Re: User Testing of Accessiblity Features

HI Debi,


On Aug 28, 2007, at 10:34 AM, Debi Orton wrote:

>
> Hello,
>
> We (the NYS Forum IT Accessibility Committee) did some work last  
> year that indicated that screen reader users fell into two camps  
> with regard to the usefulness of alt attributes for images.  Some  
> users wanted to know what EVERY image was so that they could be  
> sure they weren't missing information.  Others wanted only  
> meaningful images described.  We proposed an additional attribute  
> (two values only) for the img element to indicate whether the image  
> was informational or just eye candy.

This sounds very much like a proposal discussed earlier on the list.   
Just to summarize, it evolved through the discussion (and still needs  
to be added to the wiki),  but basically it involves using the @role  
attribute to indicate whether an image's role in a document with  
newly introduced keywords: 1) 'decorative', 2) 'icon', 3)  
'seefallback', and 4) 'seecontext'. While all embedded content would  
be required to have a role attribute with one of these four keywords,  
for embedded content with keywords 'decorative' or 'seecontext', no  
@alt attribute would be required. It could be alt='' for backwards  
compatibility.

For those cases where the keyword was set to 'seefallback' or 'icon'  
the @alt attribute would be required with a meaningful and non-empty  
string. My view is that we should recommend that conformance checkers  
provide an option for authors to suppress @alt @role errors and  
warnings (a selection that is not persistent between sessions) so  
that authors do not simply circumvent the conformance checker by  
adding bogus @alt or @role values (e.g., adding 'decorative' when the  
images are not decorative). The often mentioned noalt attribute would  
be the same as having a @role value of 'seefallback' or 'icon' and  
having no fallback content (this is for any embedded content element  
so @alt is just one of the relevant fallback mechanisms).

An embedrel DOM attribute would provide an API to access the relevant  
values and make this approach compatible with pre-HTML5 content. This  
approach allows users to discover the role of the embedded content  
and explore at their own option richer descriptions depending on the  
role of the embedded content.

Take care,
Rob

[1]: <http://lists.w3.org/Archives/Public/public-html/2007Aug/0647.html>

Received on Tuesday, 28 August 2007 19:24:27 UTC