Requirements: Keyboard only

[alastc]

Guideline: Can all the functionality be activated by a keyboard interface?

Requirements:

• Keyboard access is enabled
• Keyboard focus is not trapped
• Bi-directional keyboard use is enabled

Links:

• Google doc

[patrickhlauke]

one aspect that WCAG 2.x struggled with (and the discussion is still ongoing) is how to define "standard" keyboard interaction. there is no spec that defines a standard to, say, activate a control. there are de-facto standards, but they're not strong enough to be referenced/enforced in the binary pass/fail 2.x model. in theory then, as long as there's "some" way to control things with a keyboard, they currently nominally pass 2.x.

[detlevhfischer]

no spec that defines a standard to, say, activate a control

One way would be to define minimum standard ways of interacting that must be supported for standard HTML elements like button, a, select / option, and the standard types of input enforcing that default behavior will be avaiable? Is there a risk in this? (I can see cases though where exceptions need to be defined for things like redundant links in cards, or elements like the delete button in textfields where redundant functionality is available and where tabindex="-1" might be used - so it is not straightforward - but can be done?) "Minimum" could mean that a button or element with role=button at least needs to be activatable by ENTER (and hopefully also by space bar). Custom elements could fall under this insofar as they clearly map onto the native ones. That would cover a lot of ground even if components not available natively like tablist / tab / tabpanel might be left out at this point for fear of being too restrictive.

[patrickhlauke]

One way would be to define minimum standard ways of interacting that must be supported for standard HTML elements

where would this be defined though? in the HTML spec? UAAG? it would be weird to define it in WCAG. also, it would need to be defined in a way that works for keyboard-like (but not really keyboard) interfaces.

[detlevhfischer]

it would be weird to define it in WCAG

I don't see it as necessarily weird. It is an additional layer on top of the default behaviour encoded in native HTML elements that takes care of cases where authors prevent things from functioning or define custom controls that convey that they are to be treated like default components via the role attribute, but fail to behave like them. And that has clear accessibility implications, so that would justify having it in WCAG.
As to covering keyboard-like interfaces, it should be possible to map behaviour (where available) to base functions like "activate" and "move focus". We already have that type of generalisation in the concept of keyboard interface. I guess one could try to work through such a mapping for the exisiting technologies / devices. Granted, there may be issues once we start defining this, but me thinks it would still be worth doing...

[patrickhlauke]

additional layer on top of the default behaviour encoded in native HTML elements

but that default behaviour is not normatively specified anywhere, so having this in WCAG would effectively be a requirement on user agents? while there might be de-facto default behaviour in most/all browsers, there's no guarantee that even for basic native HTML elements it's consistent with what WCAG would require.

I think a more handwavy wording along the lines of "follows platform and user agent conventions" is the best that can be done, but even that feels very brittle, as it may mean that things must be tested on all (?) platforms and user agents, lest there be one that has different conventions

[scottaohara]

agree with @patrickhlauke - i could see wcag producing some informative general expectations for common keyboard behavior - similar to how the APG has documented the keyboard commands used for their informative ARIA pattern examples. But normative keyboard requirements for elements? i dont' see that flying.

Even with recent work in html to add new features, keyboard behavior is (as always) being left up to the OS platforms. So even HTML isn't defining explicit requirements for keyboard, nor has it in the past.

[detlevhfischer]

keyboard behavior is (as always) being left up to the OS platforms

OK, I see your point. However, if there is common behavior for the standard elements at least per OS platform, I wonder if it is possible to capture under "Keyboard only" clearly deviating and undocumented kb behavior. It would need to be phrased in a generic way, like "elements can be selected and activated with the keys that commonly work for that element on the respective platform".

[GreggVan]

In the keyboard group (now the input group) we pretty much came to the conclusion that we (W3C) would need to create and maintain a document with what we think are "standard keyboard navigation commands". It could list

• standard keyboard commands supported by most browsers (and a table showing which)
• suggested future "standard keyboard commands" and browsers that do
• other commands that would be "common" but that pages would have to add themselves - that would be helpful

or somethign like that.

then we can say -- if you use these - you are all set. If you want to use something else you need to tell the user

not final but that was the only path we really saw to talking about "standard" or "common" keyboard commands