RE: Non-text content loophole

You are referring to clause 11.7 in EN 301 549. It is very badly written as can be seen in the discussion about it at https://labs.etsi.org/rep/HF/en301549/-/issues/23


My interpretation is that it does not apply to web content, although the bad drafting certainly allows for other interpretations. Specifically, clause 11.0 says:


  1.  “NOTE 1: User agents are examples of software that provide a user interface.”

  2.  “This clause provides requirements for … software that provides a user interface including content that is in the software”. These two clauses together make it clear that your content does not provide the user interface – the browser does.

  3.  “NOTE 2: The requirements for Web content, including software that is Web content, can be found in clause 9.” You can’t get much clearer than that.

So, having made it clear that clause 11 does not apply to web content, the standard then starts to contradict itself.


  1.  “Requirements in clauses 11.1 to 11.5 apply to software … that is not a web page”. Why are clauses 11.6 to 11.8 not included? Why mention clauses 11.1 to 11.5 at all, having previously said that web content is covered by clause 9?

And then web content is re-introduced by clause 11.7 that you quoted below.

You can easily support either viewpoint by cherry picking specific clauses, but when taken as a whole it’s far less clear. This may not be the right place to discuss a European standard, but it’s arguably relevant if WCAG is considering adopting ideas from it.

Steve Green
Managing Director
Test Partners Ltd


From: Marc Haunschild <marc.haunschild@accessibility.consulting>
Sent: Thursday, November 23, 2023 3:31 PM
To: Patrick H. Lauke <redux@splintered.co.uk>
Cc: w3c-wai-ig@w3.org
Subject: Re: Non-text content loophole

Hi everybody,

In Europe we have the EN 301549, which includes WCAG 2.1 AA (2.2 is in work) but goes beyond.

Eher is a „SC“ that is called User Preferences:


Where Web-App is not designed to be isolated from its platform, and provides a user interface, that user interface shall follow the values of the user preferences for platform settings for: units of measurement, colour, contrast, font type, font size, and focus cursor except where they are overridden by the user.

NOTE 1: Web-App that is isolated from its underlying platform has no access to user settings in the platform and thus cannot adhere to them.

NOTE 2: For web content, the underlying platform is the user agent.

NOTE 3: This does not preclude the Web-App from having additional values for a setting as long as there is one mode where the application will follow the system settings even if more restricted.

So when you test this as SC you change preferences in the browser as the underlying platform of a website or web app and you check if everything still works.

Of course you don’t check for contrast. Maybe a person needs soft contrasts an its his/her choice.

But of course there are techniques that still work, when CSS backgrounds disappear. For example when using SVG you can work with currentColor, which is is the color of the font.

Also you can use images that bring their own background instead of transparent background and so on. Actually there is just one thing to address: things must be visible, when CSS backgrounds are gone and that is possible. There are many websites passing the tests (much more of course failing - but not because its impossible, just because the developers didn’t think about this).

--
Mit freundlichen Grüßen

Marc Haunschild - he / him - #gernPerDu
Prüfstelle im BIK-BITV-Prüfverbund

Marc Haunschild Accessibility Consulting
Sonnenhof 32
53119 Bonn

Telefon: 0170 8 64 00 63
Web: https://Accessibility.Consulting https://mhis.de

Email: Marc.Haunschild@Accessibility.Consulting<mailto:Marc.Haunschild@Accessibility.Consulting>


Am 23.11.2023 um 15:10 schrieb Patrick H. Lauke <redux@splintered.co.uk<mailto:redux@splintered.co.uk>>:

On 23/11/2023 13:05, Ms J wrote:

Hello
Sometimes authors use css background-color to create an image conveying information - like a styled div as the check mark for a radio button. This means background colours can't be customised as you can't tell when the checkbox is checked or not. CSS ::content and background-images fail A. However, this seems like it doesn't fail at all? The information is programmatically determinable for screen reader users as the input is there 'behind the scenes'. It's just that low vision users can't change background colours.
This also happens with focus indicators a lot where the default one is disabled but the custom one uses background-colors. I feel like there should be a fail for conveying visual information with background-colors alone. What is the general thought on this?

You're right in your assessment that WCAG does not cover scenarios where a user may have changed things (e.g. added user styles that modify the site's CSS, or switched into forced colours/high contrast modes).

It's something that future versions of WCAG may try to tackle, but because it's difficult to explicitly pinpoint exact do's and don't's (as users may potentially change all sorts of aspects of a site's presentation; even high contrast/forced colours aren't necessarily standardised in how they modify things), and also to determine at which point site authors are responsible for foreseeing any possible changes a user may make, I'd hazard a guess that it will be difficult.

P
--
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke

https://flickr.com/photos/redux/ | https://www.deviantart.com/redux

https://mastodon.social/@patrick_h_lauke | skype: patrick_h_lauke