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

On Aug 16, 2009, at 4:25 PM, Maciej Stachowiak wrote:

>
> On Aug 16, 2009, at 9:03 AM, Henri Sivonen wrote:
>
>> On Aug 16, 2009, at 17:51, Sam Ruby wrote:
>>
>>> It also presumes that invalidating one spec by another is not best  
>>> practice, something that the current HTML5 draft does in a number  
>>> of occasions.
>>
>> HTML 5 overrides past specs, or specs whose maintainers are  
>> uncooperative. ATAG 2 and HTML 5 are both specs in development, and  
>> I think cooperation would be good here.
>>
>>> And the suggestions above (and by that, I mean the whole list:  
>>> items 1 through 5) would seem like a more credible proposal if you  
>>> could point to a consolidated place where the current differences  
>>> between the CG Consensus Resolution and the HTML Working Draft  
>>> have followed the above procedure.
>> [...]
>>> Between the three of you, nobody has provided any feedback on the  
>>> resolution itself.  Collectively, you are suggesting a burden of  
>>> proof that you are not ready, willing, and able to meet  
>>> yourselves[7][8].
>>
>> The reason why I formulated my reply the way I did was to carefully  
>> avoid stepping on the toes of ATAG 2 at step #2. (I'd really like  
>> to learn more about what the consensus on this point is in the  
>> group defining ATAG. I have tried to elicit information on this  
>> publicly and privately over a long period of time but I have  
>> failed. Based on seemingly conflicting statements on the topic by  
>> past and present editors of ATAG 2 (sorry, no reference), I suspect  
>> the reason why I have failed to elicit this information is that  
>> there isn't a clear consensus, yet.)
>>
>> However, I can fill in step #2 as an accessibility non-expert based  
>> on hearsay about step #1, and then evaluate step #3 given my own  
>> filling in of steps #1 and #2:
>>
>> My understanding about step #1 is that UAs most often behave like  
>> this:
>> * The content of non-empty alt attribute is read to the user in  
>> place if the image.
>> * Empty alt (or role=presentation in new clients) cause the  
>> rendering to be as if the image didn't exist.
>> * Absent alt causes the presence of the image to be announced to  
>> the user.
>>
>> The case for the tool user providing a text alternative is, I  
>> believe, completely uncontroversial: The tool should provide a UI  
>> for inputting the text alternative, and the text should end up as  
>> the value of the alt attribute.
>>
>> Based on what I gather from comments praising Dreamweaver and from  
>> my own reasoning, I think the advice at step #2 should be that an  
>> authoring application in the situation where its user doesn't  
>> supply a text alternative must not generate a text alternative  
>> (especially not from the file name) and must not generate markup  
>> that masks the existence of the image (empty alt or  
>> role=presentation). Therefore, an image tag without an alt  
>> attribute or a role attribute should be generated when the user of  
>> the authoring application hasn't affirmatively provided a text  
>> alternative or an assertion of presentationality.
>>
>> As a matter of language design, I think the absence of the alt  
>> attribute is a sufficient syntactic signal of its absence. I think  
>> adding more syntax for affirming its absence (e.g. noalt, missing,  
>> etc.) is unhelpful.
>>
>> As for providing a marker for flagging alt autogenerated, the  
>> premise of such a marker would be that the software operated by the  
>> Web user could upon consuming such a marker ignore the alt and try  
>> to generate a better one itself. The problem is that the software  
>> operated by the Web user can't know if its own heuristic  
>> outperforms the heuristic used by the authoring app. How would the  
>> client software know when to second guess the authoring software?  
>> Due to this problem, I don't support emitting autogenerated text  
>> alternatives but then flagging them as such.
>
> If you're saying that authoring tools should produce missing (not  
> empty) alt, without any of the alternatives suggested by HTML5 such  
> as @title or <legend>, and that this should be conforming, then I  
> believe you disagree with the current state of the HTML5 spec.

(To be specific, I think the best option in this case that would be  
conforming to the current draft would be to put a title attribute on  
the image, giving the best information the authoring tool has  
available, even if it is a low-value description like "Photo 1 of 15".)

Regards,
Maciej