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

On Aug 18, 2009, at 16:51, Jan Richards wrote:

> 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).
[...]
>> 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.

OK. I now see how the "missing" mechanism (assuming that the "missing"  
mechanism would make a validator turn off alt-related messages it  
would otherwise be required to emit) addresses my concern about  
conflict between HTML 5 validation and ATAG 2 at least in theory  
(provided, of course, that ATAG 2 allowed tools to generate the  
"missing" marker when ATAG 2 B.2.4.3 applies). My apologies for  
dismissing the "missing" mechanism so quickly earlier in this thread.

What kind of dynamic the "missing" mechanism would create in practice  
is harder to predict. That is, it's harder to tell if it would have  
the desired effect on hand-author and tool developer behavior.

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

This seems more problematic than a pure validator pragma. Why would a  
generator generate an alt string and a signal for UAs to completely  
ignore it? More importantly, having an "user agents should ignore alt  
completely" marker would pose a backward and forward compatibility  
problem: If the markup generator wants UAs to ignore the alt  
completely, generating some alt and an "ignore" marker would make old  
UAs not ignore the alt. If early adopters use the "ignore" marker  
while testing in current UAs, future UAs would lose potentially useful  
text alternatives.

>>>>>> * "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="")

If the user of the tool inserts an image (outside <figure>, etc.  
special constructs) and doesn't provide a text alternative or rejects  
(which must be an option under ATAG 2 B.2.4.2.a) a tool-suggested text  
alternative but doesn't flag the image as omissible from AT  
presentation, as far as I can tell, generating role=presentation would  
be wrong by analogy with ATAG 2 B.2.4.4 and generating any alt would  
be wrong per ATAG 2 B.2.4.3 when the tool has no relevant sources that  
the UA wouldn't have.

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

Received on Wednesday, 19 August 2009 06:59:56 UTC