Re: Finalizing an Issue-204 CP

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 Sunday, 22 April 2012 11:19:34 UTC