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

Benjamin Hawkes-Lewis, Mon, 2 May 2011 23:21:05 +0100:
> On Mon, May 2, 2011 at 6:56 PM, Leif Halvard Silli:

> I think one drawback with that is that many authors value validity
> higher than accessibility and will concoct boilerplate text of their
> own.

With @alt as part of the HTML validity concept by necessity gives 
formal adherence a high value.

>>> 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.
> 
> Yeah, it's primarily a thought experiment to provide a clear example of
> how even an ATAG2-compliant tool can generate boilerplate @alt.

ATAG2 tools MAY "generate boilerplate"/insert templates: 
http://www.w3.org/TR/ATAG20/#principle_b1

>>>> 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"?
> 
> No, not particularly.

Both tool and author may detect a pattern, where same/similar text 
fits. So a routine does not need to be bad.
 
 ...
>> 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.
> 
> Is your underlying concern here: how do we make it easy for authors
> to check autogenerated text alternatives? Is this a common problem?
> Particularly, how much value would this really add over just checking
> all text alternatives, as with the Validator.nu image report?

THe value of each image should be checked. But if someone uses a CMS, 
checks the pages and gets @alt errors (that is: @alt omission errors or 
emtpy-alt errors inside links), then it would be "nice" if the 
validator user could get a message which said "hey, you yourself was 
responsible for this".

Your answer will probably, once again, be that there is a risk that the 
author simply inserts dysfunctional @alt text. If so, perhaps what is 
really needed is to offer authors to test the page in simple text 
format, so they for themselves can experience the page without images. 
May be that will help?

One of the poll voters suggested to have flag per image. And in my own 
change proposal, I have proposed the same thing as you - that no-alt 
should be the flag. So I am still thinking.

>>>>> Drupal
  [...]
>>>>> (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.
> 
> It contains a formal claim by ATutor that they plan on conforming to
> ATAG2 (see the "Accessibility" section). It's a document that backs up
> your claim that ATutor is another example of the "trend".

Thanks!

>>> 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.
> 
> Without taking a position on whether your lack of confidence is
> misplaced, I don't think we can present a TF email contesting the
> Decision that argues on the one hand that authors *must* be allowed to
> omit alt="" when including role="presentation" because they *must* be
> functionally identical, 

I don't support that authors must be allowed to omit @alt when 
role=presentation is present. So I will not put name on something which 
says that. My use of "confident" was wrong: That AT probably won't 
change is just a secondary argument. The primary argument why I don't 
support it is because it is a layer violation. ARIA isn't part of HTML5 
anymore than SVG is.

> and on the other that tools robotically
> inserting alt="" is fine because user agents will interpret it
> differently to role="presentation"!

Robotically inserting @alt="" is not fine. But you, throughout, 
emphasize that there is uncertainty and doubt that authors will not 
simply insert dysfunctional @alt values. I just wanted to lower the - 
dare I say - FUD one millimetre by pointing out that AT, in praxis, 
*DO* use images with empty @alt for repair purposes. At least when the 
image is inside a link.

> If the TF premises our requirements for conformance tools on user
> agent behavior contrary to the spec, then I think any CP put forward by
> the TF must propose changes to the spec to require that user agent
> behavior.

Yes, I think Richard should indeed do so. After all he wants to 
deprecate @alt: 
http://lists.w3.org/Archives/Public/public-html-a11y/2011May/0022

Otherwise, filed a bug against the 'HTML to Platform Accessibility APIs 
Implementation Guide':

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12587

> If we cannot agree on the treatment of alt="", then we should be open
> about that disagreement to avoid sounding incoherent

Indeed.

> and ensure we have
> either have at least one consistent position that does not depend on
> either treatment of alt="", or have at least two consistent positions
> expressing different views about the treatment of alt="".

Agree. 

>>>> 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.
> 
> If a tool can generate good enough text alternatives, then it should do
> so.
>
> Unless you're claiming that it can virtually always can do so, then you
> still have to tackle the situation when it can't.

Of course, ain't gonna be perfect.
 
>>> 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.
> 
> User agents can express the situational preferences of users where
> authoring tools cannot. For example, a user might want alt="" images
> hidden from them in the normal course of operations. But maybe they have
> a sudden need for one of these images (e.g. maybe it's an image they
> want to download for a slide). In that case, they might change their
> settings to include such images.

All the images in a Google or Bing search for images have empty alt ... 
Despite being links.

> Content outlives tools (including authoring tools and user agents).
> Tools of the future may be better at repairing text alternatives. We
> don't want to prevent them doing so by presenting a poor repair job
> (e.g. boilerplate alt) as if it were a carefully thought-out,
> human-provided text alternative.

Tools already repair for boileplate @alt. E.g. a white-space filled 
@alt is often repaired.

> If we do not know how far these claims are true, then that is an
> argument against discouraging behavior based on these ideas.

Now I feel you behave like Richard: you only focus on AT (though you 
subclass yourself to future AT ...). I think you give too much room for 
your doubt. You make it too big a task. And too hypothetical, from the 
author's point of view. It is my web site. I want to make it good. Now. 
I will send a message - that is mine - to all users!

>>> 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.
> 
> Authoring tools are represented among the HTML5 conformance classes,
> so I'm not sure why you think that?

So can you point to where in HTML5 it is described that a tool should 
omit the @alt if the author refuses to insert it?

>> Also, the chairs in their Decision discussed whether ATAG would take
>> this new information into account.
> 
> I don't think that's means we can exclude tools that do not comply
> to ATAG2 from our analysis - especially as our evidence for a rising tide
> of ATAG2 compliance is weak.
>
> I don't think we can even exclude tools that do not comply with HTML5
> from our analysis, since they may still be affected by how the validator
> treats their output, and their strategies still impact the accessibility
> of the web.

We should consider anything that is relevant. Just make your analysis 
and share it with us. But it seems to me that once you are doing such a 
thing, then you are in reality describing levels of support. Much the 
same way that WCAG (and thus ATAG) describes levels of support.
 
>>> 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?
> 
> I'm not sure what's best.
> 
> This makes me nervous about premising conformance requirements on
> solving this problem by persuading authoring tools to adopt some
> particular UI or other.

AN opt-in feature would that the author or the tool, under certain 
situations, could turn it on. That's perhaps not really how it was 
intended?
-- 
leif h silli

Received on Tuesday, 3 May 2011 03:19:12 UTC