[Webkit-unassigned] [Bug 270377] AX: CSS content unexpectedly becomes name for input type=checkbox switch

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=270377

--- Comment #5 from Scott <scottaohara at yahoo.com> ---
yeah.  text rendered by pseudo content.  i unintentionally used those interchangeably without thinking it'd be difficult to follow. 

re: "I suspect that's more of a side effect of how role=switch works than <input type=checkbox switch> as the way the latter is implemented is in terms of the former. So this might have been a longstanding issue with that role?"

hmm, yeah.  sort of.  you're right this is not limited to switch.  In ARIA a switch, radio and checkbox can all receive their name from their content (child/descendent elements).  Which, in ARIA that makes sense since one will often be using these roles on elements that allow children in HTML... and it's a convenient way to make both the switch/checkbox/radio and its label all one interactive element.  Since HTML doesn't directly allow radios/checkboxes to have children, and switch didn't exist, this wasn't really so much a 'longstanding issue' as much as it was sort of a known feature/difference - this all being defined prior to CSS pseudo content being exposed/consistently exposed by browsers to AT, and prior to the changes that have been done to these inputs to even allow them to render pseudo content.

To that point, maybe my expectation can't be met?  I don't think it's a problem with the role(s)... just changing the way they calculate their names shouldn't be changed, since that'd break any custom ARIA implementations relying on them getting name from content.  The HTML inputs could arguably ignore pseudo content in calculating names, since those elements weren't expected to have children, and increasing their ability to be styled is likely the root of what introduced this.  

Or, nothing regarding the naming changes, and Webkit instead implements the CSS pseudo content alt text feature (which is used in the CSS of the demos - e.g., content: "ON" / ""... but since it doesn't work, may be the actual problem here).  If that ends up being the 'fix', then it'd be great if people called that out when they created demos / documentation for this feature.

Regardless, all this is probably just a signal that accName WPTs probably need to be made / take these use cases into account so that expectations can be set on what the names should/shouldn't be.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20240304/c5e373df/attachment.htm>