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.

[LaurenceRLewis]

Closing

[patrickhlauke]

fwiw you could have left this open...i don’t speak for the AGWG, they may have a slightly different view on this...

[mraccess77]

It is not a failure in my opinion.

[JAWS-test]

@patrickhlauke If you still have time to deal with it, I would be interested in your answers to the for me unanswered questions.

• I don't understand why it is possible to refer to standard keys in 2.1.2, but not in 2.1.1.?
• If buttons can be activated with Enter and Space, it may not be a violation of the WCAG if at least one of them works. But what if neither is possible? Is it then also no violation of 2.1.1?
• Are the Understanding documents and Techniques and Failures normative? If so, how do you rate the fact that these documents mention certain keys that must work?
• Why would a phrase like "if there is a standard operation for a control element in the user agent, this is to be used. Deviations from the standard operation are to be documented" a problem? I think, for most operating systems and user agents there is a defined list of operating modalities from the manufacturer.

[patrickhlauke]

• the wording in 2.1.2 is inappropriate in my opinion and is too vague, something i’ve argued before. will raise this again.
• the only requirement of 2.1.1 is that some way of using the keyboard is available. if a site implemented some stupid scheme where activation happens only when you press SHIFT or whatever, it would still pass a strict reading of 2.1.1

[patrickhlauke]

• understanding and techniques are informative/non-normative - see the intro to the respective documents e.g. “Please note that the contents of this document are informative (they provide guidance), and not normative (they do not set requirements for conforming to WCAG 2.1)”
• because you think those documents from browser/user agent developers exist doesn’t necessarily make it so. if they are, for all user agents, then by all means try to propose a normative new SC

[LaurenceRLewis]

Opening

[detlevhfischer]

@LaurenceRLewis

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.

There are trade-offs here - user research shows that many users do not understand the tab panel interaction pattern and expect tabs to be tabbable - they may even completely miss content. You cannot ignore the history of tabs having been used for a decade and more in many sites as a tabbable navigation scheme.

More knowledgable users like the ARIA pattern, but are hardly thrown off-course when tabbing also activates tabs.
Mandating the ARIA pattern as the only right one and failing any deviation seems not the right course of action to me, also not supported by current normative text.

[JAWS-test]

@detlevhfischer But there are elements that are operated uniformly across platforms and browsers, e.g. buttons with Enter and Spacebar. What if a button can neither be operated with Enter nor with Spacebar? Does everyone agree that this would not be a violation of 2.1.1? If it were a violation, I would continue to plead for this to be added in the Understanding. If it were not a violation, I am in favour of adjusting the WCAG accordingly so that it becomes one.

[LaurenceRLewis]

@detlevhfischer You have a point and I agree the example of a tab widget that having every tab a tab stop may not have a big effect on a keyboard user regardless of experience. However this is not the case for a button.

FWIW IMO

I don’t subscribe to the thinking, 'because something was done a certain way historically, that it needs to remain that way'. The ARIA design paradigm, including the keyboard interactions, were written with accessibility in mind and for consistency.

Making sure developers maintain this pattern sets a consistent future standard.

This standard then becomes the norm for users.

For users who ‘historically’, use, or who don’t know the keyboard controls for a component widget, it is easy to add instructional text above the widget. Example: (use the arrow keys to navigate the tabs)

The end result is consistency across the board where any website implementing a widget type i.e. Tabs offers the user a global consistent keyboard approach.

[patrickhlauke]

as a very general point: you can’t change the meaning/interpretation of an existing WCAG SC after the fact to make it stricter...as this would result in things previously passing that SC now failing this SC. adding something to non-normative understanding document can’t change the normative understanding of an SC either. lastly, keep in mind that WCAG is referenced/incorporated into actual legislation in many countries, so it’s even less easy to just change interpretation later on.

so either you propose a NEW SC that complements an existing SC, or deprecate a past SC and redefine a tighter one.

but in short, it’s a bit more complicated and political than “i think this should fail”. it has to be weighed up against various factors, including “how much of the existing web content in the wild would immediately fail WCAG if we introduced a particular new SC”

[LaurenceRLewis]

@patrickhlauke. If changes are make and released in a version update. Then it would only apply from that point on.

[LaurenceRLewis]

@patrickhlauke As a matter of interest there is a precedent for changes to a SC after it is published. The images below show the changes made to SC 1.4.11 Non-Text Content sometime between January 19 2019 and March 22 2019.

The second screen image shows the addition of a section called ‘Boundaries’.

[patrickhlauke]

changes to a non-normative document that clarify the normative intention are not changes to the normative SC itself. anyway, bored of this now...

[alastc]

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.

As a heavy keyboard user (although not due disability) my instinct would be to use enter. Space often doesn't have the desired result and often does scroll the page, so I've learned not to use that. Given how often links & buttons are used interchangeably (and space scrolls when on a link), I'm not convinced that using space for buttons is a user-known default now, or that it should be.

JAWS and NVDA already include the Space to activate [fake] buttons by default.

I think heavy use of space might come from screenreader usage, which is often supplimented by the screenreader (e.g. in voiceover VO-space is like clicking something). But this is something the screenreader is doing for the user, that doesn't mean the website should also map the space key.

the question is why the access keys should be documented for a keyboard trap, but not the access keys for other keyboard operation.

Keyboard trap has a slightly raised importance as it is one of the ‘non-interference’ criteria. I assume the logic at the time was that this SC can completely block usage of a page, therefore the method of getting out of a keyboard trap has to be clear. 2.1.1 is a more general requirement and doesn’t specify patterns.

The images below show the changes made to SC 1.4.11 Non-Text Content

The changes were additive. i.e. not intended to change the meaning of the SC, but fleshing out how it applies in different situations. The decisions about the boundaries aspect were made prior to 2.1 being released, but feedback showed the understanding doc wasn’t clear enough, so we worked on that. (And will continue to.)

[LaurenceRLewis]

I personally have gained insight into aspects of SCs not previously considered that I can take away as learning.

Thank you for your contributions to this post.
My question has been answered conclusively.

Keyboard interaction for elements and component widgets based on non-normative documentation are not, and should not, be considered a failure of SC 2.1.1 Keyboard.

Closing