W3C home > Mailing lists > Public > public-html@w3.org > August 2009

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 18 Aug 2009 01:20:02 -0700
Message-ID: <63df84f0908180120m392b3a1by534c7b9d13c60710@mail.gmail.com>
To: Jan Richards <jan.richards@utoronto.ca>
Cc: Henri Sivonen <hsivonen@iki.fi>, HTMLWG WG <public-html@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>
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
Received on Tuesday, 18 August 2009 08:21:06 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:06 UTC