- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Sun, 22 Apr 2012 12:18:44 +0100
- To: Cynthia Shelly <cyns@microsoft.com>
- Cc: Laura Carlson <laura.lee.carlson@gmail.com>, Janina Sajka <janina@rednote.net>, HTML Accessibility Task Force <public-html-a11y@w3.org>, John Foliot <john@foliot.ca>, Joshue O Connor <joshue.oconnor@cfit.ie>, Judy Brewer <jbrewer@w3.org>, "david100@sympatico.ca" <david100@sympatico.ca>, Richard Schwerdtfeger <schwer@us.ibm.com>, James Nurthen <james.nurthen@oracle.com>, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, "Jonas Sicking (jonas@sicking.cc)" <jonas@sicking.cc>
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