Misconceptions can kill accessibility momentum · Eric Eggert

By admin
Time and time again, I come across accessibility solutions in which teams have put a massive amount of work. And often I have to ask them to undo that work. There are many reasons for that request, but it typically comes down to a false understanding of how assistive technologies actually work.

Now, don’t get me wrong, a good percentage of my work is to “well, actually” people who should know better. And I generally enjoy it – using my mansplaining powers for good.

But now and then, you get that sinking feeling that you are undoing someone’s work that they created with the best intentions, where they researched

hours and hours

for a problem they perceived.

And I come along and say “nah”.

“Nah”, because “it wasn’t a concern in the


place”. “Nah”, because “that’s not how assistive technology works”. “Nah”, because “many screen reader users can see the screen”.

The reality is, accessibility is hard, especially when thinking about it holistically. Which you have to do to not leave people behind. That complexity is inherent to the humanity that’s behind accessibility. We’re doing this for people that have all sorts of disabilities, that are different from one another in many, many ways.

Even looking at screen reader users, individual preferences and settings can throw assumptions out of the window.

I have lost count on how often I have seen developers adding tabindex="0" to random text because they couldn’t reach it using the tab key, and so they assumed that nobody could reach it.

Of course, screen readers have ways to read text on web pages. They would be pretty useless otherwise.

This blog post was spawned by

the “State of HTML


” survey and its question on the focusgroup attribute, which is an Open UI proposal that I had never heard of before.

Its goals are to bring the focus behavior of <select> elements and radio groups to other elements.

To recap: When you encounter an element with focusable child elements, the usually expected behavior is that the arrow keys do the navigation among these child elements.


to a native <select> and use the arrow keys to make a selection. This is genuinely useful behavior. You would not want to stop at every sub-item of a select, and differentiating between these


focuses makes sense.

What could bring problems is to generalize that behavior to random elements.

The use case is custom composite widgets, but experience shows that eager developers will use it in other circumstances. It would be a better approach to define default keyboard behaviors in


and let developers opt into browsers managing focus for that specific role and its children.

<!– THIS IS NOT REAL CODE –> <div role="menubar" aria-interaction="default"> … </div>

That way, browsers could verify that a role is used correctly and take measures to fix misuse. Developers would be encouraged to use correct roles for widgets and their children, if they want to reap the benefits of the default keyboard interactions.


The power to redefine how focus works amongst a group of


elements brings with it a great deal of responsibility to not mess it up. For most people, including many accessibility pros, it’s a challenge to decide when to use which behavior.

Developers are bound to stumble over these techniques, like they do now with over-eager use of


roles or the tabindex attribute. They might implement it without checking their assumptions.

A note on the “State of HTML


” survey

Generally, I think a survey like this can be useful. It would be even more useful, if it would address longstanding accessibility issues and also not itself misuse HTML elements:

Radio buttons are not supposed to be uncheckable , but if you insist on using that functionality, it must be keyboard accessible, too.

It’s also problematic that the technologies are only referred to by name without any indication if the technology is in the HTML standard (or adjacent standards), like focus group, which is a seemingly early proposal within Open UI.

Presenting landmark elements, which are part of HTML for

a decade

, alongside


makes little sense to me.

A note on the



The proposal does not use great HTML practices, which does not lean trust to it. A menubar / menuitem example uses <ul> / <li> elements only to redefine their roles. Just use <div> elements!

Another issue is the use of tabindex="-1" for demoting inactive elements in a focus group. Browsers without support will make the elements with that tabindex unreachable using the tab key, potentially hide interactive elements from users, which is suboptimal.

I also don’t like that it is both, a HTML and CSS proposal. It feels like there is a lot of potential for conflict when both are applied.

That said, in

the early days



I had an idea to use CSS-inspired “

Cascading ARIA Sheets

” which would allow developers to assign roles and properties using


selectors and a similar syntax. I still think it could be a nifty technology to have (that would of course bring its own challenges).