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

Henri,

Henri Sivonen wrote:
> On Aug 17, 2009, at 16:56, Jan Richards wrote:
> 
>> Henri Sivonen wrote:
>> ...
>>>> The Consensus Documents goes in that direction when it states that 
>>>> it doesn't mater if an <IMG> with role="presentation" has an empty 
>>>> alt="" or no alt at all. But it goes slightly in the opposite 
>>>> direction when it recommends that validators should say that an 
>>>> <IMG> with an empty alt="" but not @role should automatically get a 
>>>> role="presentation".
>>> My biggest concern with the proposed normative warning is that 
>>> role=presentation wouldn't be the path of least resistance for 
>>> dismissing the warning. Putting a space in the value of alt would be.
>>
>> Actually, if an author is going to be non-cooperative, then I would 
>> prefer they put in alt=" " rather than misuse semantic markup (alt="" 
>> and role="presentation") which indicate a cooperative author has 
>> judged the image to be presentational. (NOTE: Even more preferable to 
>> me would be to find a way for @alt to be left out in such a situation 
>> as an indicator that problem exists)
> 
> I would also prefer @alt to be omitted in this case. I meant that alt=" 
> " would be the easiest way to dismiss the validator warning under the 
> rules proposed in the WAI CG resolution.

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.

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

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.


>>> The reason I disagree with it is that I haven't seen a credible 
>>> expectation of how a Dreamweaver-like product should implement the 
>>> requirements of HTML5 as drafted without failing to conform to ATAG 2 
>>> as drafted (or vice versa).
>>> Anyway, I think discussing what should be conforming before coming to 
>>> consensus on desirable authoring tool behavior will rathole this 
>>> thread. Therefore, instead of discussing my conclusions, I'd like to 
>>> state my premises and invite anyone who disagrees with any of my 
>>> premises to come forward. If it turns out that one of my premises is 
>>> wrong, my conclusion is most likely wrong.
>>> Here are my premises:
>>> * "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.
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.


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


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

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 Monday, 17 August 2009 16:47:21 UTC