Is the assumption behind technique F87 still valid (meta issue)

[patrickhlauke]

There are already a few long-standing open issues against F87

• F87 is incomprehensibly formulated #907
• F87 and custom-styled form controls #1007
• F87 and ARIA 24 seem to contradict in the use of CSS content property #1554

There's also a lengthy (due to back and forth around "progressive enhancement is a failed idea" / "on the contrary, it's still very much relevant these days" / "back in my days, websites were built right, developers these days don't know what they're doing") discussion on w3c-wai-ig https://lists.w3.org/Archives/Public/w3c-wai-ig/2024JanMar/0164.html that brought this back to the fore.

It would be good to have another closer look at F87 and hopefully address the outstanding open issues and remove any potential confusion.

For my own part, the one aspect of F87 that rubs me the wrong way is that it seems to primarily refer to the scenario where users override or suppress the site's CSS. However, this is arguably outside of the scope of what WCAG addresses (we've had similar discussions around Windows High Contrast Mode) - at which point is an author responsible for what happens when a user explicitly changes aspects of the CSS they define?

(Noting that if the idea with 1.3.1 is to also cover non-AT users that remove/override CSS, it would then potentially invalidate any AT-specific ways to address 1.3.1 such as the use of ARIA, unless the assumption is that those users would also somehow change their CSS to visibly expose ARIA attributes or similar...otherwise, we really need to define exactly which "programmatically determinable" parts are kosher and which aren't)

There's also been an underlying assumption, in similar discussions, around whether or not screen readers can read/expose CSS-generated content. Back in the days when F87 was penned, it was not the case. Nowadays though (barring browser/screen reader bugs), CSS-generated content is announced (and in fact causes opposite problems - when font-based icons are used that map to regular characters and are then read out by SRs, leading to confusing aural experiences).

[mbgower]

I skimmed through all this, and it seems to me over time that the sentiment has tilted towards removing the technique (with the primary argument being that browser and AT support has improved).
What do people perceive as the negative consequences if F87 is removed?

[fstrr]

If anyone needs this, here's the two examples from F87 in CodePen.

[philljenkins]

CSS and JavaScript have improved so far for more than a decade that they are relied upon and clearly "accessibility-supported technologies" per the following:

• see WCAG 2.2 5.2.4 Only Accessibility-Supported Ways of Using Technologies
• see the definition of accessibility supported

If agreement is reached that CSS & JavaScript are accessibility supported, then it creates a strong rationale for removing F87 (and/or rewording) because it is no longer a valid failure technique for 1.3.1. Otherwise, even though "techniques" in general are not considered normative, "Failure techniques" do have the effect of being "normative" because they "fail" the SC:

Failures

Failures are things that cause accessibility barriers and fail specific success criteria. The documented failures are useful for:

• Authors to know what to avoid,

• Evaluators to use for checking if content does not meet WCAG success criteria.

Content that has a failure does not meet WCAG success criteria, unless an alternate version is provided without the failure.

If anyone identifies a situation where a documented failure is not correct, please report the situation as a WCAG comment so that it can be corrected or deleted as appropriate.

As currently worded, the only way to "pass" 1.3.1 would be to be forced to always provide a way all the time to support turning off CSS and JavaScript.

[electrickite]

A few thoughts:

• I don't think there can be much debate that CSS and JavaScript are accessibility supported. They are widely available, well supported, and in many cases relied upon to produce accessible content.
• Less objectively, I'm not sure that it is a reasonable expectation of web authors to support users who disable CSS or JavaScript, especially for sites that function more as applications and less as static documents.
• It appears that the majority of browsers are exposing CSS generated content in the accessibility API, which would mean that it can be programmatically determined (and also is probably available in text, depending on your interpretation).

From those points, I would argue that F87 is no longer a failure for 1.3.1. Since that is the only SC it relates to, it should probably be removed. As much as I think that the content feature in CSS breaks the content/presentation distinction, we are where we are. We were honestly already well down this road when display:none; effectively removed content from the a11y tree - stylesheets became critical to the semantic structure of the document.

[mraccess77]

I think there may be a few oddities such as not being able to search for the pseudo content, not being able to select text, and the complexity of calculating the accessible name for tools that can't access the accessibility api - but on the whole this has been long supported by most assistive technology. I suppose it could be used in problematic ways that could complicate things for some users.

[philljenkins]

@mraccess77 Johnathan, do you consider either of these "bugs" with the browsers?

... such as

1. not being able to search for the pseudo content
2. not being able to select text

First of all, thanks for pointing that out. first real issue I've heard, whether or not accessibility related.

And, why can't the AT access the API? Is it more of a case where the AT doesn't access the API, but could, correct?

3. and the complexity of calculating the accessible name for tools that can't access the accessibility api

So a bug should be opened against the browsers (if not already) and against the AT's so that it does access the API.

[mraccess77]

Maybe it's easy to access the content via CSS computed properties - I'm not certain - but to my knowledge on page AT JS tools can't access the accessibility api from JavaScript - but browser extensions can. The goal will be for this access - but I am not current on where that is. Do others know if any of these things are material issues?

[JAWS-test]

not being able to search for the pseudo content

Firefox can search for it, Chrome can not

[mraccess77]

I skimmed through all this, and it seems to me over time that the sentiment has tilted towards removing (browser and AT support has improved, being the primary argument). What do people perceive as the negative consequences if F87 is removed?

I use Stylus extension in Chrome to apply CSS to many pages I use on a regular basis to improve readability of thin text, focus, indicators, and other content.

[shunguoy]

@mraccess77 it seems to me the Stylus extension only changes themes and skins (e.g., font, size, bold), rather than reformatting or new content. The theme and skin changes are also widely available in a mobile OS, and those do improve accessibility a lot but are not well related to the F87.

[scottaohara]

referencing PR #2800 as a reminder that F87 is on deck for removal once the PR is merged.