Re: Finalizing an Issue-204 CP

Hi Benjamin,

We need to wrap up the change proposal on 204. We understand that 
some of the changes that Cynthia is making to address Laura's 
suggestions may also address some of yours. If you haven't seen it 
yet, please  take a look at the following message from yesterday:
http://lists.w3.org/Archives/Public/public-html-a11y/2012Apr/0173.html

That message mentions the remaining changes that we understand that 
Cynthia will be making to this change proposal before we submit it 
today, as we need to move this forward.

Thanks,

- Judy

At 12:18 PM 4/22/2012 +0100, Benjamin Hawkes-Lewis wrote:
>On Fri, Apr 20, 2012 at 12:25 AM, Cynthia Shelly <cyns@microsoft.com> wrote:
> > 
> http://www.w3.org/html/wg/wiki/Correct_Hidden_Attribute_Section_v2#Accessibility_API_mappings
>
>The "hidden" attribute was introduced to provide a way to mark a DOM
>subtree as irrelevant for presentation for all end-users. This is
>radically different from suggesting a DOM subtree should be hidden
>using authorial CSS, and was intended to replace abuses of CSS for the
>former purpose.
>
>I'm on the fence but there is a case to be made for including @hidden
>content directly referenced by explicit or implied ARIA properties in
>accessible name and description calculation. The CP puts this case
>reasonably well.
>
>However, the CP is much less persuasive that we should be encouraging
>the use of @hidden content for accessible name and description
>calculation, rather than trying to discourage it by making it
>non-conforming.
>
>Consider the use case where authors want to provide accessible names
>without affecting the render tree. Using @aria-label fully addresses
>this use case; we don't need to allow @aria-labelledby to refer to
>@hidden. Example 2 from the CP is meant to illustrate how @hidden
>meets this use case:
>
>   <input aria-label="foo" type=text><input type=image alt="Go!">
>   <div role=label id="foo" hidden>Search</div>
>
>This example is incorrect. There is no WAI-ARIA role "label", the
>input is mislabelled "foo", and there's no @src attribute. So let's
>fix those problems:
>
>   <input aria-labelledby="foo" type=text><input type=image
>src="search.png" alt="Go!">
>   <div id="foo" hidden>Search</div>
>
>Now let's see what the same UI would look like marked up with
>@aria-label instead of @hidden:
>
>   <input aria-label="Search" type=text><input type=image
>src="search.png" alt="Go!">
>
>This is still terrible markup since the @alt text is not appropriate
>and it uses a redundant @type=text instead of @type=search, but it
>does illustrate how @aria-label provides the same experience for
>end-users while being much simpler for authors.
>
>Example 3 also tries to use a hidden label:
>
>   <input aria-label="foo" type=text onmouseover="showFoo();"
>onmouseout="hideFoo();"><input type=image alt="Go!">
>   <div role=label id="foo" hidden><img src="decorative-image.gif"
>alt="">Search</div>
>
>This suffers from the same critical markup error as Example 2. So
>let's fix this again:
>
>   <input aria-labelledby="foo" type=text onmouseover="showFoo();"
>onmouseout="hideFoo();"><input type=image alt="Go!">
>   <div id="foo" hidden><img src="decorative-image.gif" alt="">Search</div>
>
>Purportedly, this example is included to demonstrate how "one might
>want to flatten the text for some users and not all". This may seem
>attractive from a Don't Repeat Yourself perspective, but this markup
>is a lot more complicated the @aria-label equivalent:
>
>  <input aria-label="Search" type=text onmouseover="showFoo();"
>onmouseout="hideFoo();"><input type=image alt="Go!">
>   <div id="foo" hidden><img src="decorative-image.gif" alt="">Search</div>
>
>The more complicated the DOM you are flattening, the more complicated
>the use of this technique gets. The fact that a CP arguing the utility
>of such markup got the association between the control and its hidden
>label wrong twice in a row in the simplest possible case should set
>off warning bells in our heads about the advisability of promoting
>this technique to less experienced authors.
>
>Beyond that, as the CP confesses, this example is both unrealistic and
>highly unusable. Text-mode browser users have to infer the textbox is
>a search term field from being shown alongside a button labelled "Go!"
>Keyboard users can't expose the popup.
>
>The CP further argues that <label> should be allowed in @hidden. It
>doesn't give an example to illustrate why, and I'm not sure why
>"label" is singled out and other elements that produce accessible
>names or descriptions for other elements, like <legend>, <caption>,
>and <figcaption>, aren't mentioned. Anyway, allowing <label> to be
>excluded from the render tree with @hidden harms users, since it won't
>be rendered when authorial CSS is not applied (thanks to user
>preferences, network failures, browsers, and text-mode browsers). So
>we should continue to encourage markup like:
>
>    .context { position: absolute; left: -999999px; }
>
>    <label class=context for=terms>Search terms:</label> <input
>id=terms type=search name=terms>
>
>over this:
>
>    <label hidden for=terms>Search terms:</label> <input id=terms
>type=search name=terms>
>
>What about accessible descriptions? Example 1 in the CP is included to
>illustrate the advantage of allowing hidden descriptions:
>
>   <pre role=img aria-describedby=foo>  )\._.,--....,'``.    fL
>    /,   _.. \   _\  ;`._ ,.
>   `._.-(,_..'--(,_..'`-.;.'</pre>
>
>   <p id=foo hidden>An ASCII art rendition of a cat in prone position.</p>
>
>In this example, the accessible name of the image is the ASCII
>gibberish and only the accessible description is a text alternative.
>
>Wouldn't:
>
>   <pre role="img" aria-label="An ASCII art rendition of a cat in prone
>position.">  )\._.,--....,'``.    fL
>    /,   _.. \   _\  ;`._ ,.
>   `._.-(,_..'--(,_..'`-.;.'</pre>
>
>be better for users and simpler for authors?
>
>Does anyone have any better examples that illustrate why names and
>descriptions, especially those created using "native" HTML elements
>like <label>, should be hidden with @hidden should be conforming as
>well as "just working"?
>
>--
>Benjamin Hawkes-Lewis

Received on Tuesday, 24 April 2012 18:25:03 UTC