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

Re: Mechanism Disclaimer

From: Alastair Campbell <acampbell@nomensa.com>
Date: Mon, 23 Jan 2017 23:17:42 +0000
To: John Foliot <john.foliot@deque.com>, Gregg C Vanderheiden <greggvan@umd.edu>
CC: IG - WAI Interest Group List list <w3c-wai-ig@w3.org>
Message-ID: <HE1PR0901MB14667375DA5E7EB2D640799DB9720@HE1PR0901MB1466.eurprd09.prod.outlook.com>
JF wrote:
> 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)...

I don't think it is particularly new, at least in concept, for example 2.1.1 requires authors not to interfere with keyboard use, add support for keyboard use when needed, and 2.1.2 is a more direct "don't do this"!.

I see this adaptation SC as building on 1.3.1, but making visual presentation a key factor. The user-need is very clear, the LVTF have good research and tons of practical experience, the difficulties of horizontal scrolling and dense, difficult to read text are blockers for more people than use screenreaders, and difficult for many more.

A key practical point to address is this:
> 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

I agree with all of that, and this SC will stand (or fall) on the techniques. 

NB: I also think that, similarly to 2.1.1 and 1.3.1, the SC should get down to the level of defining *how*, it should state the requirement and leave the rest to understanding & techniques.

What I propose is that we come to agreement on the SC based on the requirement (for content), and then we flesh out the techniques. Wayne and I have a plan for that, and help to do it (though more is of course welcome).

The plan is that we start testing sites with the various user-agent tools, primarily the bookmarklets created specifically for this.

For each issue we hit whilst adapting content, we try to work around it and establish we have done everything a tool can do to make it work.  The things that are left should become techniques the author needs to do to enable adaptation.

Techniques are TBC, but I'm guessing things like:
- Use SVG/images/content for icons, not weird font-families.
- Use min-height rather than a fixed height on elements containing text so that text can wrap.
- Don't rely on background images to convey information.

There are quite a few already in WCAG 2.0 which might become sufficient techniques / failures attached to this SC.

Between here and the final draft, we should have a good range of techniques, and maybe even some failures? ;-)


Received on Monday, 23 January 2017 23:18:19 UTC

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