W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2017

Re: Mechanism Disclaimer

From: John Foliot <john.foliot@deque.com>
Date: Mon, 23 Jan 2017 12:41:23 -0600
Message-ID: <CAKdCpxxF0FBvabPN=iXtCy3r2sB_ehC86zu_8HdZoPjya3rUdQ@mail.gmail.com>
To: Gregg C Vanderheiden <greggvan@umd.edu>
Cc: Alastair Campbell <acampbell@nomensa.com>, IG - WAI Interest Group List list <w3c-wai-ig@w3.org>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 January 2017 18:41:58 UTC