Re: H91 changes

>>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".

I'm actually warming up to the title attribute as a way to supplement link
text in some situations.

It is quite versatile and well supported on anchors with AT these days.
JAWS, VoiceOver, and NVDA

When the ACCNAME is occupied with anchor text it gooes to ACCDESCRIPTION
and both are read, unlike other things like aria-labelledby and aria-label
which overide the anchor text, and takes over the ACCNAME.

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*
Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Wed, Jun 8, 2016 at 7:54 PM, Greg Lowney <gcl-0039@access-research.org>
wrote:

> 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> <akirkpat@adobe.com>
> To: Greg Lowney <gcl-0039@access-research.org>
> <gcl-0039@access-research.org>
> Cc: WCAG <w3c-wai-gl@w3.org> <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> <akirkpat@adobe.com>
> To: WCAG <w3c-wai-gl@w3.org> <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
>
>
>
>