W3C home > Mailing lists > Public > public-html@w3.org > August 2009

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Sun, 16 Aug 2009 16:25:06 -0700
Cc: Sam Ruby <rubys@intertwingly.net>, Steven Faulkner <faulkner.steve@gmail.com>, Ian Hickson <ian@hixie.ch>, HTMLWG WG <public-html@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>
Message-id: <43168262-3AA3-40B6-B72D-5A8A0A31AF5C@apple.com>
To: Henri Sivonen <hsivonen@iki.fi>

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.

Received on Sunday, 16 August 2009 23:25:57 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:49 UTC