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

On Fri, Apr 29, 2011 at 10:08 PM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> 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.

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

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

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

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

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

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

> Elsewhere you have hinted that generators should/must insert a
> generator string.

The spec just says not to use the generator flag on hand-authored pages:

http://dev.w3.org/html5/spec/semantics.html#standard-metadata-names

--
Benjamin Hawkes-Lewis

Received on Friday, 29 April 2011 22:03:02 UTC