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

On Sun, May 1, 2011 at 7:22 AM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> 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.

>>> 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. HTML5's original solution to that was to not require
@alt at all, so that all values of @alt would reflect a conscious
choice to add an @alt. But this approach proved politically
unacceptable.

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

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

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

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

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

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

> Can you show me such a tool?

I'm unaware of any ATAG 2 conformant tool.

Drupal claims to be aiming for ATAG 2 conformance, and to have improved
image handling towards that goal.

http://drupal.org/about/accessibility

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

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

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.

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

No @alt does not suffer these drawbacks.

> And for whom is it an advantage?

Users, since they get better repair text.

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

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

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

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

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

--
Benjamin Hawkes-Lewis

Received on Sunday, 1 May 2011 11:10:02 UTC