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

On Tue, Aug 18, 2009 at 2:53 AM, Henri Sivonen<hsivonen@iki.fi> wrote:
> 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.

I'm not sure how the bogus @summary values are related to this? The
point is that there are orders of magnitude more @alt than @summary.

Though technically some of that can be explained by @summary not being
needed on every table. However I strongly suspect that even if you
looked at just the tables that needed it, you'd see a relatively small
percentage with @summary at all, vs. how common @alt is.

>> 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. :-/

Indeed. I simply don't know.

> 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.

Indeed.

>> 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?

You'll never have things working perfectly. No matter what solution we
argue for there will be some people/vendors doing things wrong. The
presence of errors doesn't mean that model needs to be changed.

>> 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.

The point remains that tool can't enforce all the requirements of the spec IMHO.

/ Jonas

Received on Tuesday, 18 August 2009 17:45:43 UTC