Should role button and input button be a WCAG fail if cannot be activated using space?

[LaurenceRLewis]

If a keyboard user accesses a [fake] button implemented using role button or input button, and it can only be activated using the Enter key (not space as may be expected). Should this become a WCAG SC fail. I am proposing it should.

Why?

When a sighted keyboard user tabs to a button—that visually looks like a button, their first instinct may be to use the Space key. When this actions the browser default and scrolls the page; it could cause confusion, and or disorientation.

I suggest this could especially affect people with low vision and or cognitive disabilities.

As I understand it this is not a failure for Success Criterion 2.1.1 Keyboard because the button can be activated using the Enter key.

Adding as a recommendation is a start, however, in many cases, including my own work requirements for accessibility. Testing is aligned with WCAG Success Criteria. When there is a potential accessibility issue, as described above, I can advise as best practice. But, as it is not a fail of technique, recommendations are often ignored.

The fact that JAWS and NVDA already include the Space to activate [fake] buttons by default. Implementing Space as well as Enter for non assistive technology keyboard users, could be considered a reason to include this as a requirement for success.

[patrickhlauke]

depends how far you want to take this. normatively requiring that controls/widgets always follow the standard keyboard/control interactions (also including, on mobile or touch devices, responding to things like swipe up/down or volume up/down for sliders, which is only possible via AOM or by using real <input type=“range”>)? as the standard interactions aren’t normatively defined anywhere (?) this would be tricky to normatively express in a platform agnostic way...

[LaurenceRLewis]

How far I’d like to take it is; to not meet WCAG Success Criterion. 😄 However, as you point out—there is more to contemplate than only button behaviour. Which I confess I had not considered.

I need to research what is ‘normative’ and return with a more refined argument.

[LaurenceRLewis]

@patrickhlauke could you please explain the acronym AOM. Thank you.

[patrickhlauke]

https://github.com/WICG/aom

…

On 13 Aug 2019, at 13:27, Laurence Lewis ***@***.***> wrote: @patrickhlauke could you please explain the acronym AOM. Thank you. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[JAWS-test]

I think this is a violation of WCAG 2.1.1. Imagine the activation of the button for mouse users as usual with the left mouse button, for keyboard users however neither with Enter nor with Space, but with Shift+Alt+B and this access key is nowhere documented. Of course the application would then be theoretically keyboard operable, but it would not be practical at all. Therefore the "Understanding SC 2.1.1" should be added, that keyboard operability is only given with custom elements, if it is equivalent to standard elements. Alternatively, a new success criterion should be created for this case. The criterion should be kept general (standard operation and perceptibility of the access keys, if no standard operation) and could be level AA.

[patrickhlauke]

this is a new interpretation that goes beyond the normative language of the SC and tightens it. so no, can’t just be redefined in informative understanding document

[LaurenceRLewis]

In response FWIW

Analysing the words ‘normative’ and ‘agnostic’ in relation to my suggestion for failing the WCAG Success Criterion (SC) 2.1.1 Keyboard; where an element is converted to a button using an ARIA role, and the keystrokes do not meet the default keyboard interaction assigned to a native element of the same type. In this case <div role="button" versus the native HTML <button>.

Normative
Normative as used on HTML Accessibility API Mappings 1.0
Normative sections provide requirements that authors, user agents, and assistive technologies MUST follow for an implementation to conform to this specification.

Platform Agnostic
Platform agnostic states the functionality runs equally well across more than one platform.

A role is a promise
WAI-ARIA Authoring Practices 1.1 Principle 1: A role is a promise

    `<div role="button">Place Order</div>`

Is a promise that the author of that <div> has also incorporated JavaScript that provides the keyboard interactions expected for a button. Unlike HTML input elements, ARIA roles do not cause browsers to provide keyboard behaviors or styling.

In relation to the ARIA role=button where scripting is required to assign specific keystrokes (Enter and Space) to activate the button. Enter is initiated by default (assuming the button is focusable).

A normative approach to Platform Agnostic
The term platform agnostic does not apply in this instance; because the hardware implied is a keyboard. The default keystroke for a native button element is both 'Enter' and 'Space'—setting a normative pattern.

This is the same regardless of how the keyboard is connected and the device it is connected to.
For instance, 'Enter' and 'Space' are normative to trigger a native button element—whether Apple MAC or Windows PC, Physical keyboard or onscreen touch keyboard. The same applies to a keyboard connected to a touch device. My research suggests a pointer device, other than a mouse, interacts the same way, with the same expectations of keyboard interaction.

Mobile and touch devices, considering both are touch, unaware as I am of a non-touch mobile, use a tap to activate a button. This is independent of a keyboard and therefore has no normative association and as such cannot be platform agnostic.
If a keyboard is the input controller and connected to a touch device; mobile or other, Enter and Space to activate a button is normative.

How does this compare with things like swipe up/down or volume up/down for sliders; which is only possible via AOM?

The expected keystrokes for slider role is again normative for keyboard interaction and different, but also normative, for touch devices as described in the MDN post Using the slider role.

"Never the twain shall meet" Mark Twain"

In terms of The Accessibility Object Model (AOM) I am not certain where the requirement is "to develop additions to the web platform to allow developers to provide information to assistive technology APIs, and to understand what information browsers provide to those APIs."

Because managing keyboard interaction through scripting already exists and the only requirement, I am seeking is that the keyboard interaction meets with the expectations of the user based on the specific design patterns for a component.

Where could this also apply?
The same could be said for component widgets, for example; a Tab Control where there is specific and expected keyboard interaction. A tab widget should be one tab stop with arrow key navigation within the widget. This is the promise given when the mark-up is implemented per spec and includes the appropriate ARIA roles.

When the keystrokes differ from the expected keyboard interaction as described in the ARIA WAI-ARIA Authoring Practices 1.1 Tabs this can cause frustration and or confusion.

In my experience in testing I often find the developer has included all the required roles and attributes; but has not considered the keyboard design pattern, causing every tab in the widget to be a tab stop.

Unfortunately, this is not a failure of WCAG SC 2.1.1 Keyboard, because the elements CAN be accessed using the keyboard and the user is therefore not excluded from accessing the content.
I believe this is an oversight which should be amended.

@patrickhlauke No disrespect intended but I do not find you have a compelling argument against this becoming a failure for a success criterion. The question is should it be a fail or a strong recommendation.

[JAWS-test]

@patrickhlauke In my opinion, the question is whether WCAG is interpreted strictly in the interest of keyboard users or not strictly in the interest of website operators who are not interested in changing their site. In my evaluation of websites I always interpret WCAG strictly. My reference point at 2.1.1 is the regulation in 2.1.2: "...using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away". Unfortunately, such a clear definition is missing in 2.1.1. However, the question is why the access keys should be documented for a keyboard trap, but not the access keys for other keyboard operation.

[JAWS-test]

see also: https://www.w3.org/WAI/WCAG21/Techniques/client-side-script/SCR35: "... the onclick event is actually mapped to the default action of a link or button. The default action occurs when the user clicks the element with a mouse, but it also occurs when the user focuses the element and hits enter or space, and when the element is triggered via the accessibility API"

[JAWS-test]

For many interactive elements, assistive technology automatically outputs input hints based on the role of the elements (Screenreader JAWS e.g. "Press ... key to" do this and that, if you navigate to a button JAWS say: "To activate press space bar"). If these automatic input prompts do not match the actual keyboard operation, it becomes problematic

[JAWS-test]

See also: https://www.w3.org/TR/wai-aria-practices-1.2/#button: "When the button has focus: Space: Activates the button."

[patrickhlauke]

you use a lot of words to prove i’m wrong, lawrence...well done. well let’s see what the rest of the working group thinks

[LaurenceRLewis]

I did say I would try to return with a more refined argument. I think I just had to get it out of my head. Probably longest post I’ve ever written 😳

[patrickhlauke]

further additions: there is no normative spec anywhere that defines standard keyboard interactions with widgets/controls. ARIA ptractices is not a normative spec. WCAG SCs are normative. you can’t write a normative SC requiring authors to follow something that isn’t also normative.

as for the AOM and swipe etc angle, the point is that SCs should be broad enough - one of the problems of WCAG 2.0 has been its keyboard-centric approach. going forward, it would be better to not add more SCs that only cover one input modality (keyboard), but others too (mouse, touch, etc). so instead of defining another keyboard SC it would be better to do a more generic “things behave the way they should/the way users expect” - but there it again bumps against the lack of a normative reference of what that expected behavior is.

as for “interpreting” SCs, the idea is that SCs should not require interpretation that leads to different results. you can only really evaluate against a strict reading of the normative SC text...anything else is taking your own spin on things which is NOT assessing against WCAG

[LaurenceRLewis]

I cannot say I completely agree, but I concede to your wisdom. (Edit) @patrickhlauke I have learnt from this discussion. Thank you.