- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sun, 16 Aug 2009 16:25:06 -0700
- To: Henri Sivonen <hsivonen@iki.fi>
- 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>
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. Regards, Maciej
Received on Sunday, 16 August 2009 23:25:56 UTC