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: Fri, 29 Apr 2011 21:13:18 +0100
Message-ID: <BANLkTi=uNheQFSbb8yu1x7Tbw9wnrdwLtA@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 Fri, Apr 29, 2011 at 8:18 PM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
>>>   Additionally, since the HTML5 validators does not currently perform
>>> any validation of whether alt is present at all or of how it is used,
>> This is incorrect. See the "Show image report" feature at
>> http://validator.nu/.
> I maintain that this is correct. There are two validators: validator.nu
> and validator.w3.org. Only the former has an image report. But the
> image report is just that - a report.

Fair response. I still think this compromises the purity of the test.

> The selection consists of pages made by "HTML5 pioneers" and people who
> teach others about HTML5 authoring. These are "to notch" authors and
> not "average joe".

I've rarely found tech-hype pages of this sort to be beacons of best
practice; usually the reverse.

Top-notch HTML authors shouldn't need a validator to remind them to
include an @alt.

>>> A generator exception for img elements remains a form of
>>> versioning.
>> I find this argument sophistic.
>> Document versioning was dumped from HTML because having versions trigger
>> multiple code paths in user agents did not solve any problems the WG
>> agreed were worth solving.
>> The generator exception does not require multiple code paths even in a
>> conformance checker, it's just yet another rule in its ruleset, and it
>> does *try* to solve a important problem (specifically, the generation of
>> bogus "alt" text).
> * the generator string creates "multiple code paths" in tools which
> generate web pages

How? Such tools should apply the generator flag. That's one code path
not two.

> and in the heads of the authors.

I don't find this metaphorical leap persuasive.

> * by your reasoning here, the difference between 'transitional' and
> 'strict' is not related to versioning.

Transitional doctypes triggered almost standards mode in Gecko,
so they invoked multiple code paths.

My impression is that the WG rejected versioning to avoid code branching
in web engines to deal with HTML5 differently than other text/html based
on some magic string at the top of the file (as originally requested by
Microsoft, for example). Such code branching is bad because it hurts the
competiveness of the browser market by significantly increasing the
burdens on browser makers. I'm not saying there have not been other
arguments, but that stands out to me as the one that actually mattered
over the years.

I don't think the WG will see itself as having nailed itself to the
cross of making no difference in conformance requirements for different
situations, so I think trying to hook ourselves to the no-versioning
cart does us no favors here.

I think we're stronger making arguments directly from clearly
articulated user, author, or implementor needs or problems. If we can
cite specific rationale from past decisions, all the better.

e.g. Authors expect validators to act in a transparent manner. If the
validator silently passes over missing @alt in generated code that will
trick authors who are used to errors raised over their hand coding into
thinking they haven't missed an @alt.

>>> Authoring tools vendors are not going to be willing to stamp their own
>>> code as substandard, let alone use their own product names as a
>>> sub-quality marks.
>> The generator flag doesn't establish two tiers of document quality
>> beyond the
>> obvious - generating good text alternatives requires human input.
> I don't see that you contradict what the text says.

I don't think the text is a realistic portrayal of how vendors
will see the flag. Maybe find some tool vendors who
would actually refuse to use the flag, so that we have
specific evidence of this?

>>>   Authoring tools use the generator string as a kind of signal to
>>> those who view source - to identify pages made by their product.
>> How many any authoring tools that do not have any features for automatically
>> generating markup insert the generator flag? If they generate markup,
>> then the generator flag is appropriate.
> What is not appropriate is for the spec/validator to draw any
> conclusions about the @alt usage based on the fact that it is a
> generator made page.

I think it is entirely possible to make a good inference about markup
that does not reflect the intention of an author, so I disagree that
this is intrinsically wrong. And in this case, we're talking about an
inference made from a statement by the author (or their tool), rather
than just some random quirk of the markup.

Benjamin Hawkes-Lewis
Received on Friday, 29 April 2011 20:13:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:54 UTC