RE: H91 changes

A newbie’s perspective…

I would vote to accept the changes simply as an incremental improvement to include HTML5 controls, with some of Greg’s editorial comments plus one of my own, namely:

1.       All references to attributes or elements (e.g. alt, a, label, title, etc.) should be semantically/visually distinct for clarity using <code>

2.       Table height is large enough to warrant alphabetical order

3.       Agree that the plural of image alt attributes should be used since multiple images are possible, and that the statement about concatenation can be included in a single sentence fragment, rather than repeating words in multiple fragments

4.       Change the cryptic sentence “Elements for which values and states are appropriate also expose the values and states via multiple mechanisms” to “For applicable elements, user agents also expose values and states via multiple mechanisms.”  The assistive technology is doing the exposing, not the element itself.

IMHO, however, the description needs a significant tone change, and the name column is problematic even if aria-label and aria-labeledby are disregarded.  Right now, with the exception of perhaps the first sentence, it reads like pure reference material rather than a technique implementation description for an author tied to the success criteria.  For example, what value is added (no pun intended) by referencing that the required href attribute of an anchor provides the value property?  Or for states, wouldn’t it be more instructional to have a bullet saying something akin to “Always indicate when an input field is required by using the required attribute, rather than only symbolically or stylistically (e.g. using an asterisk or color)”, instead of just listing over and over that it is part of the state?  If written in more of a “how-to” tone, I’m not sure the table would even be needed in the end

Perhaps the biggest technical issue for me arises from the repeated use of “or title attribute” when referring to the name.  The pipeline for confusion is laid simply by using the word “or”, which neither indicates a preference nor explains the consequences of using more than one item (e.g. a label and a title).  If you take the table caption literally, you might think the user agent has no preference in computing the accessible name when both exist, and if you take it more like an author might, you could conclude it is equivalent to use either one and still be in the dark on using both.  We all know neither of those is true, but you can see where the rabbit hole goes: an anchor with title but no text = another SC failure, an anchor with title and text = title goes to accessible description for at least some user agents as David pointed out, title + label = a chaotic table of screen reader + browser behavior as user agent notes, etc.  The screen reader user in me (who admittedly would never advocate the use of a title attribute for accessibility) would propose eliminating “or title attribute” altogether and changing the
Name column to instructional bullets on anchor text and input labels, then explaining where title may fit in rare circumstances.

So that’s my two cents… everyone have a good weekend.

Steve

From: Jonathan Avila [mailto:jon.avila@ssbbartgroup.com]
Sent: Thursday, June 09, 2016 2:09 PM
To: WCAG <w3c-wai-gl@w3.org>
Subject: RE: H91 changes


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

Ø  5. Add the title attribute fallback to <fieldset> and the first <input> row, where it was accidentally omitted.
I’d be consider about the accessibility support for the title attribute on the fieldset.  I know JAWS with IE does not support it.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group
jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>
703.637.8957 (Office)

Visit us online: Website<http://www.ssbbartgroup.com/> | Twitter<https://twitter.com/SSBBARTGroup> | Facebook<https://www.facebook.com/ssbbartgroup> | Linkedin<https://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog/>
Check out our Digital Accessibility Webinars!<http://www.ssbbartgroup.com/webinars/>

From: Greg Lowney [mailto:gcl-0039@access-research.org]
Sent: Wednesday, June 08, 2016 7:54 PM
To: Andrew Kirkpatrick
Cc: WCAG
Subject: 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><mailto:akirkpat@adobe.com>
To: Greg Lowney <gcl-0039@access-research.org><mailto:gcl-0039@access-research.org>
Cc: WCAG <w3c-wai-gl@w3.org><mailto: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><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 (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