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

Hi Henri,

Henri Sivonen wrote:
> 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?

No - because, as discussed previously, the consensus resolution allows 
for a "missing" mechanism that could break the impasse while maintaining 
the benefits of requiring @alt for validity (e.g. author awareness).

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

Because allowing @alt to be absent with no validation warning is a loss 
of something in HTML4 which has led to increased author awareness of 
@alt and accessibility in general.

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

Since the semantic meaning would be "don't trust the @alt string" I 
would think the behaviour would be the same as it is now when @alt is 
fully missing.

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

I'm not sure I understand the problem here...

What's the "either-or" choice? What do you see an ATAG 2.0 conforming 
tool doing that would always cause unclean reports?.
(The CD allows for "clean" reports as long as @alt (or similar) is 
always used for IMG and role="presentation" is used for images with alt="")

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

FYI: From a meeting yesterday, I have an action to propose additional 
support text that includes the following clarifications:
- Because of rapidly advancing technology in the area of image 
processing ATAG2 is not limiting that input to alternative text
- But if the format has a way to label text as "autogenerated" that 
mechanism should be employed to label input from image processing
- Because post-authoring session automatic repairs are stop-gap 
measures, it is preferable that in the next authoring session, the 
repair be flagged for author attention.



Jan Richards, M.Sc.
User Interface Design Lead
Adaptive Technology Resource Centre (ATRC)
Faculty of Information
University of Toronto

   Phone: 416-946-7060
   Fax:   416-971-2896

Received on Tuesday, 18 August 2009 13:52:08 UTC