- From: John Foliot <jfoliot@stanford.edu>
- Date: Wed, 24 Aug 2011 20:15:24 -0700
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: public-html-a11y@w3.org
> Is the example that you are providing here really one of providing a long description? Wouldn't this be better solved with using @aria-labelledby? No, because the input is already labeled by the <label> element surounding Search; the accessibility API already has an accessible label for this input. It's not a 'long' description, its an accessible description, providing contextual information about how to interact with the widget (form input). While length of the description certainly is a factor in usability, it is the intent of the description that is important, and the fidelity and granuality of the description being provided. Long descriptions of very complex images could run to multiple paragraphs or use tables for tabular data (for example a pie graph) - the intent is to convey complex graphical information directly to the end user as html marked-up content. Aria-describedby on the other hand is intended to supply the Accessible API with an AccessibleDescription property ( http://msdn.microsoft.com/en-us/library/system.windows.forms.control.accessibledescription.aspx), it's a contextual description. While the line between the 2 seems blurry, there *is* a difference between the two. You also wrote: > Right now it seems to me that I as a Web developer should totally ignore it because: * it follows the push model and users prefer to have a choice for hearing the long description * it does not allow to properly present rich text * it does not allow to point to hidden on-page text * it does not allow to point to off-page content (though this could be countered by having the link as part of the on-page html fragment it is pointing to) Aria-descibedby is for programatically describing Widgets and putting some context to the widget via the Accessibility API. When it was designed, it was not with the intent of allowing for longer descriptions of images to humans. The key is the inclusion of imagery - because we had @longdesc when aria was being developed, it was not designed to replicate that type of description need; it was for describing Widgets and other interactive content and to interact with the Accessibility APIs. * There are times when push is appropriate, and other times when it is not: pushing contextual information is important (@alt is both contextual and push), but the level of detail that @longdesc affords should be pull. * The Accessibility APIs don't generally require html-rich text, so aria-describedby, under normal envisioned usage, did not need to support rich text, but providing enhanced descriptions of imagery often may. * Aria-describedby *can* point to hidden off screen text, as long as all we need is string (or flat) text, it only breaks down when we need to support rich or focus able/tabable content: use-cases not accounted for when aria was being designed, as (once again), we had @longdesc. * Seperating contextual information from Widgets (by storing it on another page) would be harmful, however storing supplimental, detailed information intended for "pull" allows for leaner code overall - you only do your http transport on demand, resulting in smaller, faster pages, and reduced bandwidth consumption. The bottom line is that aria-describedby is not the right tool to replace @longdesc, despite its similarities. Aria-describedby is not broken, it just was not designed to replicate @longdesc - it has its own role and use to play. JF John Foliot Program Manager Stanford Online Accessibility Program http://soap.stanford.edu Tel: 650-468-5785 + sent from my Xoom tablet - Go Android! +
Received on Thursday, 25 August 2011 03:16:18 UTC