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

On Mon, May 2, 2011 at 3:48 AM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
>> HTML5's original solution to that was to not require
>
> Rather than 'not require' you probably meant 'not require for
> validity'.  HTML5 has always required @alt.
>
>> @alt at all, so that all values of @alt would reflect a conscious
>> choice to add an @alt. But this approach proved politically
>> unacceptable.
>
> Fruitless comment, that last sentence.

The HTML5 spec is produced by a political process that tends to work
against taking any given principle to extreme logical conclusions. In
this case, the conclusion you suggest (of never flagging missing @alt as
an error or warning) was rejected through that process.

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

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

>> Currently, image validation is still be implemented in the validator, so
>> it's hard to test what tools would do in the absence of the generator
>> exemption.
>
> Absolutely. Yet that is what the chair asked for.

Well, we do have the option to wait and see what happens when the
validator is updated to reflect the Decision and new authoring tools
are produced targeting HTML5, at which point we'll actually have
new information.

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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.

--
Benjamin Hawkes-Lewis

Received on Monday, 2 May 2011 08:45:50 UTC