It appears Pseudo elements pass AXE but fail F87 in WCAG

[DavidMacDonald]

We had a discussion on WCAG call today regarding removal of the F87 Technique to fail content added with CSS psuedo Elements.

https://www.w3.org/TR/WCAG20-TECHS/F87.html

Some on the group proposed removing the failure including me, because most AT Browser combinations read this content. However, others said that:

• content added with CSS Pseudo elements will cause user style sheets that had pseudo elements to override the content
• that it makes it impossible to find the content CTRL+F in a browser
• doesn't work in IE 11 which is still prevelant.

So there was not consensus to remove F87 and technically a failure of WCAG to use this content. The WCAG group is not intending to remove the failure. Seems easy to identify this failure automatically in AXE. I propose adding a check.

To test current status:
http://davidmacd.com/blog/inserting-content-with-css-accessibility.html
Run axe on the page, no failure of the use of Pseudo elements.

[jeeyyy]

@DavidMacDonald
Thanks for this.
Sounds like a good rule to add, are you looking to contribute the rule/check?
In the meantime, We will discuss internally on the viability of adding this & update the issue accordingly.

[DavidMacDonald]

https://www.w3.org/2018/09/11-ag-minutes.html#item02

[DavidMacDonald]

Here is the test procedure from F87

1. Examine all content inserted through use of the :before and :after pseudo-elements and the content property
2. Verify that the content is decorative.
3. 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.
   Expected Results
   If checks check for window object #2 or Image-alt rule should support role="presentation" #3 are false, then this failure condition applies and the content fails this Success Criterion.

Probably, AXE won't know if its decorative or not. It could check to see if the inserted content is text and if so fail it, given that text is not decorative by its nature. If its an image then let it pass, or flag it for a manual check or best practise.

[WilcoFiers]

Interesting idea David. Firstly, axe-core currently doesn't take pseudo elements into consideration at all. Unfortunately there are no DOM APIs that let us even get access to them. We are working on a work-around that involves fetching external style sheets and reading out the CSSOM. We're currently experimenting with this approach, and it would potentially let us take pseudo elements into consideration for the accessible name computation.

Your testing page is fantastically helpful. I wasn't aware that IE11 doesn't support this. Since axe-core's support baseline includes IE11, that tells me we shouldn't take pseudo content into consideration by default, but it also makes sense that we add an option to allow it. That closes an open issue #880.

I like Jey's idea of a rule that looks for this, but as you correctly point out, how do we assess that there's actual content being injected? Even harder would be to tell if it's not redundant content. Perhaps we can create a rule that does:

1. Check that elements with pseudo content have an accessible name even if that pseudo content doesn't exist.
2. Flag pseudo content that is more than a single character long for review, as a potential issue with IE11.

[mfairchild365]

Relevant: Dragon Naturally Speaking doesn't take CSS generated content into account either. https://a11ysupport.io/tests/html_label_element_css_content_aam

[dylanb]

Additional concern https://codepen.io/stevef/post/exceedingly-short-note-on-css-content-as-accessible-name

[WilcoFiers]

Since I last looked at this, we started looking at pseudo elements in the color-contrast rule. We can probably extend the logic of that to virtual nodes, so that we can make use of pseudo elements in the accessible name computation. It's something I would like to do for a 5.0 release, where I'm hoping we may drop the quirks we're still supporting for IE.