Failure technique F87 contradicts the Accessible name and desc algorithm

[Wildebrew]

The Accessible name and description algorithm (v1.1) describes how content included using the CSS :before and :after pseudo classes should be included in the accessible name calculation for an element.
This actually works with most browser and screen reader combinations, see my CSS pseudo classes for screen readers Code Pen example.
But WCAG 2.0 Failure technique 87 forbids use of CSS content to communicate information.

Since CSS content is now a part of an element's accessible name, the WCAG spec can no longer outlaw its use, in my opinion.

I believe F87 pre dates the ANDC algorithm by a few years and the web techniques landscape has changed. In light of that I recommend updating this technique to say somethihg like "whereas CSS content can be used to communicate helpful information about an element it should not be used for essential information" altogether.
or to drop it.

[awkawk]

Thanks @Wildebrew

Arguments to keep it:

1. The test procedure requires that one checks whether the information is read by AT so if the content is read then the failure won't apply.

Arguments to remove it:

1. AT support is much better now than when this technique was authored.
2. The technique ignores that CSS is a technology that can be relied on, so it isn't appropriate to require that the information is available when CSS is off.

[mraccess77]

Personal thoughts - I belove it is not supported by screen readers in IE. Seems like pseudo elwmrns also complicates the situation for low vision users who use custom css fonts/color.

[Wildebrew]

I don't think we can consider IE11 (or MS Edge) as the mainstay of accessibility support anymore. The browser landscape is changing, even for assistive technology users. IE11 is no longer being updated and Edge is barely used (see the WebAIM screen reader survey #7 for numbers). From a screen reader user perspective I don't think lack of IE11 support is sufficient to mark something as a failure. The low vision/custom CSS stylesheet argument I can definitely see the point, but then the wording of F87 should be changed to explain that the failure is primarily related to the problems of users relying on custom style sheets. I wonder if custom style sheets can be written that preserve the content of pseudo elements. My CSS background is admittedly not strong enough to provide the answer on that.

…

On 7/28/18, Jonathan Avila ***@***.***> wrote: Personal thoughts - I belove it is not supported by screen readers in IE. Seems like pseudo elwmrns also complicates the situation for low vision users who use custom css fonts/color. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #433 (comment)

-- Work hard. Have fun. Make history.

[lauracarlson]

Hello everyone,

@mraccess77 wrote:

Seems like pseudo elements also complicates the situation for low vision users who use custom css fonts/color.

@Wildebrew wrote:

The low vision/custom CSS stylesheet argument I can definitely see the point, but then the wording of F87 should be changed to explain that the failure is primarily related to the problems of users relying on custom style sheets. I wonder if custom style sheets can be written that preserve the content of pseudo elements. My CSS background is admittedly not strong enough to provide the answer on that.

+1 to the adding wording to F87 to explain the failure for user style sheets. @mraccess77 , @WayneEDick, @alastc, @allanj-uaag do you have suggestions on how best to word it? Jim, maybe add it to a LVTF agenda?

Related: A draft "Providing a Semantically Identified Icon Font with role=img" technique is in the Wiki.

[awkawk]

Do we want to fail any content based on what a user style sheet does? How easy is it for a user to inadvertently cause the pseudo content to not display?

[Wildebrew]

My concerns with the user style sheet argument is that it should equally apply to icon fonts and CSS images. Using role="img" and aria-label you can make these images accessible and they are frequently used (e.g. emojis). But if CSS images are ok, can we fail use of pseudo element content?

…

On 7/30/18, Andrew Kirkpatrick ***@***.***> wrote: Do we want to fail any content based on what a user style sheet does? How easy is it for a user to inadvertently cause the pseudo content to not display? -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #433 (comment)

-- Work hard. Have fun. Make history.

[alastc]

Since CSS content is now a part of an element's accessible name, the WCAG spec can no longer outlaw its use, in my opinion.

Except that the description does primarily aim it at people who override / don’t use CSS. The point about CSS being a tech that can be relied on is valid, but the fact the acc-name calc includes CSS content doesn’t help/affect those using customised visual access.

Having said that, there are a couple of levels to customisation: You can start with the authored styles and over-ride them (e.g. with stylus plugin), which wouldn’t remove the before/after content. The windows high-contast mode is at the upper end of that, it does/did remove background images. Or the next level is that you can wipe out the author styles and only apply your styles, which would remove the before/after content. (I think the ‘reader’ view in some browsers would do that.)

We could update the 3rd part of the procedure to remove assistive tech, but I’m not sure that’s needed depending on your accessibility support statement? (I.e. if you’re relying on modern user-agents then it will automatically pass.)

I agree this should also apply to icon fonts & CSS images, there is a technique drafted somewhere for that... @lauracarlson?

[lauracarlson]

Hi @awkawk

Do we want to fail any content based on what a user style sheet does?

I don't think so. I was thinking that the failure would be on authors for not providing role=img so that the user style sheet can hook to that. Check the draft "Providing a Semantically Identified Icon Font with role=img" technique in the Wiki.

[lauracarlson]

Hi @alastc

I agree this should also apply to icon fonts & CSS images, there is a technique drafted somewhere for that... @lauracarlson?

Yes. It is "Providing a Semantically Identified Icon Font with role=img" in the Wiki.

[lauracarlson]

Hi @awkawk,

You wrote:

How easy is it for a user to inadvertently cause the pseudo content to not display?

Pretty easily. As Alex Walker explained in The Final Nail in the Icon Fonts Coffin?, when a when a user overrides fonts, "they replace the alphanumeric characters but there are no replacements for these custom icons. We get left with big, ugly, unhelpful empty boxes instead."

Seren Davies goes into more detail in her Death to icon fonts presentation (Video) and speaker deck.

As for frequency Tyler Sticka states, They Fail Poorly and Often.

[awkawk]

Are we talking about icon fonts or :before content more broadly?

[lauracarlson]

Hi awkawk,

Are we talking about icon fonts or :before content more broadly?

I am concerned about icon fonts added via generated content. The LVTF and/or COGA may have broader concerns.

[awkawk]

I think that we should figure out the answer to the question about generated content in general first?

[lauracarlson]

Hi @awkawk,

You wrote:

I think that we should figure out the answer to the question about generated content in general first?

Do mean as F87 states general generated content items, for

users who need to customize or turn off style information in order to view content according to their needs, assistive technologies may not be able to access the information that is inserted using CSS

Alastair listed some examples: overriding authored styles via stylus plugin, windows high-contrast, direct application of user styles). After those he listed icon fonts & CSS images.

As @alastc said, "the fact the acc-name calc includes CSS content doesn’t help/affect those using customised visual access."

[awkawk]

@lauracarlson What I mean is that we need to answer the question "is all non-decorative content provided as generated content in CSS a failure of WCAG's 1.3.1 SC?"

It is possible that the broad answer is no, but that some specific cases are.

This failure was easier when it was made because we didn't need to understand all of the low-vision access questions since the screen readers didn't read the content. Now that most screen readers seem to read it, we need to determine if the low vision questions suggest that it should still be a failure.

[lauracarlson]

@awkawk ,

Thank you.

[Wildebrew]

Based on my understanding of this discussion it is possible to create CSS style sheets that do not remove CSS generated content. Windows high contrast mode is the only operating system high contrast mode that removes CSS images, at least that's what I am given to understand. CSS generated content is included in the the accessible name calculation algorithm and is picked up by most browser/screen reader combinations. There are, in fact, strong use cases for using CSS content to communicate information about focusable elements, e.g. to indicate links to PDF files or links that open in a new window or links to footnotes through a combination of an icon and visually hidden CSS content (better UI and accessibility support and easier to code than title attributes). Therefore, if I may venture an outsider's opinion, I feel it is too strong to list this as a failure technique. A failure technique is equivalent to saying coding something a certain way violates the relevant WCAG success criteria. While I see that there are potential accessibility issues with using CSS pseudo elements, I feel it is too strong to outlaw the technique by making it anWCAG failure. At minimum the documentation in the technique needs to be changed to reflect potential issues with screen magnifier users, my recommendation is that the technique should be removed as a failure technique but included in the "understanding" documentation of relevant success criteria with adequate warnings about potential user impact. Obviously, the final decision lies with the working group, and you have my 100% confidence.

…

On 7/30/18, Andrew Kirkpatrick ***@***.***> wrote: @lauracarlson What I mean is that we need to answer the question "is all non-decorative content provided as generated content in CSS a failure of WCAG's 1.3.1 SC?" It is possible that the broad answer is no, but that some specific cases are. This failure was easier when it was made because we didn't need to understand all of the low-vision access questions since the screen readers didn't read the content. Now that most screen readers seem to read it, we need to determine if the low vision questions suggest that it should still be a failure. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #433 (comment)

-- Work hard. Have fun. Make history.

[mbgower]

Adding my low-tech review, it looks like the :before :after pseudo elements come at the tail end (step 6 of 7) of a cumulative accessible name process, and their use is pretty contained:

Otherwise, if the current node's role allows name from content, or if the current node is referenced by aria-labelledby, aria-describedby, or is a native host language text alternative element (e.g. label in HTML), or is a descendant of a native host language text alternative element:

Given the points raised by @Wildebrew, I think adding some additional text/explanation to the Failure is pretty crucial -- as @awkawk says, the test procedure can be passed where it is implemented properly -- and I think the wording of the title needs to be qualified.

But I'm a bit leery of it being removed entirely. At a minimum there should some solid testing to confirm AT support and determine how frequently things can be screwed up through improper use the pseudo elements.

[mraccess77]

I don’t think you can provide role img for pseudo content only for the element as a whole.

[WayneEDick]

I use pseudo elements in my style sheets to show heading level and identify links without underlined text.
h1:before{
content:'. ';
}
h2:before{
content:'.. ';
}
h3:before{
content:'... ';
}
h4:before{
content:'... . ';
}
h5:before{
content:'.... .. ';
}
h6:before{
content:'... ... ';
}
a[href]:before{
content:'[';
}
a[href]:after{
content:']';
}

Best Wayne

[awkawk]

Wayne, here's a page with the examples in it - what happens with your stylesheet is added to the rendering? http://awkawk.github.io/f87.html

[WayneEDick]

Thanks, I need to study that page before tomorow. Best Wayne

…

On Wed, Aug 1, 2018 at 10:06 AM Andrew Kirkpatrick ***@***.***> wrote: Wayne, here's a page with the examples in it - what happens with your stylesheet is added to the rendering? http://awkawk.github.io/f87.html — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#433 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH0OFzIHE22VVrz8wCCUg-FZqSmb6aIwks5uMeAWgaJpZM4VRIA3> .

[WayneEDick]

I think we should remove the technique. There are problems, but most are solvable. The questions to ask are:
Drawbacks:
Are there any identified ambiguities: They would be programmatically non-deterministic constructs.
I am not sure how to insert an icon font into a pseudo element. Can someone give me an example. We cannot insert roles into inserted content. They are flat, so we cannot insert elements. This is a real problem. ARIA label and labelledby. So, I am not sure ambiguities exist or if they do, are they in conflict with WCAG 2.1.

Advantages: if we included generated content into the accessible domain, generated would have to obey all of WCAG 2.1. That would have many more advantages than drawbacks.

We are living in a world where, like it or not, CSS content is semantic content in web pages. Maybe it's time to figure how to include it. This is a good discussion

Best, Wayne

[WayneEDick]

I found a pseudo element with an icon value in StackOverflow.
div:before {
content: attr(data-background-icon);
font-family: "FontAwesome";
}

The following code shows how role =='img' can be enforced.

<title>icon psudo with div</title> <style> div[role="img"]:before { content: attr(data-background-icon); font-family: "FontAwesome"; } </style>

div without role.

div with role='img'.

Run it and see. The trick is only show the pseudo if the author added role=img to the element.

Could our own attribute like data-pseudo-role. The key is it can be designated.
Best Wayne

[mraccess77]

Regarding role img -- What I'm trying to say is that you have to apply the role to the whole element. So if you had a link with text and pseudo before content with a font icon you would have to apply to role img to the whole link. In that case if your user style did not apply a custom font on role's with img then the custom font would not be applied to the link element text or it's pseudo element. While that might be good for the pseudo content to not lose it's font-family the link would not changed to my preferred font.

Regarding replacement of pseudo content in your link/heading example -- say I have a link with pseudo content with some icon to indicate a new window. In your @WayneEDick example of adding content via user style sheets with pseudo element -- any content you added to distinguish links without underline (brackets) would then wipe out the author supplied pseudo content for the link with the icon showing that it opened a new window. Then you would loose information that was available to other people.

For what it's worth I don't seem to be able to select the text of pseudo content with the mouse or caret browsing mode in Chrome or Firefox.

[awkawk]

@WayneEDick Can you describe how the example page worked with your user styles?

[mraccess77]

Browser also don't include the text of pseudo elements in their find feature.

[Wildebrew]

I agree that CSS element content should not be used for important info e.g. as the sole source of an elements accessible name. The primary use cases I see for it are to indicate contextual information about elements, e.g. links that open in a new tab, open a PDF or point to footnotes. Sure, the title attribute can be used, but it is poorly supported and it requires a lot more development work to put title attributes on all individual links to footnotes, whereas it takes one CSS class to add this information, provided all the elements can be included with a single CSS selector. Visually such links often have icons or other visual cues, for a screen reader user this is the most efficient way to provide a text equivalent to those clues. I understand and agree with general concerns with CSS pseudo elements, but I personally do not agree that the solution is simply to forbid their use because of accessibility, because I see legitimate use cases and they are a part of the accessible name algorithm, which they shouldn't be if WCAG outright forbids their use.

…

On 8/2/18, Jonathan Avila ***@***.***> wrote: Browser also don't include the text of pseudo elements in their find feature. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #433 (comment)

-- Work hard. Have fun. Make history.

[WayneEDick]

Hi,
I've been looking at @Wildebrew comment. On icon links with visually hidden directions for non-visual users.

So I constructed the following:

14th Amendment, US Constitution

Wouldn't this achieve the same result?

Wayne

[WayneEDick]

Oops, I forgot and used live code.

<a href="http://www.nosetothepage.org/508/14thAmmend.html" aria-label="go to 14th Amendment"><i class="fas fa-arrow-alt-circle-right"</i> 14th Amendment, US Constitution</a>

Did I get your case wrong. If I got wrong why is aria-label not OK.

Wayne

[lauracarlson]

• Related minutes from the Low Vision Task Force's August 2 meeting
• Wayne's email to LVTF regarding generated content

[WayneEDick]

Hi All,
I've been working on this problem. As I mentioned earlier, I would like generated content to be accessible. Unfortunately it is not. There are two factors that really make it inaccessible:

1. Generated content is completely flat, it has no semantic structure. A <div> has considerable structure by comparison: class, id, role are available etc.. Pseudo elements are truly void of semantics.
2. Browsers cannot find content values for generated content. If it is anything but decorative, users will not be able to search for important information.

These two factors eliminate generated content from pseudo elements from accessibility. The Failure 87 should stand with updated documentation.

What can be done:
The ARIA group included the generated content in pseudo elements in accessible names before there was any semantic support for the content.

I think we could include content from pseudo elements if ARIA group defined some aria-pseudo parameters. It would be important for these to be accessible from CSS so that assistive stylesheets could use them. Also, we must contact browsers to learn what is needed so that find-algorithms can find pseudo element content.

[alastc]

I think the change we are coming to is simply updating the 3rd part of the procedure from:

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.

To:

3. If the inserted content is not decorative check that the information is also available when CSS is turned off.

Where @Wildebrew said:

I see legitimate use cases and they are a part of the accessible name algorithm, which they shouldn't be if WCAG outright forbids their use.

That assumes that "AT" is things which use accessible name, which is not always the case. Here the AT could be (as outlined in the description) something which over-rides CSS.

Just because they aren't valid as the only way to convey information doesn't mean they should not convey information to people who can access that way.

[alastc]

I think the summary of current status is that:

• Screenreaders have generally caught up and can deal with pseudo content.
• It is still an issue for people who over-ride the styles, that content can disappear, and is not searchable with browsers.

To try and condense this to two options:

1. We keep the failure, but remove the 'with assistive technologies' phrases.
2. We remove the failure.

I've created a PR (#473) so you can see the change from option 1.

So, if people agree that this is still an issue, is that change sufficient?

[lauracarlson]

Wayne's analysis

[awkawk]

Addressed in Pull request #473 - closing this issue.