Re: Non-text content loophole

Hi Steve,

You’re absolutely right but it’s even more complicated in Germany. I don't want to go in the details because while the European Union with half a billion people and quite some influence in the world can be seen as an relevant area for trying things out that might be adopted by a specification that influences countries and their laws all over the world, the particular situation in a single EU member state is neither relevant nor its always the best decisions that we make here.

Nevertheless it’s great to have such a standard that addresses the needs for disabled people even broader than WCAG. I think this is very progressive and the WG is free to adopt and rewrite ideas from EN.

You mentioned ETSI and I think you are aware of the process that already started to deliver „the best EN version we ever made“ to quote Jim Cook. ;-)

But I mentioned it here only because of the practical implications. There are techniques to address the problem that UI components might disappear when users change background color to their own preferences. CSS backgrounds just are not a good idea to replace UI components visually. And honestly: this „technique“ is called checkbox hack. It’s in the word! It's called „hack“ for a reason.

I never felt comfortable with this although I experimented with it for quite some while but all the results still were hacks with all kind of issues for UX and a11y. It was a dead end. And it still is in my opinion.

Also: Although I had to deliver what designers wanted I never got the reason. What’s wrong with a UI interface, that everybody recognises and that looks and feels familiar and does its job? Why change a running system? They say the default look is ugly. But a few years later the same designers explain me why this look they have created themselves and that had to be implemented now is not beautiful anymore. sigh… that's a clever way to keep the money coming.

„Hey - look at these inputs. It’s so boring that they are squares and have a label in front of them. Let’s spice thinks up, remove the lines, that make it look like a input, put the labels just anywhere where they look much more fancy and let’s get some popcorn and laugh at the users that try to send a form."

In my opinion they don't have to be „beautiful“. They must be familiar, predictable, perceivable, operable, understandable, robust - hey where did I hear these things?!? Sounds familiar. ;-)

But - you can’t argue with „That looks ugly“…

A nice evening to all of you!

Marc


> Am 23.11.2023 um 19:52 schrieb Steve Green <steve.green@testpartners.co.uk>:
> 
> 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:
>  
> “NOTE 1: User agents are examples of software that provide a user interface.”
> 
> “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.
> 
> “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.
>  
> “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://accessibility.consulting/> https://mhis.de <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
>