Re: feedback requested on WAI CG Consensus Resolutions on Text alternatives in HTML 5 document

On Aug 17, 2009, at 19:46, Jan Richards wrote:

> The CD (WAI CG Consensus Doc) resolution doesn't say @alt (or other  
> one of several listed alternatives) can't be omitted. It says the  
> IMG element is invalid if @alt isn't there. It is HTML5's  
> requirement of validity for conformance that makes this a problem.

Doesn't that mean that the consensus resolution requests keeping it a  
problem?

> In an attempt to find a way out of this problem, the CD includes the  
> following text:
> "In order to address both the validity and human generation  
> concerns, we do not oppose the creation of 'autogenerated' and  
> 'missing' attributes where either one of these could be used to make  
> an image that does not have any human-generated text alternatives  
> valid. (Note: It is important that this marker is not included in  
> the alternative text string itself.)"

Why is this affirmation necessary compared to @alt being absent?

> When used, a "missing" signal (however this might be encoded - as  
> long as it is not in the @alt string) would communicate to the user  
> agent that the @alt value should not be trusted.

What concretely is this envisioned to mean for user agent behavior?

>>>> * "Authoring tools and markup generators must generate conforming  
>>>> documents." ("Authoring tools are exempt from the strict  
>>>> requirements of     using elements only for their specified  
>>>> purpose, but only to the extent that authoring tools are not yet  
>>>> able to determine author intent." "In terms of conformance  
>>>> checking, an editor is therefore required to output documents  
>>>> that conform to the same extent that a conformance checker will  
>>>> verify.") (Quoted from HTML 5.)
>>>
>>> There's a problem here. Authoring tools often can't determine  
>>> author intent in @alt usage, so the exemption from the first  
>>> sentence would seem to apply. On the other hand, the second  
>>> sentence seems to say @alt is required for conformance to the  
>>> extent that it can automatically checked for (i.e., whether it  
>>> exists or not, rather than whether it has correctly recorded  
>>> author intent).
>> Do you mean validators shouldn't flag the absence of @alt as an  
>> error, because the question whether alt should be present or not  
>> falls outside the realm of machine-checkable conformance criteria?
>> I support making this interpretation explicit in HTML 5 and ATAG 2.
>> At present, the language about @alt in the HTML 5 draft doesn't  
>> seem to provide for this interpretation, since the spec require at  
>> least one of several syntaxes to be present in every one of the  
>> exhaustively enumerated cases of possible author intent. The WAI CG  
>> consensus resolution didn't support this interpretation, either, as  
>> far as I can tell.
>
> Perhaps lack of @alt could still triggers some type of validity  
> warning, but the HTML5 conformance guidance to authoring tools  
> (which already talks about determining author intent) could state  
> that authoring tool output can still conform with these warnings if  
> the authoring tool was unable to determine author intent vis a vis  
> the value to use for alternative equivalents - if and only if the  
> authoring tool provided the author with the ability to demonstrate  
> their intent (e.g., by filling out the proper fields).
> 3. it would then be left to ATAG 2.0 (still draft) to set  
> requirements for how authoring tools can do a good job at collecting  
> these alternative equivalents.

The crux of my feedback on the CD is this:

If the WAI requests that HTML 5 validators *by default* emit messages  
flagging pieces of markup in the output of an authoring tool when the  
authoring tool conforms to ATAG 2, authoring tool vendors will be  
faces with an either-or choice: conforming to ATAG 2 or getting a  
seemingly "clean" report from validators. Whenever authoring tool  
developers opt for the seemingly "clean" report, the WAI will have  
failed to fully meet the objectives that motivate ATAG 2 (in the scope  
of that authoring tool). Thus, the WAI will have better chances of  
getting ATAG 2 implemented widely and meeting the objectives that  
motivate ATAG 2 if authoring tool developers can both conform to ATAG  
2 and get a seemingly clean validation report by default.

As a validator developer, I would prefer not to undermine ATAG 2 by  
putting in default messages that will lead to authoring tool  
developers having to make that choice, since some developers will opt  
for the seemingly "clean" report over ATAG 2 compliance. (Validator.nu  
already has an optional Image Report feature that goes above and  
beyond what is requested in the CD.)

> 4. and it would be left to WCAG 2.0 (W3C Recommendation) to  
> determine the accessibility level of a particular final piece of  
> content, regardless of the tool used and the author's circumstances.

OK.

>>>> * Autogenerated alt="image", alt="" and alt=" " violate the ATAG  
>>>> 2 language quoted in the previous point.
>>>
>>> Actually, alt="" would be fine to autogenerate if the authoring  
>>> tool could detect that the image was presentational (e.g., it was  
>>> a 1x1 white JPG with no link)
>> I agree. I meant in the general case. (However, one might argue  
>> that the 1x1 case isn't important, since the client side could  
>> filter it just as easily.)
>
> Right, but that's perhaps the simplest case. That's why ATAG 2.0 B. 
> 2.4.3 (Let user agents repair) only applies to repairs using text  
> content that the user agent (and by extension the end user) as equal  
> access to. Repairs using image processing are always allowed.

It's not obvious to a reader who hasn't been involved in ATAG 2  
drafting that repairs using image processing are always meant to be  
allowed. I suggest noting this explicitly.

>>>> * Most authors don't respond to prompts in a meaningful way.  
>>>> (Contrast with ATAG 2 B.1.3 applicability notes.)
>>>
>>> I won't disagree with the statement. But the "contrast" is  
>>> incorrect. The ATAG 2.0 use of the word "assume" should be read as  
>>> "ONLY WHEN"
>>> "This guideline applies to the automated behavior specified by the  
>>> authoring tool developer [under the assumption that authors will/ 
>>> ONLY WHEN AUTHORS] respond properly to any prompts."
>>> (http://www.w3.org/TR/2009/WD-ATAG20-20090521/)
>> OK. I misunderstood what ATAG 2 meant. I suggest rewording the  
>> sentence using words "only when".
>
> Agreed. I will propose that change in ATAG 2.0.

Thanks!

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Tuesday, 18 August 2009 06:22:20 UTC