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

Benjamin Hawkes-Lewis, Sat, 30 Apr 2011 20:51:40 +0100:
> On Sat, Apr 30, 2011 at 11:03 AM, Leif Halvard Silli wrote:
>> Benjamin Hawkes-Lewis, Sat, 30 Apr 2011 10:10:00 +0100:
>>> On Fri, Apr 29, 2011 at 11:48 PM, Leif Halvard Silli wrote:

>>> 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 ...
> 
> I'm talking about the "pioneers" you selected, not authors using
> generators.

So how could I unconfuse "the comparison between ordinary authors using 
WYSIWYGs and this special selection"?

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

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

>> 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. Adding an </p> in a XHTML document served as 
text/html is also just "pleasing", no? Aryeh's example and the </p> in 
HTML are comparable because they are - both of them - without effect. 
(At least in VoiceOver, when used as a link, it doesn't matter whether 
the @alt has the empty string or no alt at all.) [It does matter, 
however, if a such img has a non-empty @title.]

>>> 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.
> 
> Maybe? Does it matter? It still seems to me versioning is a rabbit hole
> that takes the discussion a long distance from stakeholder needs that
> should be at its centre.

May be you are right. I will think about it. (But as you saw, I have 
made this point softer in last draft.)

 [...]

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


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

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. 

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.

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.

>> 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? Can you show me 
such a tool? 

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

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? And for whom 
is it an advantage?

I could imagine one advantage: some author removes the generator 
string, and is then asked for @alt, but only for those images which 
have @alt omitted. This would be an advantage for that author.

But if it, for the users, is better to have a bogus alt rather than 
no-alt, then I'd say user comes first. Another flag than alt omission 
could be used for telling which @alt-s are in need for a check by a 
human.

> 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 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? (And please don't come with 
MediaWiki once more. At least, present me with an author situation 
rather than a bug report - with multiple interpretations.)

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

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

Received on Sunday, 1 May 2011 06:23:09 UTC