core-aam
core-aam copied to clipboard
w3c
Sanity-check mappings for switch role
The switch role is mapped to toggle button in IA2 and ATK. This has apparently led to some problems. See https://github.com/nvaccess/nvda/issues/9187#issuecomment-457001861.
Do we want to change the mappings?
In terms of ATK, Orca is already handling this so whatever works for IA2 is probably fine.
NVDA is handling the current mapping now as well; see nvaccess/nvda#10782. In an ideal world, I think this should be cleared up in the spec, probably by mapping to platform role checkbox. However, I'm not sure if this would break other AT; e.g. JAWS, ZoomText.
I guess that leaves two options:
- Check with various AT products to see if the change breaks things; or
- Put it in the "slightly quirky but we have bigger fish to fry" category and leave it as is, avoiding any potential backwards compat breaks.
Chrome exposes it as a toggle button, with IA2_STATE_CHECKABLE. If it's checked we expose both STATE_SYSTEM_CHECKABLE and STATE_SYSTEM_PRESSED.
However, I found this comment message in Chrome's code (from https://chromium-review.googlesource.com/c/chromium/src/+/1101849/ intended to fix this bug: https://bugs.chromium.org/p/chromium/issues/detail?id=844021)
On Win, ARIA switches are equivalent to toggle buttons. We need to expose both the pressed and checked states instead of only checked. This fixes NVDA's announcement of the toggling of switches to on, whilst minimally affecting Jaws. Jaws now reads "
on pressed" instead of " on".
It seems from looking at the CL that JAWS currently expects checked, and NVDA expects pressed. JAWS is presumably using the xml-roles object attribute to differentiate it from a regular toggle button. I'd prefer to only expose it as pressed, as this is consistent with IA2_ROLE_TOGGLE_BUTTON, but alas that will break NVDA in the way described in the above-linked bug.
I agree with Jamie’s comment that there are bigger fish to fry and that we should leave this one alone. I’m not sure what the upside is other than clearer mappings. At best removing the checked state won’t break recent JAWS versions and will break older ones that treated toggle buttons as checkboxes where the author got the role wrong. Don’t know exactly when explicit toggle button handling got introduced in JAWS, but it was within the last couple of years. If the momentum is high for making this change, we can investigate further, but I’m fairly sure there will be some negative impact on JAWS users running earlier versions where pressed is an ignored state because it normally connotes a transient state not worth communicating.
From: joanmarie [email protected] Sent: Thursday, July 23, 2020 12:13 PM To: w3c/core-aam [email protected] Cc: Glen Gordon [email protected]; Mention [email protected] Subject: Re: [w3c/core-aam] Sanity-check mappings for switch role (#75)
@ggordon-visperohttps://github.com/ggordon-vispero: Could you please let us know if this would break JAWS?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/w3c/core-aam/issues/75#issuecomment-663126550, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGBCJAT7XWEUUA7MEVCLNNDR5BVQDANCNFSM4O4U3D5A.
Caution This email originated from outside Vispero. Do not click links, open attachments or forward unless you recognize the sender and know the content is safe.
Removing the checked state would break NVDA. So I think that means we're at an impasse: JAWS needs pressed, NVDA needs checked.
If we care, we do have this option:
- Ask NVDA to accept checked or pressed. If either are present, it's considered pressed. If neither are present, it's not.
- In a couple of years, we can update Chrome and Firefox to just do pressed.
- Finally, update NVDA to only accept pressed.
I apparently miscommunicated in my previous message. What I intended to say is that JAWS historically has relied on the checked state, and if you remove that, older versions of JAWS will definitely stop working. I’m fairly sure that current versions of JAWS use the IA2 attributes and not the pressed state.
My comment about pressed related to how it’s generally been abused in Windows. Other than in very specific situations, it conveys nothing but noise.
There's no attribute for aria-checked/pressed, though, only the role. So newer versions of JAWS are presumably using STATE_SYSTEM_CHECKED or STATE_SYSTEM_PRESSED as well as the xml-roles attribute. If it works in Firefox, it could only be using STATE_SYSTEM_CHECKED, but I'm not sure if it does or doesn't at this point.
I'm a little confused, I'm afraid. If the ARIA switch role were exposed as a checkbox rather than a toggle button, and the STATE_SYSTEM_CHECKED state were used to indicate the switch is "on", would NVDA and JAWS each be happy?
I'm hesitant to derail the conversation, but it's bothering me that checkboxes are tri-state controls (with an indeterminate state) and toggle buttons are boolean. I would expect a switch to align more closely with a toggle button. Of course, we could just ignore the indeterminate state and consider it unused.
Each of a native checkbox, an ARIA checkbox (using aria-checked), and an ARIA toggle button (using aria-pressed) are tri-state controls. All three allow a mixed value.
The switch role does not allow for a mixed value per ARIA 1.1 and the current ARIA ED:
The
aria-checkedattribute of aswitchindicates whether the input is on (true) or off (false). Themixedvalue is invalid, and user agents MUST treat a mixed value as equivalent tofalsefor this role.
UAs are inconsistent in how they handle for a mixed value, and when the wrong role is announced, it confuses the situation more for users.
I encourage some decision on this if only to allow for better user/dev documentation.
As a side note, exposing it as a checkbox can set the expectation that a user submission is necessary to commit the change (I only have anecdata from a small testing pool).
