F87 and ARIA 24 seem to contradict in the use of CSS content property

[mraccess77]

ARIA24 example 3 (and maybe others) indicates the content property can be used while F87 says it can't be relied upon.

[patrickhlauke]

In the case of F87, the content property was relied on to convey meaningful ("non-decorative") text content (i.e. exposed to screen readers etc), and it's saying that's a failure because it can't be relied on to be exposed consistently as content to users (though support across browser/AT has considerably improved since the time that failure technique was written, and as far as I know all modern browsers and AT combinations now expose CSS-generated content correctly).

ARIA24 on the other hand uses content to display a visual icon type character, but its actual accessible name (what gets passed on to screen readers) is given by aria-label in all cases, so even assuming that some browser/AT combos out there still don't expose CSS-generated content correctly, it doesn't matter because it's explicitly redefined here via aria-label anyway.

So, not a contradiction I'd say (though F87 could probably do with some more recent note/clarification about current browser/AT support; and perhaps a better/more holistic angle here would also be that if the CSS fails to load or something, then all of a sudden your page would be missing actual text content for ALL users - AT and non-AT users alike - and that CSS-generated content will not generally/currently be indexed by search engines etc...so not relying on content here has collateral issues, but from the browser/AT point of view it may nowadays actually be a solved issue)

[mraccess77]

The rub is the check in F87
If the inserted content is not decorative, check that the information is provided to assistive technologies and is also available when CSS is turned off.

[JAWS-test]

See #907, #1007 and #433

[alastc]

From memory, F87 was kept as folks from the low-vision task force were concerned that these types of icons / content disappear when fonts and/or CSS are over-ridden.

I do wonder if it should be converted to a failure technique based more on font-icons, as that seems to be the more common example?

A quick patch would be to get ARIA24 to use another CSS method than content (e.g. positioning of a background), but that's just a technicality.

[patrickhlauke]

I think, as @mraccess77 suggests, that the main problem with F87 is the check that essentially says "test if content disappear with custom/no CSS, and if so it fails 1.3.1". that goes, i'd argue, way beyond what 1.3.1 normatively requires. or rather, it lacks nuance, as the same meaning/content may well be conveyed otherwise (with ARIA, or additional visually hidden text, etc), which does pass 1.3.1 / fulfill the requirement of being programmatically determinable. Yes, these latter ones won't help sighted users that also change/disable styles, but that's not the point of 1.3.1 per se. also, keeping in mind that even using pure CSS generated content does, in my view, pass 1.3.1, as the content is exposed correctly in the accessibility tree in modern browsers (something that didn't use to be the case years ago). if CSS is relied on, then this seems perfectly kosher to me.

as such, I don't think F87 is a valid failure technique (in the sense that this always fails 1.3.1). rather, it's more of a best practice that goes beyond the normative ask of 1.3.1?

[JAWS-test]

Currently, CSS content is not supported at all by IE 11 and very poorly by Edge and Chrome, see FreedomScientific/standards-support#297. Chrome and Edge do not submit CSS content to the Accessibility API for labels of links, buttons, form fields, and groups. As a result, CSS content on interactive elements is not output as part of the label by the screen reader (JAWS, NVDA). The same applies to speech recognition software. CSS content is not recognized as part of the label by this software either, so that the elements cannot be controlled via Dragοn NatυrallySpeaking or Windows voice recognition, for example.

Nonetheless, I am in favor of either removing F87 or formulating it to be compatible with ARIA24. If F87 remains, a warning could be included that CSS content should be taken into account when determining the Accessible Name according to the specification, but that this is unfortunately only poorly supported at present.

[dd8]

How does the CSS content: property interact with Safari Reader Mode - which Apple describes as a cognitive accessibility feature:
https://www.apple.com/uk/accessibility/cognitive/

Reader mode removes the author CSS and replaces it with reader-mode CSS. You can see how this works if you use DevTools Inspect after switching to reader mode on macOS Safari.

Switching to reader mode strips all author CSS generated content - there's a good article that describes the problem here:
https://www.sarasoueidan.com/blog/tips-for-reader-modes/

Of note: Reader Mode in Safari 15 now seems to disable Reader Mode when pages contain CSS content: - presumably to avoid the problems mentioned above. You can see this happening on w3.org - nearly all pages allow switching to reader mode - except the working example pages for ARIA24 which disable reader mode. Unfortunately the Safari UI code that wraps WebKit isn't open source, so it's difficult to be certain CSS content is the trigger.

I think that means using CSS generated content interferes with a cognitive accessibility feature:

• at best, non-decorative CSS generated content disappears in reader mode
• at worst, any CSS generated content disables reader mode

Edit: I've also observed a VoiceOver user switching to reader mode whenever possible to make pages simpler to read (so it's not just a cognitive accessibility problem)

IMO that indicates F87 is useful (but probably needs revised for reader modes) and that there's a problem with ARIA24

[patrickhlauke]

the issue with reader mode there is that CSS is relied on as an accessibility supported technology, but then reader mode simply drops it on the floor. arguably a failing/shortcoming of reader mode. question then is does the fact that reader mode does away with this effectively invalidate all reliance on CSS as accessibility supported technology, or is reader mode essentially an outlier and it can be said that it's fine to rely on CSS because users have technologies readily available at their disposal (i.e. NOT enabling reader mode) to still access the content as authored.

[dd8]

I guess it depends on whether user stylesheets need to be taken into account when relying on CSS (ARIA24 implies they are). You could view Reader Mode as an extreme example of a user stylesheet - this user.css would have much the same effect:

* { all: unset !important; } /* reset every property on every element so they won't interfere with my styles */
/* now apply custom user styles */

Fundamentally the problems with content: are because it creates content in the style layer - there are some other browser bugs / spec problems related to this which impact accessibility:

• find not working on CSS content in most browsers ([css-pseudo-4] The browser cannot search the content, is it intentional? csswg-drafts#6222)
• selection not copying CSS content ([css-ui] Yes, it would make sense to have selectable pseudo elements csswg-drafts#2894)
• CSS lang selector used for content: may not match the HTML page lang exposed to AT (html-aam should specify how language/locale is calculated from lang attributes html-aam#258)

... but there are also some good use cases where using it increases accessibility:
https://adrianroselli.com/2019/02/f87-css-generated-content-and-wcag-conformance.html

... but Wayne's analysis is still relevant:
#433 (comment)

[patrickhlauke]

as user styles can completely break an experience even if it doesn't rely on CSS (just a silly * { display: none; } is all that's needed), they're generally not taken into account when evaluating content against most SCs. and if a site chooses to use CSS as technology that's relied upon for conformance (which is generally the rule these days, as beyond just generated content there's other things like showing/hiding content, modal dialogs, etc that would simply not work if CSS is ignored/overridden incorrectly) then i'd find it hard to fail it normatively.

ARIA24 could do with being tweaked/updated (as mentioned earlier in the thread) as yes, it seems to enshrine the idea that user styles DO need to be taken into account. and F87 is now a bit long in the tooth and hasn't really kept up pace with browser changes since 2008... (as is the case with many 2.0 techniques)

[awkawk]

This came up in a discussion with @jnurthen today and we think that this failure is not valid and should be removed. Want me to make a PR to remove it? :)

[detlevhfischer]

+1 for deletion