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 10:10:00 +0100
Message-ID: <BANLkTimYBxMvSoT_t-HJHdz-gYLXO2DUOw@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 11:48 PM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
>> My point is not that "top-notch authors" don't find value in
>> validators, but that if "top-notch authors" are failing to include
>> @alt all over the place in hand-authored pages then they're
>> unconcerned about the accessibility drawbacks of doing so, rather
>> than unaware of them.
>
> My point was actually that those HTML5 pioneers that I listed probably
> are aware of the debate about @alt in HTML5 and that this plays a role
> in why they have omitted @alt. Also, the theory of Ian is that it
> hurts accessibility to display an error message when @alt is omitted.

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.

> 'Code path' needs a definition. Clearly, if a generator behaves
> differently with regard to what it does for image accessibility when
> it uses the flag compared to when it doesn't use the flag, then that
> represents two code paths, no?
>
> Since many generators will rely on online or embedded versions of the
> official validator, then - unless they modify the validator - it is
> highly likely that they *will* behave differently with and without the
> flag. Or, even if they formally don't behave differently, the author
> may perceive that it does.

I think you're right to say code path needs a definition.

Strictly speaking, any feature involves a code branch.

But proliferation of rendering modes (e.g. quirks mode vs. standards
mode vs.  the proposed HTML5 mode) involves code branches sprinkled
throughout the code base, the multiplication of test suites, and a much
longer spec. 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 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?
>>>
>>> I'm not going to look for any authoring tool vendors ... Firstly:
>>> what should I ask them?
>>
>> Point them to the relevant bits of spec, then ask them if they will
>> apply the flag in the next version of their product, and if not, why
>> not.
>
> If the generator exception is meant to please vendors, the most
> relevant question to ask perhap sis whether they need such an
> exception.

The goal of the generator exemption is not to please vendors.

It's important we get this right when talking about it, because
otherwise we'll sound like we don't understand the problem.

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="".

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).

--
Benjamin Hawkes-Lewis
Received on Saturday, 30 April 2011 09:10:28 UTC

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