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

Benjamin Hawkes-Lewis, Sun, 1 May 2011 12:09:32 +0100:
> On Sun, May 1, 2011 at 7:22 AM, Leif Halvard Silli:
>> So how could I unconfuse "the comparison between ordinary authors using
>> WYSIWYGs and this special selection"?
> 
> You can't. They're different groups, that's my point.

I'll check once more.
 
>>>> But b[e]low 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?
>>> 
>>> Not sure, but the exemption is intended to cover situations where there
>>> is no author-provided @alt, so the quality of @alt values provided by
>>> authors doesn't seem relevant.
>> 
>> 'Meant to cover':  But there is an interaction here. Below you said
>> that the intention of the generator exception is that it is better to
>> omit the alt rather than automatically inserting a (potentially) bogus
>> alt. Clearly, that rule, if it is valid, is valid regardless of the
>> tool you use.
> 
> If you mean bogus @alt values inserted by human beings, whether to
> placate an authoring tool prompt or a validator, harm end-users,
> that's true.

Thus, I don't really see why, eventually, only generators need this 
exception. I see no other justificaiton in the CP than the wish - 
expressed in the CP -  to make sure that conforming authoring tools are 
not blamed for the author's errors.

> 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. 
 
>> '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 and if 
not, the tool has to run a check or ask the author to run a check.

Also, despite your many negative words against prompts: When the author 
answers a prompt to insert @alt, then the result is not boileplate @alt 
unless the author refuses to give an answer via a cancel option or 
similar.

You seem to draw a strong line between "author has negative attitude" 
and "bogus @alt". But those are really different issues.

> Obviously the validator
> still doesn't test to see if @alt's are boilerplate. The only way
> to make that assessment is with something like the Image Report
> at validator.nu.
> 
>>>> Or do there exist generators which, in order to be "valid",
>>>> automatically inserts empty alts all over, without asking the tool
>>>> user?
>>> 
>>> Ayreh reported that MediaWiki does this.
>> 
>> Eventually, Aryeh reported that MediaWiki tries to please *HTML4*.
>> While we are talking about pleasing HTML5, which has a special rule for
>> images that act as links.
> 
> If you meant are there "do there exist HTML5 generators", I've no idea.

I did not mean that. I meant that the evidence has to be *relevant*. 
The situation has to be equivalent. Aryeh's example may placate a HTML4 
validator, but it would not placate a HTML5 validator where it is MUST 
to have non-empty @alt in image links.

Given that MediaWIKI has a specific set of link types, related to the 
inner worksing of MediaWIKI, it should be possible to design a way to 
make such image links accessible. Note that the image could very well 
be empty, provided that there were related caption text inside the 
anchor element.

> 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.
 
>>>>> 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.
>>> 
>>> I don't see this at:
>>> 
>>> 
>> 
http://www.w3.org/2002/09/wbs/40318/issue-31-80-validation-objection-poll/results#xwarning

>> 
>> I too wondered who this "another commenter" (that Maciej quoted in the
>> Decision) was:
>> 
>> ]]
>>    Therefore
>>    we need a way for validators and authoring tools to coordinate so
>>    that validators will not criticise conforming authoring tools when
>>    a problem (in this case missing alternative text) is the user's
>>    fault and not the author tool's.
>> [[
>> 
>> http://lists.w3.org/Archives/Public/public-html/2011Apr/0451

>> 
>> Having looked it up, it turns out that the "another commenter" is non
>> other than Ian, in his original proposal for ISSUE-31 and ISSUE-80:
>> 
>> http://lists.w3.org/Archives/Public/public-html/2010Jul/0050

> 
> Reading this, the end-users still seem to be the only stakeholders under
> motivating the exemption. That some authoring tools want to produce
> valid output is just a fact of the market.

Actually, Ian quoted Gez who said: "It should be considered invalid 
because it is inaccessible". 
 
>>> 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.

Disagree. HTML5 describes how to do it: look for title of the target 
etc. If the tool did it itself, then it can also verify that it 
followed HTML5's description. If the link text was provided by another 
tool, then of course, it is not machine checkable. But it is machine 
checkable that it must be non-empty. Further checks in more advanced 
chekcing tools.

So, technically the  CP is wrong whe it says that "there's no way for a 
machine to know that the image really is presentational". Because there 
it is sometimes possibel to know.
 
>> 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".

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.

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 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.
 
>> Idea:
>> 
>> 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.
 
>>>> 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.
>>> 
>>> Even tools that conform to the current ATAG2 working draft
>>> could find themselves in situations where there is no author-provided
>>> @alt. Read the small print at:
>>> 
>>> http://www.w3.org/TR/2011/WD-ATAG20-20110426/#principle_b1

>>> 
>>> For example, a WYSIWYG authoring tool could allow a user to drag and
>>> drop an image onto a webpage then popup a dialog asking for an @alt.
>>> The user could tick a checkbox on the dialog indicating that they do not
>>> want to provide an @alt and do not want to ever be asked for an @alt
>>> again. Such an authoring tool would conform to ATAG2 as it stands.
>> 
>> Does ATAG2 say that the author, in a context-dialog for a particular
>> image, MAY be allowed tick of that (s)he never wants to be asked for an
>> @alt ever again, as long as he uses that app? Really?
> 
> By my reading, yes. Where do you think ATAG2 makes that non-conforming?

It is probably not formally incorrect to do what you said. But my point 
was that, for lasting preference changes, then the application's 
preferences is the place to go. Only preferences that the user expect 
to change relatively often should go into the day-to-day user 
interface. Deeper changes should be offered inside the application 
prefs panel. To, evertime the programme prompts for @alt,  offer to the 
user to fundamentally change this behaviour - without going into prefs 
first, does not sound correct. 
 
>> Can you show me such a tool?
> 
> I'm unaware of any ATAG 2 conformant tool.

It is still a working draft.
 
> 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. May be we should mention the Validator.nu image report 
too?  
 
> I played with a demo and created an article. I uploaded an image to the
> article. There was no dialog, but once the image was added there was a
> input box for "Alternate text" somewhere in the editing view. I ignored it.
> Drupal generated:
> 
>    <img typeof="foaf:Image"
> 
src="http://mydemo.opensourcecms.com/drupal9377/sites/default/files/styles/large/public/field/image/{my-filename}.jpg"
> alt="">

That is not how BlueGriffon operates. In BlueGriffon, one must actively 
tick off that the image is presentational. There simply is no 'OK' 
button in the image dialog unless you EITHER provide alt text OR tick 
of the 'Allow an empty alternate text'.
 
> Drupal doesn't need to give me an option to hide the "Alternate text"
> prompt, because ignoring the input box and letting it insert boilerplate
> costs me nothing.

ATutor works better than you describe here. 
 
>>> 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.

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

>>> (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".
 
>>> So we should not only consider dilemnas faced by
>>> ATAG2-complying generators but try to understand and influence
>>> developer behavior more generally.
>> 
>> We should try to understand author behaviour, yes.
>> 
>> We should also try to understand generator developers: if I were one,
>> then I would never permitted that the string which identifies that
>> authors have used my tool should be used to specify how authors could
>> author @alt.
>> 
>> How, eventually, do you feel that the generator string solution shows
>> improved understanding for 'author behaviour'?
> 
> I was talking about developers of generators not authors of webpages.

Sorry, some mean 'author' when they say 'developer'.

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

[1] 
http://www.w3.org/TR/2011/WD-ATAG20-20110426/#def-Author-Actions-Prevent  
--
leif halvard silli

Received on Monday, 2 May 2011 02:48:40 UTC