New SC for keyboard operation?

[JAWS-test]

I propose a new success criterion for WCAG 2.2 as a supplement to 2.1.1:
"If a standard operation exists for navigating through the page and for operating the interactive elements, then this should be implemented. Divergences should be documented in the application. Exception: The operation is controlled by the user agent and is not modified by the author".

Reason:

• 2.1.1 only requires keyboard operation, but does not specify how this should be done. I.e. according to 2.1.1 it would be ok if the buttons could only be activated via Alt+Shift+X and this is not documented anywhere (see Should role button and input button be a WCAG fail if cannot be activated using space? #857 (comment)).
• In 2.1.2 it is specified for keyboard traps that the standard operation must work and that divergences from the standard operation must be documented.
• If an application implements deviating operating methods, it runs the risk of no longer functioning with the screen reader, since the screen reader does not pass many keystrokes to the browser in reading mode, but uses them for its own functions (this does not apply if role=application is used or ARIA roles that cause the switch to application mode or form mode). However, if a blind user receives an indication of the used operating method in the application, he or she can manually switch the screen reader to application or form mode or use an access key to pass individual key entries directly to the browser.
• Even without a screenreader you run the risk that accesskeys will work in one browser and not in the other. So e.g. input tabindex=-1 accesskey=e can be focused in Firefox with the keyboard, but not in IE 11, Chrome and Edge Chromium, because in these three browsers with Alt+E a browser-specific function is called out. This would not be a violation of the new SC, but a problem of the browser. But it shows how important it is to support standard operation and not to rely on accesskeys, which might not work at all.
• Statistically, 2.1.1 (besides 1.1.1, 1.3.1 and 4.1.2) has the most problems with accessibility tests. Therefore, it would be good to close this loophole at 2.1.1.
• The problem affects many user groups. Primarily blind and motor-impaired users. But also cognitively and visually impaired people sometimes work with the keyboard.

Impact

• Strong improvement of keyboard usability in few cases where it is violated.
• Affects only a few pages and applications, as problems often occur with 2.1.1, but the new criterion would rarely be violated.
• The developers could either implement the standard operation (high effort) or simply describe its operation (very low effort).

For WCAG 3.0, it would make sense to combine 2.1.1 and the new criterion, as was done for 2.1.2.

I suggest AA as the level.

During the test I very rarely encounter keyboard traps, but very often hard to use web applications, because the standard keyboard operation was not implemented and the divergences were not documented. That's why I think this is an important addition.

If necessary, it could be considered to make the new criterion more general and to extend it to standard operation for pointing devices, touch, etc.

[jake-abma]

The problem as described seems to be an equally problematic issue for all users. This in contrary to a disproportionate burden for people with different needs and abbilities. This equal disbalance needs to be in place in order for a SC to be considered. The purpose of a SC is to harmonize the disbalance.

[jake-abma]

Among other rules, here's the first:

"Success Criteria shall:

1. Address a situation where a user with a disability will be disproportionately disadvantaged (as compared to a user without a disability) if the criteria is not met."

[mraccess77]

I'd argue that users with disabilities tend to more use a keyboard interface and that in general mouse operations are intuitive and thus non-documented keyboard interfaces are more of an issue for people with disabilities. I'd also point to new proposed SC for gesture documentation that is along the same lines as this.

[jake-abma]

This may be applicable for Keyboard only users and AT users ... not sure if this is discussed already in the past, but a global standard for keyboard / component functionaly should be part of the reference

[jake-abma]

Ah, you beat me to it Jon... so you know about previous discussions and do we have clear guidance on which key belong to what UIC? There are cases where people do not agree on the patterns.

Like the Tab widget and Tab / arrow keys to navigate...

[jake-abma]

B.t.w. the new gesture SC is only about custom gestures, not standard operating. This is a well considered decision.

[jake-abma]

I agree with the problem we're trying to solve here. Seen lots of bad implementations last years but especially when custom components are build.

As web components / custom elements become more and more part of the norm we might see if we see value in something like:

"Custom components can be operated in the same way as their native counterpart, unless... "

[patrickhlauke]

x-ref #857 where i suggest that it's a bit handwavey since there's no documented normative standardised way in which user agent keyboard interactions are defined. makes it a fairly fluffy/vague requirement (which may also change overnight if a user agent decides to change or extend their current keyboard interactions, so you could end up with something that passes one day but fails the next)

[JAWS-test]

@jake-abma

The problem as described seems to be an equally problematic issue for all users

No, not at all. As a mouse user, you are free to use the keyboard. If the keyboard doesn't work: no problem, use the mouse. As a keyboard user, you are essentially dependent on the fact that the keyboard operation

• works at all (regulated in 2.1.1 and 2.1.2) and that
• it is recognisable how it works (regulated so far only in 2.1.2 for traps)

By the way, it would of course not be a violation if an element could not be operated with the mouse. Then everyone would have to operate the element with the keyboard and would fail. That would be a malfunction of the application.

There are cases where people do not agree on the patterns

And I've added the restriction for this particular case: "If a standard operation exists for navigating through the page and for operating the interactive elements"

Like the Tab widget and Tab / arrow keys to navigate...

Actually, everyone agrees on that:

• if the tabs are links in a list (a href in ul) they must be reachable with Tab.
• if the tabs are marked with role=tablist/tab, with arrow keys (https://w3c.github.io/aria-practices/#tabpanel).

Otherwise it would not work with Screenreader.

Also: If two operations are common (like here, depending on the implementation: arrow keys and tab), of course both are allowed. But what if the tabs are only reachable when F5 has to be pressed to focus them and then Shift+ and Shift- to navigate through them. Who would consider this a useful and accessible method for keyboard users (unless it is documented)?

There would be enough space in the Understanding document to explain these subtleties. However, I will of course only write a draft for this if there is an agreement that such a new criterion makes sense.

[JAWS-test]

@patrickhlauke

since there's no documented normative standardised way in which user agent keyboard interactions are defined

I don't know if anything's documented anywhere. But there are

• https://w3c.github.io/aria-practices
• a standard that has established itself on the web within all major browsers and that applies to most elements (the only exception I know of is the non-contiguous multiple selection of select multiple, which varies from browser to browser with the keyboard or does not work at all)
• and in 2.1.2 WCAG also found a solution to the problem that it could theoretically be possible for browser manufacturers one day to decide that navigation should no longer be possible using the tab key, but with the key combination WIN+N: "or other standard exit methods". I.e. if the standard changes, everything is still fine with the SC
• In addition, UAAG requires all user agents to comply with standard operating procedures. For example, if one day in Chrome the links are no longer reached by tab, this is not a violation of the WCAG, but Chrome has violated the UAAG: https://www.w3.org/TR/2015/NOTE-UAAG20-Reference-20151215/#sc_215
• Assistive technology relies on standard operation. The screenreader outputs operating instructions for many elements and specifies the keys that must be used (e.g. menu, tree, tab, select, grid: arrow keys; link: enter; button: space bar etc.).
• There are also standard methods for mouse operation that are meticulously adhered to by web developers, regardless of whether they are specified exactly or not. But everyone knows them. If you don't adhere to them, you are doomed to your site or application not being used. No mouse user likes it when a link cannot be activated with the left mouse button. She or he would leave the page immediately. Only keyboard users are sometimes confronted with unusual operating methods: because a violation of the standard is not considered a functional error, but "only" an accessibility problem.
• There seem to be clear rules for keyboard operation at least for the operating system (for Windows in the Microsoft Platform SDK documentation, see http://www.screenio.com/gui_screenio/gs_htmlhelp_subweb/windows-stuff/windows-keyboard.htm, https://docs.microsoft.com/en-us/windows/win32/uxguide/inter-keyboard). The handling of interactive elements within browsers is often derived from them, although there are some differences. How to deal with these differences could be explained in the Understanding, if you want to rely on the standard operation of the operating system in the new success criterion.

[patrickhlauke]

• https://w3c.github.io/aria-practices

This is about ARIA of course. And the keyboard interactions there document the current generalised way in which ARIA widgets behave. This is not normative, and not a document that mandates explicitly how user agents should behave...so it's not a basis for then potentially suing web developers for not abiding by it (which, at the end of the day, is what WCAG is/can be used for). It was already established in different conversations here that not following an ARIA pattern itself is not a failure of WCAG, so by the same rationale we can't fail things because they don't follow the suggested/documented "this is generally how keyboard interactions with these sorts of things work in most user agents).

• a standard that has established itself on the web within all major browsers and that applies to most elements (the only exception I know of is the non-contiguous multiple selection of select multiple, which varies from browser to browser with the keyboard or does not work at all)

That's not sufficiently specific to make a "you didn't follow this, you fail and can be sued" argumentation.

• and in 2.1.2 WCAG also found a solution to the problem that it could theoretically be possible for browser manufacturers one day to decide that navigation should no longer be possible using the tab key, but with the key combination WIN+N: "or other standard exit methods". I.e. if the standard changes, everything is still fine with the SC

You found a solution = you've come up with a way of reading/interpreting an SC to fit your particular argument. Not everybody will agree with you, which is why these sorts of statements become problematic, and which is why I believe the actual handwaving language used to keyboard trap needs revisiting - however, at least with keyboard trap, we're handwaving one single interaction. Here, you're extending the argument to ALL widgets/controls, which is a much bigger handwave, and therefore far more problematic.

• In addition, UAAG requires all user agents to comply with standard operating procedures. For example, if one day in Chrome the links are no longer reached by tab, this is not a violation of the WCAG, but Chrome has violated the UAAG: https://www.w3.org/TR/2015/NOTE-UAAG20-Reference-20151215/#sc_215

UAAG is not enshrined in/referenced by law. If a browser manufacturer doesn't follow UAAG, they can't be sued for it directly. If, however, a web author doesn't follow WCAG, they potentially can. So this is far more dangerous territory, and unless very explicitly clear and binding language/specification is available that says exactly what authors can/can't/must/mustn't do, I'd not be comfortable putting forward this SC (particularly at level AA - maybe at a stretch AAA, but even there the wooliness of language would be a problem for me).

[JAWS-test]

@patrickhlauke

and unless very explicitly clear and binding language/specification is available that says exactly what authors can/can't/must/mustn't do

There are dozens of other criteria whose language is much vague and whose rating is much more subject to the subjective evaluation of testers, developers, users, judges, etc.:

• 1.1.1: "All non-text content that is presented to the user has a text alternative that serves the equivalent purpose" - what is equivalent?
• 1.2.1: "provided that presents equivalent information" - same question...
• 1.3.2: "When the sequence in which content is presented affects its meaning" - when affects meaning?
• 1.4.12: "no loss of content or functionality" - how much may the page be changed, that there is no loss of content or functionality
• 2.1.2: "or other standard exit methods" - what are other standard exit methods
• 2.1.4: "The keyboard shortcut for a user interface component is only active when that component has focus" - how big may the component be to be considered as such (Confirming 3rd bullet of Character Key Shortcuts #844)
• 2.2.2: "there is a mechanism for the user to pause, stop, or hide" - what requirements exist regarding the mechanism?
• 2.4.2: "Web pages have titles that describe topic or purpose" - What must a title look like to describe the page?
• 2.4.6: "Headings and labels describe topic or purpose" - same question
• 3.1.3: "A mechanism is available for identifying specific definitions of words or phrases used in an unusual or restricted way, including idioms and jargon" - what are idioms and jargon? (Linguists can write dissertations about the question)
• 3.1.5: "When text requires reading ability more advanced than the lower secondary education level" - is the education level the same in all countries of the world? And what if the level goes up or down?

And 2.1.1 is currently also one of the criteria that are very vague because it is not clear what is meant by keyboard operation: any or standard operation. If any keyboard operation were allowed, there wouldn't be the exclusion criterion: "The use of MouseKeys would not satisfy this Success Criterion because it is not a keyboard equivalent to the application; it is a mouse equivalent ". The new criterion would solve the problem of inaccurate definition in 2.1.1.

In the current version, 2.1.1 is not testable at all, because no tester can try all the other billions of key combinations that would be possible for every element that cannot be operated with the standard keys.

[JAWS-test]

Exception added: "The operation is controlled by the user agent and is not modified by the author"

[mraccess77]

An often cited failure of WCAG is a button that is an anchor tag with role button that only works with enter and not spacebar. Many fail this situation although it's not a WCAG failure. It likely produces unexpected results when activated by the user.

[JAWS-test]

An often cited failure of WCAG is a button that is an anchor tag with role button that only works with enter and not spacebar

This is a common mistake, but at the same time a very minor one: if one key doesn't work, I try the other one, which I know must work. More important would be the new SC for cases where the operation is completely different, e.g. where I can't activate the button with spacebar or Enter, but only with Ctrl+B - if this is not well documented, no keyboard user will be able to operate the button. Such a case sounds absurd, but if you test pages for accessibility long enough, you will encounter such cases.

[patrickhlauke]

An often cited failure of WCAG is a button that is an anchor tag with role button that only works with enter and not spacebar. Many fail this situation although it's not a WCAG failure. It likely produces unexpected results when activated by the user.

but this then also brings up odd compound/cascade failures. what if it's acting as a button, but is marked up and exposed as a link. you'd fail this for 4.1.2 because it's not exposing the right role, but could you fail it for not reacting to space? not while it's exposed as a link. only if the authors then fix it to turn it into a button (by, say, adding role="button") would it THEN fail if it didn't react to space.

in any case, i'm still dubious of the feasibility of making this a normative requirement (unless it's pegged at AAA).

[mraccess77]

what if it's acting as a button, but is marked up and exposed as a link. you'd fail this for 4.1.2 because it's not exposing the right role

I'm not sure I would fail this as there is no clear documented in WCAG for this specific situation. Whether the element asks like a role or button may be subjective. e.g. Next buttons that look like buttons really navigate to the next page. If it must have a link but it looks like a button then it fails SC 1.3.1 because the role doesn't match the visual appearance.

[JAWS-test]

I find the discussion about links and buttons a bit pointless, because in my opinion there is no rule how a button and a link has to look like. Without CSS, both are of course easy to distinguish, but as soon as they are designed, the differences become blurred.