RE: Plugins as SC - thread was: Visual Indicators

Hi Alastair,

Yes that helps, thanks again. 

I think the summary below is very interesting and has not been assembled before with this viewpoint:

- Orientation (physical cradles)
- Identify input purpose (icons set additions). ?
- Text spacing (Font or CSS overrides in various forms)
- Content on hover (magnification).
- Character key shortcuts (voice input) ?
- Label in name (voice input) ?

It will give enough food for thought for a while. For the items with "?" I don't know exactly what you mean. Would you please mind to comment a bit for what external tools are needed there?
 
>> As another example, if the browsers all implemented highly visible focus styles (or even an option to enable that) then the new focus-visible SC would be fulfilled without the author having to do anything.

This is what I meant, there or in build frameworks this is a feature that removes the need for external tools or plugins and should be the preferred approach, no normative requirement raised by a W3C group. All I advocate for (and of course the group can have another or no strong opinion on that) is that *built-in* is always better than *bolt-on* for users. Nothing more.

Best Regards
Stefan


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

Hi Stefan,

 > 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. 

My point was that the documentation for different organisations and/or frameworks about *their* most effective way to be accessible would be different. The documentation we do for each organisation is different, even though it uses the requirements from WCAG as the baseline.

However, WCAG needs to work across different organisations and approaches, we cannot be opinionated about that.


 > 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?

The guidelines are written to be about the content, so the relationship is rarely direct. There are quite a few that primarily benefit screenreaders but also benefits others in other scenarios.

Trying to keep to your point though, these come to mind (at level AA): 
- Orientation (physical cradles)
- Identify input purpose (icons set additions).
- Text spacing (Font or CSS overrides in various forms)
- Content on hover (magnification).
- Character key shortcuts (voice input)
- Label in name (voice input)

The more user-requirements we aim for, the more likely it is that we expand beyond current browser/AT features.


 > Saying "browsers won't implement that, therefore you can and have to use external tools" removes all the pressure from the browser vendors. 

As a working group, we have no direct influence with browser vendors and I can't comment on their priorities or approaches.

What we can do is write criteria that can be fulfilled by either authors or user-agents. Language such as  "a mechanism is available" can be author or user-agent fulfilled. 

As another example, if the browsers all implemented highly visible focus styles (or even an option to enable that) then the new focus-visible SC would be fulfilled without the author having to do anything. 

HTH,

-Alastair

Received on Monday, 20 April 2020 10:34:25 UTC