- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Tue, 18 Aug 2009 12:53:16 +0300
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Jan Richards <jan.richards@utoronto.ca>, HTMLWG WG <public-html@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>
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:02 UTC