Issue-204 from HTML-A11Y TF now stable and ready for next steps

Dear HTML Chairs:

As previously discussed, all substantive changes are now incorporated in
the Issue-204 Change Proposal authored by Cynthia Shelly on behalf of
the HTML-A11Y TF and the WAI-PF WG.

The only remaining edits are minor nits of spelling and grammar
corrections per:

We expect Laura will withdraw her proposal in deference to Cynthia's
very soon.

We further expect the TF will vote a resolution in support of this CP at
its Thursday teleconference.



Janina Sajka,	Phone:	+1.443.300.2200

Chair, Open Accessibility	
Linux Foundation

Chair, Protocols & Formats
Web Accessibility Initiative
World Wide Web Consortium (W3C)

Forwarded message 1

  • From: Cynthia Shelly <>
  • Date: Tue, 24 Apr 2012 21:25:34 +0000
  • Subject: RE: Finalizing an Issue-204 CP
  • To: Judy Brewer <>, Benjamin Hawkes-Lewis <>, Laura Carlson <>, Janina Sajka <>
  • CC: HTML Accessibility Task Force <>, John Foliot <>, Joshue O Connor <>, "" <>, Richard Schwerdtfeger <>, James Nurthen <>, Leif Halvard Silli <>, "Jonas Sicking (" <>
  • Message-ID: <>
I believe I have made changes to address all the open issues.  If you feel I haven't addressed one of your issues,  please let me know within the next 2 hours.  Please provide the exact text you want changed and why.


-----Original Message-----
From: Judy Brewer [] 
Sent: Tuesday, April 24, 2012 10:55 AM
To: Benjamin Hawkes-Lewis; Cynthia Shelly; Laura Carlson; Janina Sajka
Cc: HTML Accessibility Task Force; John Foliot; Joshue O Connor;; Richard Schwerdtfeger; James Nurthen; Leif Halvard Silli; Jonas Sicking (
Subject: 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:

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.


- Judy

At 12:18 PM 4/22/2012 +0100, Benjamin Hawkes-Lewis wrote:
>On Fri, Apr 20, 2012 at 12:25 AM, Cynthia Shelly <> wrote:
> > 
> essibility_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 
>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 
>   <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"
>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" 
>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" 
>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.
>   <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 Wednesday, 25 April 2012 04:45:59 UTC