Re: H91 changes

Andrew, I can certainly live with the proposed table, but if you want to improve it here are some suggestions. Most of the editorial ones are general rules that can apply to a lot of the group's documents.


Here are a few substantive issues:

1. Copy the <a> Name handling to <button>. Both should be handled identically.

2. Copy the <a> Name handling to <fieldset>, but modify it to refer to the <legend> subtree rather than the <fieldset> subtree.

3. Clarify that the title attribute should be used only when the other values are empty, e.g. change "alt attribute or title attribute" to "alt attribute, otherwise title attribute".

4. Are the terms "text content within" or "text inside" an element clear to all readers as including the text content of all elements in the subtree? If not, consider using a phrase such as "text content within an <a> element and its subtree".

5. Add the title attribute fallback to <fieldset> and the first <input> row, where it was accidentally omitted.


And here are a few more editorial suggestions:

6. Use commas to avoid ambiguous, dangling modifiers. For example, "label element associated with control or title attribute" should be "label element associated with control, or [or otherwise] title attribute" so it can't be misread as meaning "label element associated with control or [with] title attribute".

7. Sort the <input> rows alphabetically by <type> value, rather than seemingly randomly.

8. Use grammar (articles) to distinguish element and attribute names from normal parts of speech, e.g. say "text inside an <a> element" (as is used in some WCAG 2.0 techniques such as FLASH17) or "text inside an a element" (as is used in the HTML5 spec). Current phrases like "text contained within a element" can at first appear to be a grammatical error, and when reading "In the case of form controls, label elements" one can't tell if those if label is a name or verb until you get further on (as in "In the case of form controls, label [all] elements or title [all] attributes so that the user agent can...").

9. Use standard markup for element and attribute names, as the distinct presentation can also help speed up comprehension for many readers. Why enclose element and attribute names in nonstandard tags instead of using <code> as so many other W3 and WAI specs do? (Or even better, <code class="element">?)

10. Use the plural for <img> inside <a>, <button>, and <fieldset> as either can contain multiple images. (See suggested rewrite in item 5, below.)

11. Use a parenthetical to distinguish the two rows with input = "text", as is done for the two rows covering <select>.

12. Rewrite the Name field for the <a>, perhaps to something like "a string that includes text content within <a> element and alt attributes of <img> elements it contains, or title attribute." This avoids using a period to separate sentence fragments, avoids the word “value” to be consistent with the rest of the document, handles multiple <img> elements, and is vague enough to allow the UA to provide separators instead of naked concatenation. This would also apply to <button> and <fieldset>.

     Thanks,
     Greg

-------- Original Message --------
Subject: Re: H91 changes
From: Andrew Kirkpatrick <akirkpat@adobe.com>
To: Greg Lowney <gcl-0039@access-research.org>
Cc: WCAG <w3c-wai-gl@w3.org>
Date: 6/8/2016 6:42 AM
> Greg,
>
> *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.)
>
> I’d love to point to another document, but unless it is done we can’t.  We can update this in the future pretty easily.  The Mappings 1.0 document doesn’t have a simple role/name/value/state table though, so I think that there is value in this, even if we would rather have another group maintain it.
>
> *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?
>
> I think that this is very useful for authors/evaluators who need to make sure that what they implement meets the relevant success criteria.
>
> 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.
>
> If you can provide more detail, that would help.
> Thanks,
> AWK
>
>
>     Thanks,
>     Greg
>
> -------- Original Message --------
> Subject: H91 changes
> From: Andrew Kirkpatrick <akirkpat@adobe.com>
> To: WCAG <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
>> http://twitter.com/awkawk
>