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 first 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 2023” 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.

Tab 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 two 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 ARIA 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.

Conclusion

Support Eric’s independent work

I'm a web accessibility professional who cares deeply about inclusion and an open web for everyone. I work with Axess Lab as an accessibility specialist. Previously, I worked with Knowbility, the World Wide Web Consortium, and Aktion Mensch. In this blog I publish my own thoughts and research about the web industry.

Sign up for a €5/Month Membership Subscribe to the Infrequent Newsletter Follow me on Mastodon

The power to redefine how focus works amongst a group of UI 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 ARIA roles or the tabindex attribute. They might implement it without checking their assumptions.

A note on the “State of HTML 2023” 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 focusgroup makes little sense to me.

A note on the focusgroup proposal

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 of ARIA I had an idea to use CSS-inspired “Cascading ARIA Sheets” which would allow developers to assign roles and properties using CSS selectors and a similar syntax. I still think it could be a nifty technology to have (that would of course bring its own challenges).