- From: Steven Faulkner <faulkner.steve@gmail.com>
- Date: Tue, 18 Aug 2009 11:21:24 +0100
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: HTMLWG WG <public-html@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>
- Message-ID: <55687cf80908180321x1feefebfu241676bf647273cc@mail.gmail.com>
hi jonas, The spec at it is promotes the warning of missing alt attribute under most circumstances, the circumstances when it should not are clearly described. I don't think the argument is to warn of missing alt under all circumstances (ie alt must be present on every image) the consensus document recommends some extra situations where a missing alt should be considered valid: - @aria-labelledby is present (non-empty only) - @role="presentation" and it omits some situations that are currently considered as valid - The title<http://www.whatwg.org/specs/web-apps/current-work/?slow-browser#the-title-attribute>attribute is present and has a non-empty value. - The img<http://www.whatwg.org/specs/web-apps/current-work/?slow-browser#the-img-element>element is part of the only paragraph<http://www.whatwg.org/specs/web-apps/current-work/?slow-browser#paragraph>directly in its section<http://www.whatwg.org/specs/web-apps/current-work/?slow-browser#concept-section>, and is the only img<http://www.whatwg.org/specs/web-apps/current-work/?slow-browser#the-img-element>element without an alt<http://www.whatwg.org/specs/web-apps/current-work/?slow-browser#attr-img-alt>attribute in its section, and its section<http://www.whatwg.org/specs/web-apps/current-work/?slow-browser#concept-section>has an associated heading. I have provided some reasons why the first of the omissions should be considered: here http://lists.w3.org/Archives/Public/public-html/2009Aug/0881.html and have filed a bug (http://www.w3.org/Bugs/Public/show_bug.cgi?id=7362) in respect to this. I have no argument against the second staying in the spec. note: in regards to IE displaying alt as a tooltip, as of IE8 it no longer does in standards mode. regards stevef 2009/8/18 Jonas Sicking <jonas@sicking.cc> > On Mon, Aug 17, 2009 at 6:56 AM, Jan Richards<jan.richards@utoronto.ca> > wrote: >>> The Consensus Documents goes in that direction when it states > that it > >>> doesn't mater if an <IMG> with role="presentation" has an empty alt="" > or no > >>> alt at all. But it goes slightly in the opposite direction when it > >>> recommends that validators should say that an <IMG> with an empty > alt="" but > >>> not @role should automatically get a role="presentation". > >> > >> My biggest concern with the proposed normative warning is that > >> role=presentation wouldn't be the path of least resistance for > dismissing > >> the warning. Putting a space in the value of alt would be. > > > > Actually, if an author is going to be non-cooperative, then I would > prefer > > they put in alt=" " rather than misuse semantic markup (alt="" and > > role="presentation") which indicate a cooperative author has judged the > > image to be presentational. (NOTE: Even more preferable to me would be to > > find a way for @alt to be left out in such a situation as an indicator > that > > problem exists) > > > I've been staying out of the discussion, mostly because I don't consider > myself very experienced in accessibility. However I figured I > should send my opinions to the list and let people take it or leave it > as they see fit. > > I'm choosing a more or less random email to respond to. What triggered > my decision to write this was the last parenthesis above, which is why > I'm choosing this particular email to respond to. > > So, first off, I do think that @alt should be required (possibly > except in cases where other/context is available, as described in the > list in the beginning of [1]) , and here is why: > > 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 > 2. @alt used to be displayed by IE as a tooltip > > I don't know which has been the more important reason, but the > important part is I think that 1 has helped. While not everyone > validate their pages, I think HTML evangelists have managed to get the > word out that @alt should be filled out, and I think validators have > been an important part of that messaging. > > So, what to do about what I understand to be the big sticking point > with making @alt required. Tools, like dreamweaver and flickr, that > generate HTML, and where the user interacting with the tool has not > provided enough information for the tool to fill out a useful @alt > attribute value. > > 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. > > 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 we look at the entity creating the HTML document as > the user and tool together, the blame for the page not being valid > calls on the user half of that relationship (or possibly somewhat on > the tool part since it could maybe do more to encourage the user to > provide a proper description. > > 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. > > So all in all it seems to me that making @alt required will help with > accessibility. Even if that means that there is (another) way for > tools to create invalid markup in the hands of a user that doesn't pay > enough attention to accessibility. And even if people many times just > fill out a random value in order to get their documents to validate. > My fear if we don't make @alt required is that it will turn into > another @summary [2]. > > [1] > http://www.whatwg.org/specs/web-apps/current-work/?slow-browser#unknown-images > [2] Please don't overtake this thread with discussions about @summary. > The relevant part here is that @summary is used very little (even just > looking at the places where it's needed), something I don't think > anyone disputes. My impression is also that it's used less than @alt. > > / Jonas > > > -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html
Received on Tuesday, 18 August 2009 10:22:08 UTC