Skip to content

Accessibility: dynamic accessible names, playing with state, etc.

  • 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-activedescendant, aria-valuenow, and aria-valuetext can 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-pressed is 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-pressed state 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 type="module" in <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.