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

Benjamin Hawkes-Lewis, Mon, 2 May 2011 09:45:21 +0100:
> On Mon, May 2, 2011 at 3:48 AM, Leif Halvard Silli:
>>> HTML5's original solution to that was to not require
  [...]
>>>> 'Situations where there is no author-provided @alt': So, do you say
>>>> that it also covers situations where there is a tool-provided @alt as
>>>> well? Meaning that the generator exception can justify boilerplate
>>>> @alt-s (empty or non-empty) as well as no alt at all? Hm ...
>>> 
>>> What do you mean by "justify"? The purpose of the exemption is
>>> to prevent tools providing boilerplate @alt.
>> 
>> An ATAG compliant tool doesn't - from *its* side - provide
>> 'boilerplate @alt'. It can provide automatic generation of content, but
>> then the generated content has to be guaranteed to be accessible
> 
> By default option and unless author actions prevent generation of
> accessible web content, in which case it would still have to generate
> /something/.

Reformulation of what you said in previous reply: "The purpose of the 
exemption is to permit tools to omit the @alt as alternative to 
generating something." 

We have 3 alternatives: non-empty, wrong non-empty @alt, wrong empty 
@alt and @alt-omission. I agree that if the tool has the option to be 
nominally valid even if there is no @alt, then this increases the 
chance that @alt is omitted instead of  generating an @alt.

>> You seem to draw a strong line between "author has negative attitude"
>> and "bogus @alt". But those are really different issues.
> 
> Not sure what we're talking about here.

Read "link" rather than "line".

 [...]
>>>>> Also I don't buy it as a plausible motivation. There's basically no cost
>>>>> to generator developers to pump out pages filled with autofilled
>>>>> alt="" and alt="Image", so there's no incentive for them to change
>>>>> the status quo beyond actually caring about end-users.
>>>> 
>>>> This is not true. Not anymore. There is a cost: HTML5 describes how to
>>>> create link text. There is a cost to figure out how to do so when the
>>>> link text is inside an img element. (Remember that HTML5 makes it a
>>>> MUST to, in that case, provide alt text that is useable as link text.)
>>> 
>>> That MUST is not machine-checkable. They could output alt="Image"
>>> everywhere and the validator would not raise an error or warning.
>> 
>> If the link text was provided by another tool, then of course, it is
>> not machine checkable.
> 
> Exactly. What will affect generator developer behavior is what the HTML5
> validator says when authors put the generated markup through the
> validator. The validator cannot check for bad link text, only missing
> link text.

That the same for *any* link text - visible too, which are often bad. 
The problem that Ian's CP took up was that it is not machine checkable 
whether the it is correct to have an empty @alt.

>>>> Btw, with regard to Ian's need for a way: what is needed, then, in
>>>> order to put the blame on the right person, is have a way to tell
>>>> whether teh alternate text error is the author's responsibility or the
>>>> tools responsibility.
>>> 
>>> The purpose of the exemption is not the allotment of blame, but
>>> the reduction of tool-provided bogus @alt attributes.
>> 
>> Please read the quote above of what Ian said once more. For the record:
>> ATAG too speaks about "blame".
> 
> The only point of alloting blame in Ian's CP is to discourage authoring
> tools from inserting bogus alt text.

Ian cited Gez, who said that tools shouldn't insert anything when 
authors are "adamant they're not going to provide alt text". Ian 
followed up that quote with an argument which had to do with blaming 
the author rather than the tool.

So, I agree with you that the point is to not remove from their table 
of options that he @alt can be omitted.

There is one problem in the line of thought, here, though: If the 
author consciously says nay to @alt, then I believe a conforming 
authoring tool will also explain that it is invalid to not provide 
@alt. I don't understand why authors would believe the tool is buggy 
when they themselves said no to adding @alt.

>> Also, again, you seem to mix "tool-provided bogus" and "humanly added
>> bogus": If the author answer a prompt in a mechanical way, then the
>> answer is his/her responsibility - and not the tool's.
> 
> That's what Ian's CP says.

If we agree about reality description, then there is no problem.

>> I will also note that you have agreed that it is always correct of a
>> tool to use the genrator string. I therefore don't believe that it is
>> the intention of the generator exception that the tool does not prompt
>> the user for @alt text. This has to be wrong. There is nothing in Ian's
>> texts about when it should be inserted.
> 
> I didn't say the intention of the generator exception was that tool
> never prompt for @alt?

I guess not. But you did talk quite much about the problem that the 
author might say no to ever add @alt.

>>>> I think, then, there would need to be a flag to be inserted into the
>>>> <img> (or <area> or <input type=image >) each time the @alt content is
>>>> provided by the tool rather than by the author. In that case, an AT
>>>> user or non-visual user could, if the @alt text is meaningless, inspect
>>>> the code and blame the right person/tool.
>>> 
>>> How would this improve the everyday user experience over not inserting
>>> boilerplate @alt in the first place?
>> 
>> If it can be verified to have been inserted by the tool, then the tool
>> can be corrected, if it has a bug. Else, the author can be corrected.
> 
> Same with missing @alt, so this doesn't sound like an improvement.

The improvement is that it is possible to check without having omitting 
the @alt first. Tools that try to fulfil ATAG has to/can auto-generate 
alt text regardless of such a HTML-validity exception.

>>>> We could define *all* empty @alt's as tool-inserted. Whereas for
>>>> non-empty @alt, we could "say it how it is". This, because, sometimes
>>>> it is clearly wrong to have an empty @alt, in which case the tools
>>>> should fix it somehow. Whereas when there is a non-empty @alt, then it
>>>> is the quality of if that matters.
>>>> 
>>>> If the tool *knows* that the image should have an empty @alt, then
>>>> there is no need to provide the user with the option to insert @alt -
>>>> tool can just insert it.
>>> 
>>> How would this improve the everyday user experience over not inserting
>>> boilerplate @alt in the first place?
>> 
>> I think you must define what you mean by 'boilerplate'. Preferably find
>> another word.
> 
> Routine insertion of the same text.

You mean "routine _author_ insertion of same text"? 

> e.g. alt="Link" for link images, alt="Button" for button images, alt=""
> for other images.

Author inserted or tool inserted? If the tool reminded the author that 
the alt was to be link text, then it is quite likely that author 
inserted a better text.

Anyway, in face of alt=link, then the author has reason to believe it 
is link text. Which should be much simpler to check for relevant-ness, 
rather than the omission of @alt.

>>> Drupal claims to be aiming for ATAG 2 conformance, and to have improved
>>> image handling towards that goal.
>>> 
>>> http://drupal.org/about/accessibility

>> 
>> ATutor also does things like that:
>> http://html4all.org/pipermail/list_html4all.org/2011-April/001130.html

>> 
>>> (Incidentally, this is an example we could cite in support
>>> of "A demonstrated trend towards more authoring tools fully supporting
>>> ATAG2, including the requirement to prompt for textual equivalents
>>> for images" if we're willing to call one product a trend.)
>> 
>> Two with ATutor.
> 
> Here's a citation for their intent to conform to ATAG2:
> 
> http://atutor.ca/atutor/docs/ATutor_brochure.pdf


That's a link, and not a citation. If you think that document proves 
something, then please point to paragraph and explain what it proves. 

>> May be we should mention the Validator.nu image report
>> too?
> 
> I'm not sure Validator.nu is relevant, since it's not a markup
> generator. Does it have an explicit commitment to support ATAG2?

Don't know.

>>>>> The generator exemption would allow the authoring tool to insert no @alt
>>>>> in this situation instead of a bogus value.
>>>> 
>>>> "This situation". Which "this situation"? Above you described several
>>>> moments in time:
>>>> 
>>>> 1. popup asking for @alt
>>>> 2. author ticking of what (s)he wants
>>>> 3. every moment since moment number 2.
>>> 
>>> 3
>>> 
>>>> The generator exception, per what you said on top of this message,
>>>> would also allow the tool to insert a bogus @alt 'in this situation' -
>>>> instead of omitting it. What is the advantage of, 'in this situation',
>>>> omitting the @alt in contrast to inserting a bogus @alt?
>>> 
>>> Bogus @alt prevents repair by user agents (e.g. filename substitution).
>>> Worse, alt="" implies that a user does not need to know the image is
>>> there.
>> 
>> Except that when it is sole content of a link, then it doesn't have
>> that implication anyhow.
> 
> It still has that implication and will still be removed from the
> accessibility tree.

For the record: img with empty alt and img with role=presentation are 
treated differently. Regardless what HTML5 says, I'm not confident that 
this will change.
 
>>> No @alt does not suffer these drawbacks.
>>> 
>>>> And for whom is it an advantage?
>>> 
>>> Users, since they get better repair text.
>> 
>> That we don't know. Many file names are extremely meaningless. A short,
>> non-empty, none-whitespace alt text may indeed be better, very often.
> 
> Not persuaded.

I can only reply: ditto.

>>>> Another flag than alt omission could be used for telling which @alt-s
>>>> are in need for a check by a human.
>>> 
>>> How would this help users?
>> 
>> By causing more correct use of @alt since those images that are likely
>> to be in most need of check can easily be found.
> 
> You could just use missing @alt for this purpose.

No, that's impossible. I suggest to check whether the @alt value is 
relevant or not. If the @alt has been omitted, then there is nothing to 
check - you must create the @alt value from scratch.

>>>>> Moreover, if we care about the accessibility of the web at large, then
>>>>> we want generators to produce more accessible content *even* if they
>>>>> don't comply with ATAG2.
>>>> 
>>>> But I don't see how the generator string lets the generator enhance
>>>> anything.
>>> 
>>> It lets them insert no @alt, which is putatively an enhancement from
>>> bogus @alt.
>> 
>> You have a very high confidence in what repair can do.
> 
> Do I?

Below you strengthen that impression on me.

>> Authors in general provide cool URIs, but uncool @alts? It seems you
>> are putting other things in this than Ian's CP did. Whether an bogus
>> alt is bad, must be investigated per image. 'Bogus' is a value loaded
>> word. But the bogus @alt can be totally OK. E.g. if the bogus value is
>> the empty string, then in - let's say - 50% of the case, an image
>> *should* have an empty @alt. In which case a bogus empty alt would be
>> correct 50% of the time. I could stretch myself to say the same about
>> @alt-omission too: sometimes it will be better than an empty alt.
> 
> Missing @alt allows accessibility tree clients to make their own decisions
> about whether to inform or not inform users about the presence of the
> image.
> 
> Empty @alt prevents this by preventing the "img" being represented in
> the tree.

Empty alt does currently not prevent this. It is only per the letter of 
HTML5 that this is prevented. I you replace "empty @alt" with 
role=presentation, then I shall agree with you.

> It is better to push information down towards UAs, for the benefit of
> tools that are more attuned to their particular user needs and for the
> benefit of cleverer future tools dealing with the legacy content of
> tomorrow.

Why is this better? When it is it better? I think we would need to make 
a lot of research to be able to declare that you are right.

>>>>> (It seems obvious to me that the vast majority will not.)
>>>> 
>>>> Can you list a tool which, w.r.t. to @alt, complies with ATAG2 and one
>>>> that doesn't so that I can compare?
>>> 
>>> No, since there are no ATAG2-compliant tools AFAIK. (Drupal is aiming
>>> to comply, but I don't have time to assess if they actually do.)
>>> 
>>> I would be positively surprised if there are ever any ATAG 2 compliant
>>> tools. There were never any ATAG1-compliant tools, Microsoft suggested
>>> ATAG2 compliance was impossible back in September 2010:
>>> 
>>> 
http://lists.w3.org/Archives/Public/public-atag2-comments/2010Sep/0004.html

>>> 
>>> Of course, it's a moving target, so this can change.
>> 
>> The feature we are discussing is, according to the CP, supposed to do
>> something only for *conforming* tools: "so that validators will not
>> criticise conforming authoring tools".
> 
> A webpage can conform to HTML5 without conforming to WCAG.
> 
> A tool can conform to HTML5 without conforming to ATAG.

In theory. But HTML5 does not define how conforming tools operate.  
Also, the chairs in their Decision discussed whether ATAG would take 
this new information into account.

>>>>>> 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?
>>>>> 
>>>>> If they noticed any change (e.g. due to the validator complaining
>>>>> about an empty alt in a link or button, or due to reading the
>>>>> specification), yes.
>>>> 
>>>> This is a good point. Which IMHO speaks against this exception.
>>> 
>>> Not sure how.
>> 
>> Having read the CP [I did my best when I answered the poll, but it was
>> the most confusing poll ever], I don't think it is the intention that
>> the generator string should be inserted as result of a author
>> behaviour. The (conforming) tool is meant to contain the string all the
>> time. And it is meant to provide the usual prompts to get the author to
>> write conforming @alt. Of course, the author would not experience any
>> validation difference regardless of whether he/she adheres to the alt
>> text prompt, and so could be demotivated. But note, as well, that the
>> generator string does not prevent WCAG validation.
>> 
>> Note also that if the author sabotages the tools accessibility
>> features, then the tool is excempted from meeting the success criteria.
>> [1]  But I don't think it makes sense  to build it into the programs
>> that they can be sabotaged. Look at BlueGriffon again. How can I
>> sabotage it? I can tick of that the image should have empty @alt when
>> it shouldn't. Or I can type a space character into the alt text field.
>> But it has no "I don't care" mode.
> 
> This is not obviously better, since @alt provided by apathetic authors
> may often be worse than user agent repair, whereas @alt provided by
> motivated authors should almost always be better than user agent repair.

Rather than describing what not to do and all the dangers you see, 
perhaps describe what do do?

> Anyhow, I still don't really understand how authoring tools actually
> implementing the generator string and not robotically inserting routine
> alt="" or filenames to placate the validator would argue /against/ the
> exception, since this is precisely the sort of behavior it's supposed to
> lead towards.

You seem to actually like Drupal's behaviour better than BlueGriffon's 
behaviour, with the exception that, instead of adding an empty @alt, 
Drupal should not have have added any @alt.

But regardless of omission of @alt or current behaviour, it seems that 
Drupal, if it wants to be accessible, needs a post-edit checking tool.
-- 
leif halvard silli

Received on Monday, 2 May 2011 17:56:48 UTC