Accessibility Notes, January 2020
At work, I spend much of my time consulting with co-workers about accessibility. This is the second in a series of posts about common topics that come up, or other things I want to share. Let’s dive right in!
A common topic is menus that expand and collapse, toggling a set of items (typically navigation links below) them.
When people run into this, and want to make it more accessible, their search brings them to the ARIA
menubutton roles. While it seems reasonable (“it says menu on the tin” and “semantics are good, right?”), I usually advise against it.
menu role is meant for a type of “application”, which in ARIA (and screen reader implementations) implies a specific set of interactions. Screen readers might go into a specific application mode upon encountering a
As an example, you would probably use the
menu role if you were implementing Google Docs’ top-bar menu (the one that says
Edit etc.), rather than a hamburger menu, or a menu of sharing options.
Another reason not to use
menu, in my experience, is that its implementation has a number of moving parts that can go out of sync as a project goes along. As the ARIA Authoring Practices document says, “a role is a promise”. A
menu widget must act like a
menu, and it turns out there are a few things involved to do that. You can read the interactions and markup on the ARIA Authoring Practices guide.
There are keyboard interactions involved, and a set order of nesting the markup for
menuitems. Most often, I see
menuitems go on nested child nodes instead of immediate ones. At that point, the implementation is wrong, but it certainly might look right to someone! Even worse, it might look daunting. If a piece of code looks daunting, then people avoid touching it and it only accumulates cruft. That can be dangerous for the accessibility of a project long-term.
I love this article by Sarah Higley on Roles and Relationships and the various moving part of compound widgets. I think she outlines much of the same concerns, better than I could!
A concrete alternative
Given the above, I usually recommend that people simplify, and use
aria-expanded, with the menu that gets expanded immediately following the button in the markup. A button with
aria-expanded will be announced as “button, menu, collapsed” and “button, menu, expanded”, depending on the state.
display: none or equivalent on the menu. (Again, a role is a promise, so having
aria-expanded, means that it will change on press).
Where to draw the line with OS, browser, screen reader software and versions supported#
This was asked by @JKallunki on Twitter, when I elicited questions in the beginning of the month. I’ve been thinking about it since!
Part of the question hinges on what we define as support, so I’ll break it down a bit.
By saying support, I mean having as a policy that:
- We test with these browser and screen reader combinations;
- We commit to fixing bugs that come up in them.
This is especially important when considering custom widgets, such as those in the ARIA Authoring Practices, which you should be testing. It is also a kind of policy that you could have if you maintain a pattern library / design system / project guideline.
For that, the survey on browsers and screen readers from WebAIM can be a starting point.
I think part of this exercise would go hand-in-hand with writing an accessibility statement. An outline of the level of WCAG compliance you are aiming for, how people can contact you and your plans for addressing known issues, are just as important as the specific combinations of OS & screen reader that you elect to support.
Coding to standards
I should point out something else too. A big part of accessibility is about coding to standards (aside: I cannot recall where I first heard this, let me know if you have an attribution!). For example, HTML markup, implementing and testing ARIA widgets can take you a long way.
Working around specific software bugs can have an adverse effect if in the future those bugs change. That also accumulates code, which makes it less likely to change, and so on as above :)
In other words, for OS & screen reader combinations outside of your defined list, you can be open to receiving bug reports, but might not work around specific bugs. You never know, a report might surface a bug in your implementation, which can improve the experience for other combinations too!
I helped start a kind of accessibility help desk at work! We called it “Accessibility Jam”. The idea is to have an ad-hoc communal help desk about accessibility, where people can drop in and out as they want.
For your bookmarking needs, we have a site at https://accessibility-jam.club.
I hope this gives us a regular space for people to ask questions and find out more about the topic. It also gives me a supply of things to write about!
I hope you found this collection of notes useful!