Avoid changing the accessible name of controls on the fly. It may not get conveyed to users, or it may become oddly verbose, confusing users.
Some properties such as
aria-valuetextcan be expected to be announced by screen readers when changed (support issues aside). Some state changes (such as
aria-disabled) are not consistently announced when changed. However, as a very general rule of thumb, it is safer to assume that a change in state will be communicated than a change in property (and please never change a role during a user interaction).
aria-pressedis a state, and the accessible name is a property.
The conventional wisdom is to not change the name of a control while the user is interacting with it. It turns out this is pretty good conventional wisdom: upon testing, I found that while a name change is sometimes announced, it is not nearly consistent enough to be relied upon.
Change the name, but not the state, of play/pause buttons. Use state for all other toggle buttons.
[...] never change both the name and
aria-pressedstate in tandem. That way, confusion lies. Just imagine trying to parse the meaning of "play button, on" vs. "pause button, off".
Definitely do not give the button a disabled attribute when it shows as processing. That will prevent the button from receiving focus for everyone (such as keyboard users) and you will need to manage focus instead.
- Crafting generic focus indicators is hard.
- We can use
<script>tags to identify browsers that support ES6.
- Making accessible applications is not just about checking accessibility criteria — we need to better understand our users and their needs;
When people talk about "oh, accessibility is one of our core values"... Inclusion should be your core value, and accessibility ends up being a really good byproduct of including people with disabilities.
Inclusive design is a process, accessibility is an outcome. And we should be using inclusive design to achieve accessibility, rather than achieving accessibility by guessing or by exclusively relying on past experiences.
Here is an extensive list of recommended code libraries, patterns, and design systems.