W3C home > Mailing lists > Public > wai-xtech@w3.org > August 2008

RE: Flickr and alt

From: Justin James <j_james@mindspring.com>
Date: Wed, 20 Aug 2008 01:24:24 -0400
To: "'Leif Halvard Silli'" <lhs@malform.no>
Cc: "'Gez Lemon'" <gez.lemon@gmail.com>, "'Patrick H. Lauke'" <redux@splintered.co.uk>, <wai-xtech@w3.org>, <public-html@w3.org>
Message-ID: <04c001c90285$01ddf880$0599e980$@com>

> -----Original Message-----
> From: public-html-request@w3.org [mailto:public-html-request@w3.org] On
> Behalf Of Leif Halvard Silli
> Sent: Tuesday, August 19, 2008 10:12 PM
> To: Justin James
> Cc: 'Gez Lemon'; 'Patrick H. Lauke'; wai-xtech@w3.org; public-
> html@w3.org
> Subject: Re: Flickr and alt
> Justin James 2008-08-19 22.38:
> >> Leif Halvard Silli Sent: Tuesday, August 19, 2008 2:49
> >> It seems to me that the understanding of conformance versus
> >> validation could be improved by requiring the role=""
> >> attribute, and have spesific @alt requirements for each role.
> >
> > The techno-geek in me loves this idea. The pragmatist in me
> > says that it makes things too complicated for the typical HTML
> > author. :(
> >
> > Unless, of course, we assign a default @role for @role="" and a
> > missing @role, and the default @role has @alt rules of "@alt
> > must be present (even with a value of empty string), see WCAG
> > for information on how to use it." That would take the entire
> > thrust of Karl's proposal and merge it with this excellent idea
> > presented here. The large majority of HTML authors who are
> > savvy enough to use @role will also be able to follow along
> > with the idea that @role can affect @alt requirements.
> A default @role value? Perhaps. Against 1: The presence of @role
> is very simple to validate. So why allow omitting it? To validate
> HTML 4 docs as if being HTML 5? Against 2: What validation
> response should lack of @role then lead to?

The reason why I suggest that we allow it to be omitted, is because it is a pretty large burden to impose on HTML authors to ask them to try to categorize every tag they use into the @role system. Creating a role called "unspecified", and spec'ing it so that anything where @role is omitted or equal to empty string is equivalent to @role=unspecified makes it possible for people who do not care about @role (which will be the vast majority of HTML authors, unfortunately), who do not need @role (not too many HTML authors), or who can't figure out the right value for @role (a fairly frequent case, I suspect) to still be writing valid and conforming code.

One contributing factor in why I feel this way, is that I am of the opinion that @role should be available on nearly every element in the body of an HTML document.

> Some tryouts for the last question: If the default value was
> (1) somethign requiring alt text => endless requests for alt text
> (though the author could add @role to get rid of many of them.)
> (2) role="decorative" => endless requests for @alt text removal.
> (3) role="undefined" => error response = not what you wanted.
> (4) role="private-undefined" (the name of the default role should
> seem unfitting for "public" pages) => validator announces
> 	(a) the lack of @role; (b) the name of the default role (c) that
> such a value is incorrect for pages which are corporate,
> governmental or public, and for all other pages in need of a
> measure of universal access and accessibility (d) that the @alt
> can not be evaluated before @role is added (though the presence of
> @alt, and - possibly - repeated alt values could be evaluated,
> depending on how the defult value was defined, and always with an
> advice to add @role before editing the @alt attribute).

I tend to favor a behavior of missing/empty/"unspecified" @role value to behave consistently with Karl's proposal from yesterday (at least in regards to @alt), of "@alt is a mandatory attribute, even if it is simply empty, see WCAG for accessibility information". It is simply the best proposal I have seen on the subject, despite the hundreds of emails on the topic. That being said, your option #4 is darned close to what I would expect and want, and I suspect it's what you favor too, given the detail you give it in your description. I do not think the two ideas are incompatible, and indeed, I think that they complement each other extraordinarily well!

> Over all, @role would open many new possibilities for better
> validation services:
> Repeated alt could trigger a response. (It would be ok for IMG-s
> with e.g. role=logo, but unexpected with some other roles.) Some
> loopholes could become narrower. (Use of white-space in order to
> achieve conformance should e.g. throw an error if the role is
> role="logo".) @Role would allow the validator to apply
> "heuristics". (E.g., for advice, the validator could "calculate"
> whether the presence of role="logo" one one IMG, lowers or
> increeases the chance that role=private-undefined on another seems
> correct, or not.)

I agree 100%! I think that @role not only opens up great things for validation, but also for search engines and any other "Semantic Web"-consuming/parsing application. But I also think it's way too much to ask of many (if not most) HTML authors to always use it, let alone use it correctly (much like @alt, sadly).

Received on Wednesday, 20 August 2008 05:25:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:25:22 UTC