RE: Plugins as SC - thread was: Visual Indicators

Hi Patrick,

>>> As for SCs that "require plugins", I think there's a nuance here: it's 
not that the SCs themselves require plugins. It's usually that SCs 
require things to be done correctly/programmatically so that things like 
user agents, plugins, etc CAN then offer certain functionalities (like 
text spacing etc). The requirement (and the only thing possible for 
authors) is that the authored content should not try to actively 
suppress/stand in the way/not provide the necessary programmatic hooks 
that allow users to get to the necessary end result.

The current wording of respective SC Test just not reflects that thinking fully. Therefore I insisted to discuss this.
The plugin is therefore a TEST tool and not a tool to ACOMPLHISH the requirement.

Subtle but important difference nowhere mentioned.

Regards
Stefan


-----Original Message-----
From: Patrick H. Lauke <redux@splintered.co.uk> 
Sent: Friday, April 17, 2020 2:58 PM
To: w3c-wai-gl@w3.org
Subject: Re: Plugins as SC - thread was: Visual Indicators

On 17/04/2020 09:58, Schnabel, Stefan wrote:
[...]
> Basically, a WCAG requirement "...who should do what with reasonable 
> effort..." is handled for me on different levels that built on each other:
> 
>   * OS foundation (settings, services)
>   * User Agent features (using foundation but also own functions)
>   * Framework (encapsulating requirements by using user agent and markup
>     language features)
>   * Web Application / Web Page author (the rest)
[...]
> I just say if making plugins with user settings or modifications an 
> integral part of requirement SC concept *is dangerous *since it removes 
> the need for the layers above to do **anything**. They will always 
> argument “yeah yeah take a plugin and you’re good” (for screen readers, 
> you practically have no other choice).

Unless I'm misunderstanding here, there seems to be a slight 
misunderstanding though about WCAG - it is aimed at content authors (so, 
looking at those "levels", only the last two).

WCAG can't require something that needs to be done at UA or OS level. 
That's the job of UAAG.

As for SCs that "require plugins", I think there's a nuance here: it's 
not that the SCs themselves require plugins. It's usually that SCs 
require things to be done correctly/programmatically so that things like 
user agents, plugins, etc CAN then offer certain functionalities (like 
text spacing etc). The requirement (and the only thing possible for 
authors) is that the authored content should not try to actively 
suppress/stand in the way/not provide the necessary programmatic hooks 
that allow users to get to the necessary end result.

Because otherwise, if we put the burden on authors to also provide the 
actual solutions themselves, we end up with the chicken-and-egg problem 
you describe (e.g. browsers saying "why should we offer an option for 
this? if a site wants to fulfill this WCAG SC they will build it as a 
custom site widget anyway").

However, there also of course needs to be a level of pragmatism - doing 
purely theoretical SCs that have no real-world actual support 
is...suboptimal (looking at you SC 1.3.5 in particular - though at least 
that's saved by the lucky side effect that autocomplete has a real-world 
benefit, though unintended).

P
-- 
Patrick H. Lauke

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

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

twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Friday, 17 April 2020 14:43:41 UTC