- From: Justin James <j_james@mindspring.com>
- Date: Mon, 5 May 2008 10:09:56 -0400
- To: <public-html@w3.org>
Folks - I think we need to take a step back, look at the use cases for alt, and see where we need to go from here. Right now, we're generating a lot of email on the subject, but it does not seem like we're handling it like we need to be. So far, after reading the zillions of messages on this subject, here are the use cases I have identified. Please add others, since I have only skimmed many of the emails and may have missed something: 1) alt is used to have words describe the image at a technical level; for example: alt="image.jpg 200x320" 2) alt is used to have words describe the image at a descriptive level; for example: alt="Picture of Bob and Jim at the big game" 3) alt is used to describe the consequences of some sort of user interaction with the image (a tooltip): alt="Click the image to see it full size" 4) alt is used to provide a full transcript or summary of the text contained within an image; for example, if the image is a full, scanned in page from a document, the alt text would contain an executive summary, or the full text 5) alt is omitted or left blank under a wide variety of circumstances; sometimes for good reasons (such as a purely decorative image being used as a fancy box border, in which case alt text would not only be senseless, but provide a distraction in the UI to the user) and sometimes for not good reasons (the image is supported by one of the previous use cases, but the user did not provide alt text for whatever reason) We can divide our authors into a few major groups: a) Users who do not realize or care that they are generating HTML, such as people writing email in an HTML capable email client b) Users who are aware that they are authoring HTML, but with little technical know-how, like a blog author; these users will use many features of their authoring tools, but are still 100% dependent upon those tools c) Users who are writing HTML by hand, or sometimes using the "show source" feature of their HTML software, but who have not read and/or memorized every last detail of the spec (or maybe they learned HTML at version 3, and only change what they know when it no longer works), and for whom conformance is of little concern d) Users who are writing HTML by hand, or sometimes using the "show source" feature of their HTML software, and who *have* read the spec and remember it well and refer to it when they are not sure about something; these users read new HTML specs when they come out, and update their usage as appropriate; conformance is a high priority for these users e) Automated software that may or may not have a way to determine (and may or may not have a good reason to not provide) appropriate alt text that meets one of our use cases except perhaps CASE #5 (which can be considered the "else" use case) Finally, we can ask ourselves the following questions: i) Is mandating accessibility a goal of the HTML 5 spec? ii) Is it the HTML 5 spec's responsibility to ensure that as many people as possible can consume an HTML document? iii) Is it the HTML 5 spec's duty to force authors to only use images for certain purposes? iv) Would authors and tools be better served by having an alternative to <img>, but used specifically in the event of CASE #5? Maybe, something like, <decoration>? Comments: * Considering how much in-accessible functionality is already in HTML 5 (particularly with regards to support for AJAX-type work), it is clear that this is *not* a goal. From the way the spec supports AJAX and multimedia, it is clear the accessibility is a "nice idea" but certainly secondary to functionality. * If this was purely about accessibility, we would be intent on insisting that authors provide translations of their content in, say, the top 5 major languages; that would force their content to reach a lot more people that trying to make it play nicely with a screen reader. * If we are going to mandate al text due to CASE #4, we should make the <audio> and <video> tags (and anything that does the same in <object>) have a mandatory @transcript system. * It is impossible for any kind of software to validate CASE #1, CASE #2, and CASE #3. Software that supports OCR could validate that the document conforms for CASE #4. * The proposals that I have seen that state that user agents, validation tools, or authoring tools need to have some sort of built-in OCR system to validate CASE #4... that is a major burden to put on tool authors. * It is fairly clear to me that the use cases are too disparate to allow a single attribute to handle them all, unless the attribute definition provides zero usage guidance (let alone requirement on how to use) or implementation details to authors and tool creators. * I believe that having separate attributes and/or tags to handle each use case will be a mess; as it is, @alt is frequently omitted when it should not be. J.Ja
Received on Monday, 5 May 2008 14:10:53 UTC