- From: Schnabel, Stefan <stefan.schnabel@sap.com>
- Date: Fri, 17 Apr 2020 14:43:22 +0000
- To: "Patrick H. Lauke" <redux@splintered.co.uk>, "w3c-wai-gl@w3.org" <w3c-wai-gl@w3.org>
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