Re: Flickr and alt

Hi Justin,

>>> The techno-geek in me loves this idea. The pragmatist in me
>>> says that it makes things too complicated for the typical HTML
>>> author. :(
>>>
>>> Unless, of course, we assign a default @role for @role="" and a
>>> missing @role, and the default @role has @alt rules of "@alt
>>> must be present (even with a value of empty string), see WCAG
>>> for information on how to use it." That would take the entire
>>> thrust of Karl's proposal and merge it with this excellent idea
>>> presented here. The large majority of HTML authors who are
>>> savvy enough to use @role will also be able to follow along
>>> with the idea that @role can affect @alt requirements.
>>
>> A default @role value? Perhaps. Against 1: The presence of @role
>> is very simple to validate. So why allow omitting it? To validate
>> HTML 4 docs as if being HTML 5? Against 2: What validation
>> response should lack of @role then lead to?
>
> The reason why I suggest that we allow it to be omitted, is because  
> it is a pretty large burden to impose on HTML authors to ask them to  
> try to categorize every tag they use into the @role system. Creating  
> a role called "unspecified", and spec'ing it so that anything where  
> @role is omitted or equal to empty string is equivalent to  
> @role=unspecified makes it possible for people who do not care about  
> @role (which will be the vast majority of HTML authors,  
> unfortunately), who do not need @role (not too many HTML authors),  
> or who can't figure out the right value for @role (a fairly frequent  
> case, I suspect) to still be writing valid and conforming code.
>
> One contributing factor in why I feel this way, is that I am of the  
> opinion that @role should be available on nearly every element in  
> the body of an HTML document.

Leif's suggestion is not as complicated as it seems. Most HTML  
elements already have an implied role. Though the DTD or document  
definition prose do not necessarily discuss it, assistive technology  
makes assumptions about the role nevertheless. So authors need do  
nothing when, for example, they include a <input type='button'> in  
their document because the role of that element is mapped for them.  
The exceptions to this are the embedded media elements (IMG, OBJECT,  
VIDEO, etc). In those cases it is not possible to sufficiently map  
those elements to a role keyword because they have diverse uses. The  
only other option would be to coin new element names for every role we  
could think of. It is far simpler to simply use the explicit role  
attribute to encode this information.

So my view is that we should require role on all of these embedded  
media elements and Leif is suggesting that the need for alt is avoided  
for many roles. For example a 'decorative' role indicates that alt is  
not necessary. Likewise a 'photo' role combined with alt='' could be  
treated as conforming, but subject to conformance checker warnings.  
The role 'chart' with alt='' would instead be a conformance error. The  
important thing is to keep the number of non-text media related  
keywords to a manageable level.

>> [snip]
>
> ... ! I think that @role not only opens up great things for  
> validation, but also for search engines and any other "Semantic Web"- 
> consuming/parsing application. But I also think it's way too much to  
> ask of many (if not most) HTML authors to always use it, let alone  
> use it correctly (much like @alt, sadly).

I think the difficulty authors have with using role is not inherent to  
the use case it addresses, but reflects the failure to reach consensus  
among those of us in this community. I'm not speaking of those whose  
knee jerk reaction is to dismiss accessibility with claims that it is  
an oppressive regime these cripples run (we have only a vocal few of  
those in this WG). Rather it is those of us who genuinely want to see  
accessibility needs addressed who are still talking past each other.  
For example, WCAG leaves some of these use cases unaddressed (at least  
explicitly). I think of role as helping to bring the community to  
consensus as well as guiding the author through the steps needed for  
accessibility. Think of it as one of these ubiquitous assistants or  
wizards we see in so much software.

1) what is the role of this image (or video or audio or applet, etc as  
determined by the resource's media type or the HTML element used)?

     [for image]
     a) decorative
     b) photograph
     c) chart or graph
     d) geographic map

     [for audio]
     a) musical accompaniment
     b) audio equivalent

     [for other]
     a) decorative
     b) interactive application
     c) film

  2) based on the role indicated, the alt is either required or highly  
recommend. Also longdesc, other supporting attributes or media  
specific accessibility hook might be recommended based on the  
selection of a role.

Such an approach allows both authors and users a way to quickly filter  
out the decorative or focus attention on missing alt text (without  
using an attribute such as missingalt=missingalt that can become out  
of sync). For someone visually impaired it is a good bit of  
information to know that of the dozens of images on the page (some  
with alt text others without) there is one image with the role 'photo'  
even if that photo has no alt text or other description (for example,  
the goal may have simply been to download the relevant photo and print  
it).

It is also very easy for authoring tools and conformance checkers to  
keep track of the role and the requirements for alt text.

Take care,
Rob

Received on Wednesday, 20 August 2008 08:46:22 UTC