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

On Mon, May 2, 2011 at 6:56 PM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> There is one problem in the line of thought, here, though: If the
> author consciously says nay to @alt, then I believe a conforming
> authoring tool will also explain that it is invalid to not provide
> @alt. I don't understand why authors would believe the tool is buggy
> when they themselves said no to adding @alt.

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

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

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

>> e.g. alt="Link" for link images, alt="Button" for button images, alt=""
>> for other images.
>
> Author inserted or tool inserted?

It's boilerplate whether designed by an authoring tool developer or an
author.

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

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

>> 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, and on the other that tools robotically
inserting alt="" is fine because user agents will interpret it
differently to role="presentation"!

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.

If we cannot agree on the treatment of alt="", then we should be open
about that disagreement to avoid sounding incoherent 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="".

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

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

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.

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

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

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

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

--
Benjamin Hawkes-Lewis

Received on Monday, 2 May 2011 22:21:34 UTC