RE: Plugins as SC - thread was: Visual Indicators

Hi Alastair,

>> That works when you are in the context of a particular pattern library and development approach

This is the standard scenario in large companies creating UI frameworks and for content builder tools, something that should be treated with more priority within the WCAG group, INHO. 

I did not knew that you have already thought and prepared material like 
https://service-manual.nhs.uk/accessibility/development#test-that-text-sizes-and-zooms-correctly

https://alastairc.ac/2017/02/four-levels-of-accessibility-customisation/


Very good! And I also understand that sometimes for one requirement something is forbidden code-wise whereas it passes others.

>> The TL;DR is that things which try to over-ride layout tend not to work, that's where you run into really big issues

I highly agree but with this we are back in the "don't get in my way" common requirement realm. 

Let's put my question different: *How many WCAG requirements* do currently strictly *require* the usage of 3rd party tools (exception: screen readers) to have the desired effect (with described SC met) for users with disabilities?

Definition of 3rd party tool: everything what is NOT OS, browser, builder framework or app setting

I think "less as possible" should be the design approach here. Do you agree?

And please allow me a last comment: Saying "browsers won't implement that, therefore you can and have to use external tools" removes all the pressure from the browser vendors. Like saying to kids "You don't need to learn to swim, there are boats". 

Best Regards
Stefan



-----Original Message-----
From: Alastair Campbell <acampbell@nomensa.com> 
Sent: Sunday, April 19, 2020 8:20 PM
To: Schnabel, Stefan <stefan.schnabel@sap.com>
Cc: w3c-wai-gl@w3.org
Subject: RE: Plugins as SC - thread was: Visual Indicators

Hi Stefan,

 > why are the whole prerequisites for the text spacing requirement also not part of 
 https://www.w3.org/TR/WCAG21/#reflow?


Mainly because it is a different requirement, you could pass reflow with fixed size boxes.

Of course, when you approach from a good-practice point of view you can combine text-size, text-spacing and reflow together. For example, as part of a project I contributed this to the NHS service manual:
https://service-manual.nhs.uk/accessibility/development#test-that-text-sizes-and-zooms-correctly 

That works when you are in the context of a particular pattern library and development approach. However, sites in general can and do fail one or the other, and the issues they cause for users could be based on one or the other.

It would also make the SC text itself much more complex, and the already long understanding documents would be huge when combined.

When we were working on 2.1 I wrote down my thoughts on levels of accessibility customisation: https://alastairc.ac/2017/02/four-levels-of-accessibility-customisation/ 

That might provide some help in thinking about the cut-off between "don't break it" and more active customisation. The TL;DR is that things which try to over-ride layout tend not to work, that's where you run into really big issues.

Cheers,

-Alastair

Received on Monday, 20 April 2020 08:58:43 UTC