Re: feedback requested on WAI CG Consensus Resolutions on Text alternatives in HTML 5 document

On Aug 18, 2009, at 11:20, Jonas Sicking wrote:

> My general impression of @alt is that relatively speaking it has been
> pretty successful, as far as "bolt-on" accessibility attributes go.
> Looking images that needs description (i.e. is non-presentational) vs
> tables that needs description (due to having a complex layout), my
> impression is that @alt has been much more successful than
> @summary[2]. This makes me wonder why. I can think of two reasons:
>
> 1. @alt is required, and thus a missing @alt is flagged by validators

It doesn't explain the difference relative to summary, though, because  
there's no validator-related reason to put in the predominantly bogus  
summaries that have been found in the wild.

> 2. @alt used to be displayed by IE as a tooltip

If the alt tooltip in IE made alt better, the campaign not to show alt  
as tooltip in other browsers has been horribly misguided. :-/

In any case, there are many other more plausible reasons including:

  3. Alt is the foremost accessibility evangelism item. Introductions  
to accessibility cover alt right away but don't necessarily cover  
summary.

  4. For sighted authors, alt is conceptually easier to grasp and  
easier to test in Lynx or in a GUI browser with image loading turned  
off.

  5. SEO propaganda.

> It looks to me like there are two options here:
>
> 1. Fill out a best guess value. The DC document uses the example
> "Photo X of Y" as an example.
> 2. Not fill out any alt attribute at all.
>
> The advantage of using 1 is that it allows us to say that @alt should
> be a required attribute. The downside is that it creates a bunch of
> @alt attributes which contain fairly useless information. And with no
> way for AT users to tell that the information is useless. I don't know
> how big of a problem this useless information is for AT users. I seem
> to recall some AT user saying that it's easy enough to skip an
> attribute if it appears to contain useless info.

I've decided to no longer advocate what solution should be adopted,  
but I think the signals for authoring tool developers should be  
coherent across HTML 5 validation and ATAG 2. If there's WAI consensus  
that #1 is the right thing to do, ATAG 2 needs to be edited to say so  
to keep things coherent.

> The problem with 2 is that it goes against the requirements of the
> spec. I.e. the tool would create invalid HTML. I'm not convinced this
> is a problem.

If it isn't from the tool vendor point of view, why do BlueGriffon and  
iWeb do what they do?

> This seems very similar to me to how the spec says "Tables must not be
> used as layout aids". However it's quite possible today to use
> dreamweaver to create a page that uses tables as layout. Thus
> dreamweaver today can already create invalid HTML. The responsibility
> to not do that falls both on the tool and the user.

That's substantially different, because the spec doesn't give  
computable criteria for deciding if a table is a layout table, so the  
requirement isn't machine-checkable. To make alt similar, the spec  
would need to make the presence of the alt syntax to depend on matters  
that aren't computable.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Tuesday, 18 August 2009 09:54:00 UTC