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

Hi Henri,

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

I'm glad that I've finally put together a coherent explanation of the 
"missing" mechanism idea. In practice, I doubt it would be hand-coded 
very often...instead it's more likely to be used by authoring tools. 
Here's an example of how I think it might be used:
1. the author drag-and-drops an image into an authoring tool (bypassing 
the usual insert dialog)
2. the authoring tool has implemented a "live" accessiblity checker (not 
required by ATAG but a nice feature), so the image is immediately given 
a blue squiggly underline (similar to red underlining of spelling 
errors) to indicate no @alt value has been set.
3. BUT the author ignores the underlining, saves and close the document.
4. BUT the authoring tool has an accessibility option set to use the 
"missing" mechanism to validate, so when the author has failed to 
address the accessibility issue and the content is being closed, the 
tool adds @alt=" " and the "missing" mechanism.
(Ordinarily adding " " to the @alt would be considered a repair of the 
alternative text, but the missing mechanism tells user agents to ignore 
it...so ATAG2 B.2.4.3 is met)

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

I can see the backwards compatibility problem, but not the forwards 
compatibility problem. Why would testers add the "ignore" marker while 
testing in current UAs?


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

If the author rejects the suggested @alt value, ignores the 
prompts/checks for their own @alt, and turns off the "missing" mechanism 
then....yes, invalidity will result, but at some point, isn't that the 
author's choice?

Cheers,
Jan

Received on Wednesday, 19 August 2009 20:43:44 UTC