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

Benjamin Hawkes-Lewis, Fri, 29 Apr 2011 23:02:34 +0100:
> On Fri, Apr 29, 2011 at 10:08 PM, Leif Halvard Silli wrote:>
>
>>>> 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.
>>
>> And (text) authors shouldn't need dictionaries?
>>
>> I think everyone needs a validator.
>
> 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.

>>>> * 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.
>> 
>> HTML5 doesn't make it *obligatory* for generators to use the generator
>> flag. If it were obligatory, the much less should there be a 'generator
>> exception'.
> 
> Either a generator chooses to use the flag or it doesn't. It doesn't need
> two code paths to be conforming. (It might want to give authors an option,
> but that's not required by spec.)

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

>>>> * 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.
>> 
>> And apart from that, they were OK?
> 
> I wouldn't go that far; I'm just talking about code paths. :)

It seems that the transitional/strict/half-strict doctypes for the most 
part affected parsers, which was bad enough.

>> The generator exception would burden developers and authoring tools
>> creators. E.g an author who wants full validation must remove the
>> generator string via post-editing with a text editor. Or the generator
>> must offer a way to not publish the generator string. Or a new kind of
>> generator flag would be invented by the tool vendors (e.g. a HTML
>> comment ...).
> 
> Hmm. I think I'd pitch the failure to removal the flag in terms of
> errors costing users rather than being a massive burden to authors.
> 
> Users will lose out when images miss @alt text because:
> 
>   * Authors take tool output (e.g. via Tidy) as the basis for 
>     handcoding, but forget to remove generator flags.

Exactly. Forget or find it impractical.

>   * Novice authors copy-paste code that includes the generator flag,
>     without understanding its effect they have on conformance checkers.

Right. Good points.

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

>> Second: I am embarrassed to ask them - I'm ashamed
>> about the entire, childish exception. Having to spend hours to get the
>> chair to reopen this issue is  ... well.
> 
> Understood.
> 
> The reason I suggest asking is that the Chairs have stressed that 
> they look for concrete examples to support claims like this when
> evaluating the strength of objections.

There is one example mentioned: what Aryeh said about MediaWiki. See 
the first paragraph. Aryeh was, as I understood it, focused on the 
need, due to 'those authors', for the exception.

One reason why I won't ask is that I don't think we need the kind of 
answers that Maciej gave to John: a promise that Apple finds 
accessibility very important. What was that meant to mean? That we can 
just keep the generator exception because Apple will produce high 
quality code regardless, because they have a higher bar than that 
exception?

But if evidence pops up before Monday, one could of course discuss to 
add it on the meeting then.

[ snip ]
-- 
leif halvard silli

Received on Friday, 29 April 2011 22:48:54 UTC