RE: Is Common Failure Technique F87: inserting non-decorative content by using ::before and ::after pseudo-elements; still valid?

Alan, see question near the end.

Steve,
Thanks for the link.

However,

  *   that gov.uk rationale was written in 2016. That page does load without CSS, as I would expect it to do since it was designed to do so back then. Kudos for that.
  *   the F87 technique was written earlier than 2015. It is actually a “hold over” from 1999 and WCAG 1.0’s checkpoint 6.1<https://www.w3.org/TR/WCAG10-TECHS/#tech-order-style-sheets>

Now, not that it is invalid just because it is “old”, but because the assumptions and rationale used to create the failure technique I assert to no longer be valid. A similar situation occurred when Success Criteria 4.1.1 is now obsolete and removed<https://www.w3.org/WAI/WCAG22/Understanding/parsing>.

| …  If you want to use CSS content, you just need to state that CSS is a “relied-on technology” in your accessibility statement.

OK, interesting view. So, is there general agreement that if/when the web site states that CSS is required, then F87 is no longer required to meet 1.3.1?

Now, back to the 2016 (1999-ish) non-accessibility rationale with [my comment in brackets]:

You should not assume the reason for designing a service that works without CSS or JavaScript is because a user chooses to switch these off. There are many situations when extra layers can fail to load or are filtered, for example:
·        temporary network errors [hmm, network errors impact HTML same as CSS]
·        third-party browser extensions like ad blockers [not accessibility related and now a browser setting.]
·        third-party supplier downtime, such as when using a content delivery network [not accessibility related and only affects that small part anyway]
·        DNS lookup failures [not sure what this has to do with CSS, unless the assumption is that the CSS is loaded from a different server? Same as if the HTML is loaded from a different server (but who does that today anyway?)]
·        bugs introduced by browser updates [impacts HTML same as CSS, nothing unique to accessibility]
·        corporate firewalls blocking, removing or changing content (large institutions like banks or government departments may use these) [hmm, need an example to make a judgement]
·        mobile network providers changing content to speed up load times and reduce bandwidth usage [need an example to make a judgement]
·        personal firewalls or antivirus software changing or blocking content [that is the user’s choice, and they can choose to turn it back on]
·        the use of unsecure connections, where internet providers insert their own code into the page that accidentally conflicts with your own [need an example where this even happens still, but really nothing to do with accessibility because I don’t see how turning off CSS turns off the internet service provider’s ability to “insert their own code”. Browsers themselves handle this now.]

In summary, those “many situations” are handled differently today by using redundant services and other approaches so that the user is never presented with situations like that anymore.

Alan,
|… people who disable all site-provided CSS and replace it all with their own CSS, designed to alleviate some visual requirement of theirs.

I just need an example of a visual requirement that can’t be alleviated other than disabling “all” CSS and replacing “all” of it with their own.  Is there an appearance setting that bowser need that isn’t already met, or an OS setting, plug-in, or AT/user agent that is already installed by the user that does not require turning off CSS?

Again, I’m still looing for “a web example where this “testing technique” would uncover a real accessibility problem. But I’m leaning towards the “CSS is required”, so F87 is no longer a valid failure technique/requirement.

_______
Regards,

Phill Jenkins
IBM Accessibility, IBM Design
Equal Access toolkit and accessibility checker at ibm.com/able/<https://www.ibm.com/able/>
“Without accessibility, there is no diversity and inclusion of people with disabilities”

From: Steve Green <steve.green@testpartners.co.uk>
Sent: Friday, March 15, 2024 3:00 PM
To: Bristow, Alan <Alan.Bristow@elections.ca>; Phill Jenkins <pjenkins@us.ibm.com>; WAI Interest Group discussion list <w3c-wai-ig@w3.org>
Subject: [EXTERNAL] RE: Is Common Failure Technique F87: inserting non-decorative content by using ::before and ::after pseudo-elements; still valid?

It’s still a valid success criterion. If you want to use CSS content, you just need to state that CSS is a “relied-on technology” in your accessibility statement. In the UK, it is a requirement that all central government
ZjQcmQRYFpfptBannerStart
This Message Is From an Untrusted Sender
You have not previously corresponded with this sender.
    Report Suspicious  <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/AdhS1Rd-!-_FXfhZeXk962ls5LqRBkbGE9rCPuT84QVYtXuOV0oLZR-U1B5bkt4q5CSbfmVl7U3k9X-vGC3H-Hcv1Y7TnCOO4VAif1HdR5JQSQR5V7iegtK2LjcjI4OpTh5oxgNrDThar2dUU4Mc$>   ‌
ZjQcmQRYFpfptBannerEnd
It’s still a valid success criterion. If you want to use CSS content, you just need to state that CSS is a “relied-on technology” in your accessibility statement.

In the UK, it is a requirement that all central government websites are usable without CSS, JavaScript or images. You can read their rationale at https://www.gov.uk/service-manual/technology/using-progressive-enhancement#do-not-assume-users-turn-off-css-or-javascript<https://www.gov.uk/service-manual/technology/using-progressive-enhancement#do-not-assume-users-turn-off-css-or-javascript>. But even if you don’t agree with it, you still need to comply with it if you’re building government websites.

I expect most people would agree that CSS content is an “accessibility supported technology” insofar as it is supported by the screen readers you mentioned. However, that does not mean it is supported by all text-to-speech applications such as more basic screen readers or literacy software. Nor does WCAG require an accessibility supported technology to be supported by every user agent. But the more technologies that are relied on, the more likely it is that some people will not be able to access the content.

Steve Green
Managing Director
Test Partners Ltd


From: Bristow, Alan <Alan.Bristow@elections.ca<mailto:Alan.Bristow@elections.ca>>
Sent: Friday, March 15, 2024 7:34 PM
To: Phill Jenkins <pjenkins@us.ibm.com<mailto:pjenkins@us.ibm.com>>; WAI Interest Group discussion list <w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>>
Subject: Re: Is Common Failure Technique F87: inserting non-decorative content by using ::before and ::after pseudo-elements; still valid?

I assume one reason it is(?) still valid is because of the people who disable all site-provided CSS and replace it all with their own CSS, designed to alleviate some visual requirement of theirs.

But. Although that would explain it still being valid, I have no idea if that is a theoretical edge-case that never actually happens, or, if it is a technique in use and hence F87 must remain valid.

Regards,

Alan

. . . . -   . . - - -
Alan Bristow ( he / him / il )
Web Developer / Développeur Web
Elections Canada / Élections Canada
alan.bristow@elections.ca<mailto:alan.bristow@elections.ca>

________________________________
From: Phill Jenkins <pjenkins@us.ibm.com<mailto:pjenkins@us.ibm.com>>
Sent: 15 March 2024 14:51
To: WAI Interest Group discussion list <w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>>
Subject: Is Common Failure Technique F87: inserting non-decorative content by using ::before and ::after pseudo-elements; still valid?

Ce message a été envoyé par un expéditeur externe. Veuillez faire preuve de prudence et ne pas cliquer sur les liens ou ouvrir les pièces jointes à moins de reconnaître l'expéditeur et de savoir que le contenu est sûr.

This message was sent from an external sender. Please exercise caution and do not click links or open attachments unless you recognize the sender and know the content is safe.



Regarding the WCAG 2.2 Technique F87:

Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using ::before and ::after pseudo-elements and the 'content' property in CSS

https://www.w3.org/WAI/WCAG22/Techniques/failures/F87<https://www.w3.org/WAI/WCAG22/Techniques/failures/F87>



  1.  Does anyone agree that F87 is no longer a valid failure technique?

     *   Quote: “A common way to test [this criterion]* is to disable CSS styles to view whether content added using pseudo-elements remains visible.” Who in 2024 disables CSS anymore (and why)?  Disabling CSS and JavaScript is not a valid “disability” test in my opinion.
     *   JAWS and free screen readers VoiceOver and NVDA support reading the content, including non-decorative content.
     *   Quote: “…they may not be able to access the information that is inserted using CSS” is not explained why this is still valid even when users load their own CSS.  If they load their own CSS, they are not disabling CSS & JavaScript.

  1.  Can anyone provide a web example where this “testing technique” would uncover a real accessibility problem?



The text ”this critiera” is a typo on the W3C WAI page.