While on holidays I have been pondering a question
Why can’t ARIA interactive roles be focusable by default like their HTML counterparts?
The HTML specification states the following:
Modulo platform conventions, it is suggested that the following elements should be considered as focusable areas and be sequentially focusable:
It is important to note that the above is only a suggestion it imparts no normative requirement on browsers to implement. But of course, unless browsers did implement it would not be a useful suggestion…
An additional suggestion could be:
Any HTML elements with conforming usage of the following ARIA role values button, checkbox, radio, searchbox, slider, switch, spinbutton, tab or textbox; should be considered as focusable areas and be sequentially focusable.
Upsides
- Improve accessibility for keyboard users
- Simplify coding for developers
Downsides?
You tell me?
6 replies on “Why not?”
The answer, my friend, is blowing in the wind … it’s the tension between “Aside from using WAI-ARIA markup to improve what is exposed to accessibility APIs, user agents behave as they would natively.” and the following “The WAI-ARIA specification neither requires nor forbids user agents from enhancing native presentation and interaction behaviors on the basis of WAI-ARIA markup.” in https://www.w3.org/TR/wai-aria-1.1/#ua-support
It’s the philosophical tension between “this is only meant as info exposed to AT, nothing more, and should not influence browser behavior” and “but we don’t forbid browsers from doing it anyway”. Strong yet weasly words…
My primary argument against native focusability is that these ARIA widgets very often do not have the appropriate keyboard interactions defined for them to be fully accessible. It would, I think, be a worse user experience if browsers made these widgets natively focusable in these cases. Any author that is capable of defining the full, proper keyboard interactions would inherently be making the widget element focusable anyway.
I guess it comes down to whether one thinks it’s better for users to be able to navigate to a widget that may not otherwise be keyboard accessible or if it’s better to bypass navigation to something that isn’t going to work anyway? The latter seems better to me because it puts the burden on authors to get things right, and avoids the tenuous presumption by browsers that they’ve done so.
Beyond forcing focusability, browsers may need to do extra adaptation (for instance, actually firing the click event handler on Enter/Space when any arbitrary element with role=”button” has been force-focused). That *should* get them working. But yes, that starts going down a more complex route once you move beyond just mere click event.
I would fully support both focusability and enter/spacebar activation for simple widgets (button, link, checkbox, possibly input), but would advice against it for more complex widgets (radio/radiogroup, dropdowns of all kinds, even text inputs) because being focusable is far from sufficient, they must support much more complex interactions and continuing to push for improve HTML support and adoption is the only way forward for those.
Just playing devil’s advocate here. It sounds like some of the arguments against doing this are basically “they might misuse it.” We already have that with ARIA and we choose to use it anyway. Doing something like this would make it even easier to implement ARIA correctly.
I think the downside is perhaps just this. If you make role=”button” keyboard automatically keyboard focusable, then why not implement all the rest of the keyboard interactions for role=”button” so it is identical to using the button element. So far so good. make role=”linkn” the same as using an link element. But then you get into the roles where there curretnly is no HTML 5 element. Do the browsers then just implement all the additional keyboard interactions? If they are going to do that, wouldnt it be better if they focused on creating native HTML 5 elements to do those things? If they are going to do that, then why do the extra work to support ARIA because then ARIA is no longer needed. Just a thought.
[…] Faulkner asked this exact question in August in his post Why not? and got some thoughtful […]