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.