Re: H91 changes

Greg, thank you for the feedback.     Keep in mind the following regardif sufficient techniques
- they are just one way of meeting the SC
- they are generally accessibility supported - e.g. Aria-label is not supported in the past by speech recognition
- they may provide  people with the preferred way without confusing them with many choices many of which may not be appropriate.  E.g.  Aria-label is not the preferred way of assigning a name to a button with text or even an input field yet it is first in the name calculation
- techniques can be technology specific as this may help focus on the right solution for the right technology.  E.g placeholder may be used in the name calc but it's really fallback and should not be relied on for a name.
.etc.

Techniques like H91 can be very helpful because they can provide clear actionable guidemce abd steer people in to the most supported implementation.

Jonathan

Sent from my iPhone

On Jun 8, 2016, at 3:39 AM, Greg Lowney <gcl-0039@access-research.org<mailto:gcl-0039@access-research.org>> wrote:

Hi Andrew,

After thinking about this a bit more, I have two very fundamental questions:

1. Why conflict with other, forthcoming documents? This table conflicts pretty completely with HTML Accessibility API Mappings 1.0 and the documents on which it's based. It's still a working draft, but as it's their job to explain all this. Shouldn't we simply refer readers to one or more of those documents, instead? (Probably more than one if we want to address web technologies beyond just HTML.)

2. Is this table useful for content authors? It seems more appropriate for UAAG and ATAG than for WCAG. How do you expect content authors to use it? The whole point of H91 seems to be to use standard links and form controls so you won't have to take special steps or think about these issues, beyond the basics of providing attributes such as alt. Am I missing something?

If we decide to keep it, I've spotted some serious internal errors that should be fixed, as well as some editorial and grammatical errors. But we'd have to rewrite it pretty completely anyway if we didn't want it to conflict with the documents mentioned above.

    Thanks,
    Greg

-------- Original Message --------
Subject: H91 changes
From: Andrew Kirkpatrick <akirkpat@adobe.com><mailto:akirkpat@adobe.com>
To: WCAG <w3c-wai-gl@w3.org><mailto:w3c-wai-gl@w3.org>
Date: 5/25/2016 6:02 AM
WCAG -

We discussed H91 on a call a few weeks ago and the group approved the changes on the call, but people wanted to see the changes in rendered HTML rather than HTML code because the changes are in a table and it is difficult to read in markup.

This started out as a request to at aria-label and aria-labelledby (https://github.com/w3c/wcag/issues/167) but the group felt that technique H91 should stay focused on the support provided in HTML directly, and needed to add the new form types found in HTML5.

The changes are here: https://github.com/w3c/wcag/pull/179/files?diff=split
The rendered HTML version of the changed table is here: <http://awkawk.github.io/h91.html> http://awkawk.github.io/h91.html (this just has the table from the technique, see the bottom of the code for the changes to the test procedure.
The original technique: http://www.w3.org/TR/WCAG20-TECHS/H91.html

What do people think?  Any questions/concerns?

Thanks,
AWK

Andrew Kirkpatrick
Group Product Manager, Standards and Accessibility
Adobe

akirkpat@adobe.com<mailto:akirkpat@adobe.com>
http://twitter.com/awkawk