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

Benjamin Hawkes-Lewis, Sat, 30 Apr 2011 10:10:00 +0100:
> On Fri, Apr 29, 2011 at 11:48 PM, Leif Halvard Silli 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.

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

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? Or do there exist generators which, in order to be "valid", 
automatically inserts empty alts all over, without asking the tool user?

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

Right.

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

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.

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

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

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.

Currently, this over-focus on the risk for providing incorrect @alt 
text, has lead to a working group decision which blesses it as "valid" 
to not have link text, as long as the link text is supposed to be in 
the @alt.

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. 

> 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?
-- 
leif halvard silli

Received on Saturday, 30 April 2011 10:04:18 UTC