The switch role and associated ARIA state attributes are confusing and inconsistent.
- The switch role maps to a toggle button in the AAM.
- This is equivalent to using a button element with the aria-pressed attribute, as specified in the HTML-AAM.
- However, the authoring practices and other sources state that, with the switch role, aria-checked should be used, not aria-pressed.
An example: <span role="switch" aria-checked="true">Use dark mode</span>.
This leads to stuff like "Use dark mode toggle button", followed by "not pressed checked" announcements in NVDA. The same with a toggle button would simply say "Use dark mode toggle button pressed".
There are two possible solutions:
- Change the authoring practices and other reference material to reference aria-pressed and make it clear that a switch acts like a toggle, and that the toggle button semantics apply. This is the easier fix which does not require changes by user agents and assistive technologies. Firefox uses the aria-pressed attribute, Chrome kinda does both, but also inconsistently.
- Require the switch role to be exposed as a checkbutton instead of a toggle button, similar to a checkbox role or the checkbox input. This would require changes to more parts of the different specifications, as well as user agents.
Filing the issue here because conceptually, I would think that option 1 is the easier path forward, and would mostly require changes in documentation and examples.
Also see this NVDA issue with even more discussion, and a possible, but very ugly, third way forward on this.
The switch role and associated ARIA state attributes are confusing and inconsistent.
An example:
<span role="switch" aria-checked="true">Use dark mode</span>.This leads to stuff like "Use dark mode toggle button", followed by "not pressed checked" announcements in NVDA. The same with a toggle button would simply say "Use dark mode toggle button pressed".
There are two possible solutions:
Filing the issue here because conceptually, I would think that option 1 is the easier path forward, and would mostly require changes in documentation and examples.
Also see this NVDA issue with even more discussion, and a possible, but very ugly, third way forward on this.