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

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.

...

Cheers,
Jan

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

   Email: jan.richards@utoronto.ca
   Web:   http://jan.atrc.utoronto.ca
   Phone: 416-946-7060
   Fax:   416-971-2896

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