- From: John Foliot <john.foliot@deque.com>
- Date: Mon, 23 Jan 2017 12:41:23 -0600
- To: Gregg C Vanderheiden <greggvan@umd.edu>
- Cc: Alastair Campbell <acampbell@nomensa.com>, IG - WAI Interest Group List list <w3c-wai-ig@w3.org>
- Message-ID: <CAKdCpxxF0FBvabPN=iXtCy3r2sB_ehC86zu_8HdZoPjya3rUdQ@mail.gmail.com>
Gregg wrote: > the AUTHOR knows that all users already have it (it is in all browsers) All browsers? That's a mighty high bar to meet Gregg - I wonder aloud how many readers of this thread regularly test in Opera? How about the Yandex browser? Vivaldi? (and those are all based on the Blink web engine[1]) What about Avant[2]? SeaMonkey[3]? qutebrowser[4]? Others? I'm worried that this is making assumptions not based on evidence, and is hardly a repeatable, testable state. And as sad as it is to say aloud, we cannot be expecting web authors to be anticipating every individual user-configuration and setting, and I additionally think we should not be asking authors to create widgets and other user-agent tools to address browser short-comings. I mean, it's great that those needs are being met in the marketplace by extensions and plugins (this thread mentions Stylish frequently), but writing a SC dependent on the quirks of a browser plugin feels very wrong to me (in very much the same way as suggesting writing WCAG 2.0 to reflect JAWs of 2006 was not a good idea then either). "A mechanism exists" is indeed a very powerful blanket statement, but it is also a double-edged sword, and I would suggest we need to tread very carefully here. Alastair wrote: > However, for these adaptation SCs the onus is on the user to provide the mechanism, and for the author not to disrupt their use of it. +1, but that contradicts what Gregg is suggesting (not that I am in agreement with Gregg's assertion here). I agree Alastair, I suspect that part of the problem is that we are also moving towards a series of SC that say what the author must NOT do (e.g. do NOT mess with the end-user's ability to enlarge text), as opposed to what they must do (provide a widget that allows for magnification of text up-to 400%). I think we need to be crystal clear on that. JF [1 - https://en.wikipedia.org/wiki/Blink_(web_engine)] [2 - http://www.avantbrowser.com/] [3 - http://www.seamonkey-project.org/] [4 - http://www.qutebrowser.org/] On Mon, Jan 23, 2017 at 11:58 AM, Gregg C Vanderheiden <greggvan@umd.edu> wrote: > ??? > > There are not — and should not be - any requirements on the user in any > WCAG. These are guidelines for authors. > > > A “mechanism is available” means that the AUTHOR knows that all users > already have it (it is in all browsers ) or the author has to provide it. > > If there are new SC being proposed that say “ the user must provide a > mechanism” (in any words) then — you are right - that is a problem and > needs to be fixed. > > Gregg C Vanderheiden > greggvan@umd.edu > > > > On Jan 23, 2017, at 12:18 PM, Alastair Campbell <acampbell@nomensa.com> > wrote: > > Gregg wrote: > > “Mechanism is available” is a very powerful and forward looking approach > > Yes, and to be clear I wasn’t being critical of its use in WCAG 2.0. In > those cases the onus was (and mostly still is) on the author to provide the > mechanism. > > However, for these adaptation SCs the onus is on the user to provide the > mechanism, and for the author not to disrupt their use of it. In that way > it is similar to 2.1.1 Keyboard. The user brings the keyboard, the site > should enable that usage by using proper HTML inputs/links/buttons, not > using dodgy event handling etc. > > Cheers, > > -Alastair > > > -- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com Advancing the mission of digital accessibility and inclusion
Received on Monday, 23 January 2017 18:41:57 UTC