Bug 270377 – AX: CSS content property replacement text ignored when it is the empty string

• Component: Accessibility
• Status: RESOLVED FIXED

[Scott]

Reviewing https://webkit.org/blog/15054/an-html-switch-control/

For the instances of the switch demonstrations which use CSS pseudo content to display visible "on" and "off" text states, Webkit is exposing this pseudo content as the accessible name of the switch control.  So, per the demos if one were to use VoiceOver they would hear them announced as "on off, switch, [actual state of switch announced here]"

If these are properly labelled, then the label element text, or the aria-label(ledby) attribute, would provide the name.  Unfortunately, the current implementation gives this pseudo content priority over the title attribute, so that can't be relied on to name the switch if there is pseudo content.

To resolve this, I would generally expect this pseudo content to not be used as a candidate for the switch's accessible name. The most common use of such pseudo content is to communicate the current state in text, anyway. So, using it as a potential name source is redundant at best, and confusing at worst. Using another one of the examples, consider the day/night switch using pseudo text to convey the current state as well as the graphical change.  Where right now, this would result in the switch being exposed as "day night, switch, [on\off]".  Even if someone were to build this in a way where only one pseudo content text string was displayed at a time, it'd result in a name change when the state changed.  So what does "day, switch, off" mean? Does it mean day is "off" so it's night?  Or that because the switch is in the off state, it _is_ daytime?


But, if there is any desire to make sure users have access to this pseudo text, potentially as a way to overwrite the implicit on/off announcements.  So for instance, a user could hear "Choose theme, switch, light" or "choose theme, switch, dark" - then this is what the ARIA working group has been discussing both as a potential new ARIA feature, but ideally, this should be possible in the HTML implementation without need for ARIA - https://github.com/w3c/aria/issues/2085#issuecomment-1973438719
 
an additional test case to show how the psuedo text isn't available when labelled, and is as a confusing name when unlabelled:
https://codepen.io/scottohara/pen/ExJxEaZ

[Radar WebKit Bug Importer]

<rdar://problem/123919592>

[Radar WebKit Bug Importer]

<rdar://problem/123919677>

[Anne van Kesteren]

Can you clarify what pseudo text is? Are you talking about the CSS content property?

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?

[Anne van Kesteren]

(Also raises the question of whether this is a problem for other role values, especially those not backed by HTML elements, but that's probably best investigated separately.)

[Scott]

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.

[Anne van Kesteren]

An early version of the demo didn't have fallback. We then added fallback to the demo and also added support for that syntax to WebKit (previously we only had the -webkit-alt CSS property), but maybe it's not entirely hooked up correctly?

[Anne van Kesteren]

Adjusting the title based on my best understanding of the issue here, which isn't unique to switch (also applies to a styled checkbox or radio button).

[Anne van Kesteren]

Pull request: https://github.com/WebKit/WebKit/pull/25527

[Scott]

if fixing the CSS content alt is what comes out of this issue, so be it.  

But I do not think the matter of what to do with pseudo content for these HTML inputs has been settled.  Devs can still put in whatever text they want, and while such text is inappropriate to surface as a name, if they use text beyond the default 'on/off' state text, then that loops back to the ARIA issue i referenced.

Is this discussion better to have in the existing switch issue/proposal on the HTML spec, or would a new issue need to be created for this?

[Anne van Kesteren]

Currently the pseudo elements are still a bit up in the air, but a new issue might be reasonable? However, I'd generally expect a label to provide the necessary context. Just like it would for a checkbox.

[Scott]

fair. but even going by the demos in the webkit blog post, those switches have no labels.  So if someone were to have custom pseudo text to indicate the switch represented "day" and "night" (or light/dark) - just hearing "on" and "off" wouldn't let someone know what they had chosen.  Even if given a label, like "theme", 'on' and 'off' wouldn't match what the designer had intended for the control.

with radios and checkboxes, people don't generally design these in a way where they expose custom states through text.  it's much more common to just have the control and the label.  Rather than with switch where people are trying to input the pseudo content text to either repeat the 

There's been a lot of discussion about this exact use case / how people want to design these controls based on examples of how switches are being used, in Open UI - and again hence the ARIA issue i raised / linked to in this ticket about providing a way to expose these instances of 'custom states' where people are intending to visually give different meaning to what is only exposed now as 'on' and 'off'.

But, i'll open a new HTML issue then if that's the best way to continue this.

[EWS]

Committed 275872@main (93c3eb8ac99a): <https://commits.webkit.org/275872@main>

Reviewed commits have been landed. Closing PR #25527 and removing active labels.