Is the assumption behind technique F87 still valid (meta issue) about wcag HOT 11 OPEN

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.

from wcag.

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

from wcag.

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?

from wcag.

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

from wcag.

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.

from wcag.

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.

from wcag.

@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.

from wcag.

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?

from wcag.

not being able to search for the pseudo content

Firefox can search for it, Chrome can not

from wcag.

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.

from wcag.

@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.

from wcag.