W3C home > Mailing lists > Public > public-html-a11y@w3.org > April 2011

Re: [text] updated draft of clarification on alt validation

From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Date: Sat, 30 Apr 2011 20:51:40 +0100
Message-ID: <BANLkTimZp9tw=rv87yxByMT5B_-Mwk6J+g@mail.gmail.com>
To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Cc: Judy Brewer <jbrewer@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
On Sat, Apr 30, 2011 at 11:03 AM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> Benjamin Hawkes-Lewis, Sat, 30 Apr 2011 10:10:00 +0100:
>> On Fri, Apr 29, 2011 at 11:48 PM, Leif Halvard Silli wrote:
>> If they choose to omit @alt as a statement, then they are indeed
>> unconcerned about the accessibility drawbacks of doing so and I think
>> that confuses the comparison between ordinary authors using WYSIWYGs
>> and this special selection.
> You say "if they choose". This implies, to me, that if the author uses
> a "generator" of some sort, then he/she has no choices to make - it is
> all automatic ...

I'm talking about the "pioneers" you selected, not authors using

> But blow you speak about "bogus alt" and mention as example empty alt.
> Are users of generator tools really more prone to insert empty alt
> than others?

Not sure, but the exemption is intended to cover situations where there
is no author-provided @alt, so the quality of @alt values provided by
authors doesn't seem relevant.

> Or do there exist generators which, in order to be "valid",
> automatically inserts empty alts all over, without asking the tool
> user?

Ayreh reported that MediaWiki does this.

>> I don't think the complexity of code branching required to implement
>> the generator exception is remotely comparable, so I doubt this will
>> trigger the vendor resistance that underpins the WG's resistance to
>> "versioning". Someone could be deterred from or impaired in creating
>> a new browser by proliferation of rendering modes; nobody seems
>> likely to be deterred from or impaired in creating a validator (or an
>> authoring tool including a validator) by this exemption on code
>> complexity grounds.
> I do think that the generator exception can deter/delay vendors from
> implementing better solutions. And it is an extra burden for authors
> to, eventually, create two user experiences for its users - one
> without generator and one without generator.

> But I can agree that the generator exception is not as worthy the term
> 'code branch' as 'transitional/quirks' is worth it. But this, then, is
> the same for the old WYSWYG editor exception in the working draft of
> January 2008.

Maybe? Does it matter? It still seems to me versioning is a rabbit hole
that takes the discussion a long distance from stakeholder needs that
should be at its centre.

> However, two things:
> 1) the the transitional/strict versions weren't planned to have
> anything to do with quirks/strict mode - that was, so to speak - an
> 'add on' ... Thus, it had nothing to do with code branch, to begin
> with.

Yes. I think this reflects the fact that the previous iteration of web
standards (1998-2002) was a normative programme for what should be that
was incompatible with processing existing content and did not provide
enough detail for interoperability with future content. On the whole, I
think this iteration of web standards is doing much better at describing
what is required for interoperability.

> 2) We can't, thus, really predict what becomes of versioning.

Nothing is certain. But getting vendor agreement on the details of how
to process and generate HTML, including error handling, makes it
possible to make much better predictions.

>> The goal of the generator exemption is to help *users* by allowing
>> generators to produce markup that appears to conform in validators
>> *without* inserting bogus @alt text that harms *users*, such as
>> alt="".
> I do get this, sort of. (I planned to write that that that is how
> Ian's theory goes, but apparently didn't.) But I don't trust that this
> is the sole motivation of everyone. In the poll, saving the tools from
> its users was also something we saw expressed as motivation.

I don't see this at:


Also I don't buy it as a plausible motivation. There's basically no cost
to generator developers to pump out pages filled with autofilled
alt="" and alt="Image", so there's no incentive for them to change
the status quo beyond actually caring about end-users.

> I also do not understand how it is going to work: in order to not
> trigger the author to insert an erroneous/bogus @alt, the tool has to
> simply accept what its users do, without asking questions. As far as I
> can see, it can only function in  authoring tool that is completely
> silent.
> The generator exception thus seems like an expression of distrust in
> ATAG2.

Even tools that conform to the current ATAG2 working draft
could find themselves in situations where there is no author-provided
@alt. Read the small print at:


For example, a WYSIWYG authoring tool could allow a user to drag and
drop an image onto a webpage then popup a dialog asking for an @alt.
The user could tick a checkbox on the dialog indicating that they do not
want to provide an @alt and do not want to ever be asked for an @alt
again. Such an authoring tool would conform to ATAG2 as it stands.

The generator exemption would allow the authoring tool to insert no @alt
in this situation instead of a bogus value.

Moreover, if we care about the accessibility of the web at large, then
we want generators to produce more accessible content *even* if they
don't comply with ATAG2. (It seems obvious to me that the vast majority
will not.) So we should not only consider dilemnas faced by
ATAG2-complying generators but try to understand and influence
developer behavior more generally.

>> When you argue generator developers will not implement this, you are
>> suggesting that generator developers that will not (a) add the flag
>> (or keep adding it) and (b) omit @alt where they would otherwise
>> insert bogus @alt text. This seems unlikely to me, given the only
>> reason to insert bogus @alt text was to placate validators (as Aryeh
>> gave evidence in the case of MediaWiki).
> So, is what you are saying that it is likely that authors/vendors
> which insert bogus alt only in order to validate, are also likely to
> grasp the opportunity to insert a generator string, as well?

If they noticed any change (e.g. due to the validator complaining
about an empty alt in a link or button, or due to reading the
specification), yes.

Benjamin Hawkes-Lewis
Received on Saturday, 30 April 2011 19:52:08 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:19 UTC