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

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