F87 and custom-styled form controls

[JamesCatt]

It's a common practice to visually hide checkbox/radio buttons and use pseudo elements to provide custom-styled alternatives (for example, see https://www.w3schools.com/howto/howto_css_custom_checkbox.asp)

I'm curious what the WG thinks of this practice and whether or not it should be considered a failure of F87.

On the one hand, it does seem to go against the spirit of F87, as the technique involves using pseudo elements to communicate essential information (i.e., the presence and state of a checkbox or radio button). If a user has a custom stylesheet, this information could be lost.

On the other hand, if a user is indeed using a custom stylesheet with pseudo elements for checkboxes/radio buttons, then it may not actually matter that the author-supplied styling is lost—it would simply be replaced by the user styling.

The current wording of the test scenario is somewhat vague:

Check that non-decorative information presented by the generated content is available when styles are overridden.

This could be interpreted in a way that passes—if the user has custom styles defined for checkboxes/radio buttons and their states which simply override the author-supplied styles, then no information would be lost to the user. It could also be possible for the two sets of styling to conflict in a way that makes it incomprehensible. It really depends on what styles each is introducing and how they interact with one another.

[patrickhlauke]

I would say this practice is fine, and doesn't clash with the intent of F87 (since F87, from my reading, is intended to prevent situations where the CSS pseudo elements are the ONLY place where this additional content is defined/presented, whereas the custom checkbox/radio scenario is a progressive enhancement to what is already defined in the markup). Yes, custom stylesheet users may be affected if their custom stylesheets don't cover these situations...but that is up to the users and their custom stylesheets. And yes, if users disable stylesheets altogether, then they'll just see the regular unstyled checks/radios.

[JAWS-test]

If I understand it correctly, it is as follows:

• earlier (when F87 was developed) CSS content was banned because a) screen readers didn't output it and b) pages without CSS should work. Both are no longer relevant today, because a) CSS content is part of the Accessible Name according to the specification and b) it is no longer assumed that CSS is disabled.
• Today, the issue is that users use their own user styles and overwrite the existing CSS, e.g. with a different font.

Unfortunately, F87 was not properly adapted to the new situation and the examples contradict the mentioned intention. You get a better impression with ARIA24. According to ARIA24 it would be okay if the CSS graphics were marked with role=img, because then the user styles do not exchange the graphics. Of course, this assumes that all users of user styles know this. To what extent this is actually the case is of course very questionable...

In your example, however, the checkboxes and radio buttons are not created with CSS font icons (which can be overwritten with userstyles), but with background color and the border attribute. This should not be affected by the relevant userstyles. The problem, however, is that the checkboxes and radio buttons are not visible when adjusting the contrast (the radio buttons in both states, the checkbox only if it is not checked). To what extent High Contrast Mode must be supported according to WCAG is very controversial here. Personally, I consider the wrong display in the High Contrast Mode to be a violation of SC 1.3.1.

Also not nice (though not a violation of the WCAG) is that with CSS disabled, the labels are in front of the radiobuttons and checkboxes and not behind them.

However, the example includes 2 violations of the WCAG:

• SC 2.4.7: Focus is not visible
• SC 1.4.11: Contrast of the unchecked radio buttons and checkboxes is not sufficient with 1.2:1

[JAWS-test]

See also: #907

[alastc]

It's a common practice to visually hide checkbox/radio buttons and use pseudo elements to provide custom-styled alternatives

I'd say (chair hat off) that this is a separate technique from (only) adding content with CSS. In F87 it is talking about turning CSS off and that content disapearing.

In that technique from W3schools, it is hiding accessible content behind inserted content, so when you turn styles off you still have the default content.

Keep in mind there are two scenarios for user-adjusted styles:

1. Completely over-riding the default CSS, so you drop the author-provided CSS and replace it with your own.
2. Adding adjustments to the author-provided CSS.

F87 helps in the first case.

There is some discussion at the moment about requiring visual indicators, and whether user-side CSS could acheive that. Like the W3schools example, case (2) an be affected because the element the user's CSS would act on is hidden. However, there isn't a decision on that yet.

Do the above comments answer the question @JamesCatt?

[JAWS-test]

@alastc

Completely over-riding the default CSS, so you drop the author-provided CSS and replace it with your own.

Is this actually a WCAG scenario. i.e. pages that are not displayed correctly without CSS violate SC 1.3.1? If so, then ARIA24 would not be a technique to comply with SC 1.3.1...

[alastc]

It is a user scenario, there are aspects of WCAG to help with that e.g. F87.

ARIA24 is aimed more at a scenario where there is more limited over-riding, e.g. changing font-styles.

The core is that (where there are appropriate structures available) the design is represented in the code (for 1.3.1).

[JAWS-test]

@alastc
I don't understand this: If 1.3.1 requires that all content must be in source code and not only be transmitted via CSS, then ARIA24 would be wrong and should be deleted (there shouldn't be any technology that meets one criterion but at the same time violates others, should there?) Therefore my question would be: does 1.3.1 require that even without CSS all content is correct and fully perceptible?

In general, I would like to see that the recommended techniques and examples do not violate the WCAG: for example, when I look at https://www.w3.org/WAI/WCAG21/working-examples/aria-icon-font-img-role/, I find that the contrasts of the stars are not sufficient (SC 1.4.11) and when adjusting the text spaces, the stars are not displayed correctly (SC 1.4.12).

[alastc]

If 1.3.1 requires that all content must be in source code and not only be transmitted via CSS, then ARIA24 would be wrong...

The 'content' is in the source code, each example in ARIA has an alt text / label.

In general, I would like to see that the recommended techniques and examples do not violate the WCAG

In general I would to, but we're all volunteering our time trying to get as much done as we can, please feel free to make a pull request to fix the aria-icon example.

[JAWS-test]

The 'content' is in the source code, each example in ARIA has an alt text / label.

Does this mean: If users completely overwrite or disable CSS in the browser according to WCAG, do they have to display alt texts and ARIA labels? I've never read about that. If so, it should certainly be mentioned in the Understanding.

please feel free to make a pull request to fix the aria-icon example.

I'd love to do that, but I'm either too stupid or the usability of GitHub is too bad: I haven't figured out how to do a single PR yet. With me, all changes are always assigned to the same PR. See #912

[alastc]

It means that in the millions of ways websites can put things together, and the millions of ways users can adapt websites, there are certain things that have been identified to help. We can't document every combination, and it would probably be counter productive if we did.

From #912 I can't tell what the source repository was. I think you need to fork the WCAG repo into your own account, create a branch, make the changes, and then make a PR back to the W3C's repo:
https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request-from-a-fork

[awkawk]

Related to F87, we discussed this in #433 and actually I think that we came to the wrong decision. Since CSS can be a technology that is relied on, there is no reason that the information needs to be viewable when CSS is turned off in a browser. If the content is conveyed to assistive technologies appropriately then using pseudo elements to deliver that content is fine. Last time we discussed this the AT support was not as solid as we would like, so doing this isn't thought to be the best way to deliver content, but it shouldn't be a failure either.

[alastc]

Thanks for the pointer to the old issue, I re-reviewed that. Previously we focused on font-icons, but there are a couple of different cases here:

1. CSS is used to create an image without an <img> tag, e.g. with background images applied to an element.
2. CSS Pseudo elements are used to add content, typically text content.
3. A combination of 1 & 2, e.g. the CSS uses pseudo elements to add background images.

What we were not focusing on before was the CSS-inserted content, which could be be important, such as things programmatically created from hidden attributes. E.g. the tooltips on the github editor buttons are added via pseudo elements.

The font-icons technique (ARIA24) means that people overriding fonts can stop over-riding those items (only).

From a user point of view I can still see three issues:

1. Someone dropping authored styles in favour of their own will lose generated content.
2. Someone with user-agent styles that use pseudo elements could lose generated content if it clashes. For example, if you use pseudo elements to show heading levels because you need maximum size text for everything, you would lose the site's generated content on headings. (Example page setup for same-sized headings with pseudo content added.)
3. Finding text from generated content.

I agree that CSS can be 'relied on' in an accessibility supported sense, but it is also a very manipulable technology (by design), which is why we have text-spacing and input-purpose. Turning CSS off is a convenient proxy test-method (if we still agree that's appropriate), without that we'll have to get more granular.

If the content is conveyed to assistive technologies appropriately then using pseudo elements to deliver that content is fine.

People with more extreme CSS over-rides don't have a mechanism to avoid killing-off pseudo element content, or to understand the programmatic alternatives. There isn't a way (that I know of) to consistently show the accessible name of something, or to avoid overriding whatever custom element (or inline style) the author used to generate the content.

ARIA24 was a method of tackling that problem for font-icons (supporting scenario 2 above), but other uses (like the examples in F87) are still a problem as there is no 'hook', no predictable structure to target.

Content added by before/after pseudo selectors is still very second-class, it can't provide any structure information and can't be 'found' by the browser. In relation to 1.3.1 it is content conveyed by the presentation layer, but it's presentation is not programmatically determinable or in findable text.

[JAWS-test]

From a user point of view I can still see three issues:
1 Someone dropping authored styles in favour of their own will lose generated content.
2 Someone with user-agent styles that use pseudo elements could lose generated content if it clashes. For example, if you use pseudo elements to show heading levels because you need maximum size text for everything, you would lose the site's generated content on headings. (Example page setup for same-sized headings with pseudo content added.)

@alastc:

If I take this seriously, examples 1-3 on ARIA24 must be removed because they generate CSS content that is relevant and would not be visible on your 2 issues. Only example 4 could remain because the content here is decorative.

The problem could be partially solved (issue 2) by inserting the icons in ARIA24 not as CSS content, but in the HTML source code.

[JamesCatt]

Hi all, thanks for the spirited discussion. In retrospect, I realize that citing the W3Schools example wasn't ideal, since it arguably also fails F3 for using a background-image (it will break in Windows High Contrast mode).

Example without background-image

To refocus on the main point of my post (specifically the use of pseudo-elements), we can consider the example of a radio button that uses pure CSS to achieve a certain visual presentation. For an example see here: https://codepen.io/jcatt/pen/mdyoLJd

• It doesn't affect semantics of the underlying <input>, so shouldn't impact any assistive technologies that rely on that information
• If CSS is removed entirely, the browser default radio button will re-appear
• Works in Windows High Contrast mode by leveraging CSS border
• If a user has custom styles to help them identify radio buttons, those styles will hopefully still work or replace the author styles, but there is a slight chance that they may conflict and break the experience.

It's the last point that I was mainly thinking about when opening the issue.

So in summary, I guess what I'm personally interested in is everyone's opinion on the following two questions:

1. Do you think this example is a failure of F87?
2. If not, do you think it's an acceptable technique? Or should something in WCAG be amended to prohibit it?

[JAWS-test]

I think:

1. it is not an error according to F87, because no content is added by CSS, which is not available without CSS
2. it is not a violation of the WCAG because there is no SC prohibiting this technique For example, SC 1.3.1 requires that all information can be "programmatically determined". This is the case here.
3. Whether it is an acceptable technique is a difficult question, since there is the possibility that someone with her/his own userstyles does not show the HTML checkbox, but overwrites the visual representation of the checkbox by CSS. In this rare case this would be a problem. I suggest that this problem be discussed further and then, if necessary, a new SC should be written

[jared-w-smith]

I'm going to bump this issue again. Pseudo-content is now very broadly supported in all major browsers and assistive technologies (IE being an exception in some cases). Browser are also now supporting alternative text for pseudo-content (https://www.w3.org/TR/css-content-3/#alt)/

F87 is overly broad in its prohibition of CSS-generated content (further verified by ARIA 24's sufficient technique which prescribes its use). This is leading to confusion.

I believe this failure needs to be scoped to the use cases where pseudo-content actually violates 1.3.1 or removed entirely.

[JAWS-test]

alternative text for pseudo-content doesn't work in Firefox and IE 11 and not very well in Chrome, see: FreedomScientific/standards-support#367

[jared-w-smith]

Yes, support is not yet complete for alternative text for pseudo-content, but I don't believe this means that pseudo-content cannot be used for text, links, decorative images, or other things that are supported.

[bruce-usab]

The current version of F87 includes this note in description:

A common way to test this critieria [sic] is to disable CSS styles to view whether content added using pseudo-elements remains visible.

That would indeed be a common way to test, but it could fail uses that are accessibility supported!

[3dots]

Can I get a final clarification on this?

I have tables that have css content icons in them which expand/hide content. Making them keyboard accessible was ok, but now I am not sure if I am still failing F87 or not despite ARIA24.
Here is a codepen similar to it.

Ultimately it's question of whether the first case is enough or I need the second one for when user disables css:

<!-- content = "+" With ARIA24 -->'
<td class="expandable" tabindex="0" role="img" aria-label="Expand section trigger"></td>
<!-- With ARIA24 vs F87 no CSS? -->
<td class="expandable" tabindex="0" role="img" aria-label="Expand section trigger">
    <span class="hidden">Expand section trigger</span>
</td>

[JAWS-test]

Can I get a final clarification on this?

I would like that too. But there are the following problems with your example independent of F87:

• role=img on td overwrites the table-semantics (violation of SC 1.3.1). the role=img should be located at an element within td
• The button has no suitable role (violation of SC 4.1.2). I.e., there should be a button within td. And an element with role=img within the button

[innoticFR]

The above pull request #1016 is removing the accessible name for the element (edit: this is more a problem with the aria-hidden attribute set on visible elements).

Elements with img role have the "Name from: author" and must have at least an aria-label or aria-labelledby attribute (which can be compatible with the sr-only approach).

I am not sure that this modification (making the text "visibly hidden" instead of using aria-label) might solve the problem addressed by ARIA24 which is changing the font-family, not disabling CSS. This may put the focus on the wrong problem and would minimize the impact of the solution (here giving the element the img role), if any (see: #1185)

I agree that for the current ticket this "scenario is a progressive enhancement to what is already defined in the markup" as @patrickhlauke said. Even if users blindly override CSS rules, they won't want to view hidden CSS elements.