Warning:
This wiki has been archived and is now read-only.

IssueAltAttribute

From HTML WG Wiki
Jump to: navigation, search

Short Text Alternatives on <img>

Issue

The img element section allows instances where the <img> element may have no text alternative: not just a null alt attribute for eye candy, but no text alternative for content. HTML5 lacks a way for automatic validators to programmatically detect the presence or absence of short text alternatives on the img element. The issue involves ensuring images have accessible alternatives. It asks the question "What should be done when a text equivalent is unknown/unavailable?

The current guidance for conformance checkers for Section 4.8.2.1 the img element does not implement the WAI Coordination Group's (WAI CG) advice on the validation of short text alternatives.

HTML5 currently says: "A conformance checker must report the lack of an alt attribute as an error unless either the conditions listed above for images whose contents are not known apply, or the conformance checker has been configured to assume that the document is an e-mail or document intended for a specific person who is known to be able to view images, or the document has a meta element with a name attribute whose value is an ASCII case-insensitive match for the string 'generator'."

Requiring a set of machine testable, programmatically valid options helps ensure that images have complete structure. If no accessible option can be determined, then the resulting structure should be considered invalid. Text alternatives are essential for accessibility. Enabling automatic validators to programmatically detect the presence or absence of text alternatives raises public awareness of Web accessibility in general and aids in accessibility education in particular.

Status

Open Issue:

Contents

Use Cases

Text alternative use cases include:

  • Users who are blind or have a visual impairment and use a screen reader that reads aloud the information from the web page (text to speech software).
  • Users who are blind and use a dynamic braille display to get information from the web page.
  • Users who have a cognitive impairment that makes it difficult or impossible to read, and use a screen reader.
  • Users who have a slow connection and turn off images to speed download.
  • Users have expensive data roaming connections (that are not slow).
  • Users who turn off images to decrease bandwidth use in order to lower their Internet usage fees.
  • Users with a text-only browser.
  • Users listening to the page being read out by a voice browser or other voice output, for example, as they drive or otherwise cannot read the web page.

There are many benefits for web site developers and owners to include text alternatives for images as well; for example, it improves search engine optimization (SEO) because the text alternatives are available to search engines, whereas images themselves basically are not.

Authoring Tools

The following authoring tools support the alt attribute.

Image Galleries

Mail clients

  • Mail.app and other email clients.

Authoring Tool Accessibility Guidelines

Research

Advice From Accessibility Authorities

WAI and the PFWG

Conclusion:

"barring the introduction of new, good reasons for a change, the failure of the HTML5 draft to make @alt on <img> an across-the-board requirement (even if sometimes it has the value of "") is a bug."

Finding:

"The language "In such cases, the alt attribute may be omitted," gives the appearance of creating a policy line that is inconsistent with WCAG, whether 1.0 or 2.0. As such, this needs to be changed. HTML WG should re-work the <img> element section to bring it into line as techniques for implementing WCAG 2.0. We say 2.0 because of the strong likelihood that WCAG 2.0 will precede HTML5 to Recommendation status."

"WCAG WG is chartered to set Accessibility guidelines and HTML WG is not; so HTML5 should be careful to create features that support WCAG and describe their use in ways that conform to WCAG."

Source: Re: Request for PFWG WAI review of Omitting alt Attribute for Critical Content - Al Gilman

WAI CG and the PFWG

WAI CG Consensus Resolutions on Text alternatives in HTML 5

WCAG 2.0 WG Comment

Relevant Cited Blog, Wiki Posts and Papers

Relevant IRC Logs

Tutorials

  • about.com "Always Use the <img /> alt Attribute"
  • bejoy.in "Attributes 'src' for the source URI and 'alt' for alternate text are mandatory."
  • chami.com "Inside your <img> tag we used the two required attributes; src and alt."
  • Cynthia Says "The rule states all IMG elements are required to contain either the 'alt' or the 'longdesc' attribute."
  • Elementary Standards "This (alt) has been required since HTML 4.01 Specification"
  • evotech
  • GAWDS "One of the first things anyone learns about accessible web design is the importance of the alt attribute on images. If you are using XHTML, image tags without alt attributes won't even validate, so ensuring this information is provided becomes even more important."
  • Homemade Parachute "Element “<img>” requires that the attribute “alt” be specified."
  • HTML Fix It "The attribute mentioned is compulsory and you should add it to the relevant tags on your page."
  • IBM "Use the ALT attribute in IMG tags"
  • Jim Thatcher "The single most important thing you can do to do to make a web page accessible is to include alternative text for images."
  • Jukka 'Yucca' Korpela "Check all images (<img> elements) on the page, and consider whether they have an alternate text (alt attribute) specified and whether that text is adequate."
  • maxdesign "Provide a text equivalent for every non-text element"
  • Net Mechanic "ALT is a required element for images"
  • onlinetools "You have to set an ALT attribute in each image"
  • SEO Workers "Always add alt attributes to images. Alt is mandatory for accessibility and for valid XHTML."
  • Skills for Access
  • stuffandnonsense
  • Sitepoint "Don't simply omit the alt attribute-it's required, and absence of an alt attribute can cause problems for screen readers, which, in an effort to provide information about the image, may read out the image’s filename, for example."
  • Accessibility: Websites: Project: Part 2 - Think Vitamin Video. At 02:33 "Remember the alt tags are required in HTML and it is what screen readers see instead of seeing the image."
  • Your HTML Source "The alt attribute is also required, so you must write one for every image you use."
  • WebAIM "Adding alternative text for images is the first principle of web accessibility."
  • WebProNews "All non-text elements must have labels (i.e. add the alt attribute); the alt attribute is a requirement for both HTML 4 and XHTML W3C standards based documents."

Laws, Policies and Standards

Web Content Accessibility Guidelines

  • WCAG 2 Guideline 1.1 - "Provide text alternatives for any non-text content so that it can be changed into other forms people need such as large print, braille, speech, symbols or simpler language".
  • Techniques for WCAG 2.0 F65 - "Failure of SC 1.1.1 due to omitting the alt attribute on img elements, area elements, and input elements of type 'image'.
  • WCAG 1

Laws

Policy and Standards

  1. Arizona State University
  2. Athens Clark County
  3. Biz/ed.co.uk
  4. California State University
  5. California Department of Rehabilitation
  6. Caldwell Community College and Technical Institute
  7. City and County of Denver
  8. City and County of San Francisco
  9. City of Encinitas
  10. City of Shreveport
  11. Colorado State University
  12. Commonwealth of Massachusetts
  13. Connecting for Health UK
  14. Contra Costa County
  15. County of San Diego
  16. CPG Capital Partners (China)
  17. Crown Prosecution Service (UK)
  18. Dive Into Accessibility
  19. Durham University
  20. Education, Audiovisual and Culture Executive Agency (EU)
  21. elearning.unitbv (Romania)
  22. Fedstats
  23. Free Open Source University of Macedonia (Greece)
  24. Guide Dogs (Tasmania)
  25. Governo Italiano Directive
  26. University of LODZ Institute of Computer Science (Poland)
  27. Honolulu Department of Transportation Services
  28. Howard University
  29. Humboldt State University
  30. IBM
  31. Illinois State University
  32. informatizacia (Slokakia)
  33. Japanese Ministry of the Environment (PDF)
  34. Law Office of Lainey Feingold
  35. Louisiana State University
  36. LCC International University (Lithuania)
  37. Massachusetts Institute of Technology
  38. Manitoba Internet Policy/Website Development Standards
  39. National Center for Accessible Media
  40. Monroe County
  41. Moodle
  42. Nevada Department of Transportation
  43. New York State Forum
  44. nuclearmalaysia.gov
  45. Ohio State University
  46. Open eBook Publication Specification
  47. Patient Opinion (UK)
  48. Princeton
  49. Purdue
  50. Roger James, Clements & Partners Solicitors
  51. Ryerson University
  52. PubbliAccesso.gov.it
  53. Save the Children
  54. Sacramento Sheriff's Department
  55. Sietook (Slokakia)
  56. Silicon Valley Power
  57. Spain and Portugal for Visitors
  58. State of Colorado
  59. State of Connecticut
  60. State of Hawaii
  61. State of Indiana
  62. State of Maine
  63. State of New Jersey
  64. State of Oklahoma
  65. State of Oregon
  66. State of Rhode Island
  67. State of Vermont
  68. Sul Ross State University
  69. Sumitomo Mittsui Banking Corporation
  70. symbio.cz
  71. Tarleton State University
  72. Texas & M
  73. The Laws Reviews (UK)
  74. Trinity College Dublin
  75. United Nations
  76. United Nations Volunteers
  77. United States Department of Commerce
  78. United States Department of Health and Human Services
  79. United States Environmental Protection Agency
  80. United States Geological Survey
  81. United States Internal Revenue Service
  82. United States Postal Service
  83. United States Environmental Protection Agency
  84. University of Arkansas
  85. University of Bristol
  86. University of Cambridge
  87. University of Florida
  88. University of Georgia
  89. University of Iowa
  90. University of Illinois at Chicago Center for the Advancement of Distance Education
  91. University of Minnesota
  92. University of North Texas
  93. University of South Florida
  94. University of Texas at Tyler
  95. University of Wisconsin
  96. University of Wisconsin-La Crosse
  97. University of Wisconsin Superior
  98. University of Wisconsin-Milwaukee
  99. Victoria College
  100. University of Western Ontario
  101. Welt-Historie
  102. Wright State University
  103. xstrata

Rationale: Requiring a set of programmatically valid options/Why text alternatives should not be optional

  1. Structural Integrity of the Language - From an architectural point of view, the structure of an image isn't complete without a text alternative, so it should be a required for this reason alone. src is to sighted users as text alternatives is to some users with disabilities. Omit the src attribute and sighted users have no content. Omit text alternatives and some users with disabilities have no content. Without both a src and a text alternative the <img> element is incomplete.
  2. Accessibility Awareness - Enabling automatic validators to programmatically detect the presence or absence of text alternatives (like HTML4 did with alt) raises public awareness of Web accessibility in general. It is an undeniable advertisement that text alternatives are needed and a chance to educate the author about proper usage. It has been said that the W3C HTML4 validator has done worlds more than the HTML4 specification for increasing the quality of HTML documents on the web.
  3. Education - Requiring a set of programmatically valid options aids in accessibility education. When the validator flags missing text alternatives it creates a teachable moment. A moment of great opportunity: a time to flag errors, educate, to make people aware, and to get action, to get people to actually fix their pages. The W3C validator is currently used as a web accessibility teaching tool. Students are instructed to use the W3C validator in classes in order to flag missing text alternatives. It is the very first step in getting that important *message* across. One of their first lessons is to validate HTML on the W3C site to be sure that it is error-free and that they have indeed examined each image. It makes a BIG impression that text alternatives are mandatory not just for WCAG but as well for valid HTML.
  4. The Right Thing - Enabling automatic validators to programmatically detect the presence or absence of text alternatives encourages authors to do the right thing. As Ian Hickson has said, "we _should_ be calling authors out on this kind of mistake. Just because people do something doesn't mean we should make it valid - after all, we made <font> invalid, along with many other things. Conformance is about trying to advise authors to do the right thing."
  5. Addressing Business AND Accessibility Needs - It is possible to require a set of programmatically valid options which maintains the integrity of the markup and aids accessibility while addressing business needs. A "generated" and "missing" attribute could address the business concern of authoring tools wanting to conform to HTML5 even if the author does not supply a text alternative. The outcome would be practical methods of detection, repair, and handling. WAI CG said that they would not oppose creating a "generated" or a "missing" attribute.
  6. It creates a scenario where authors can (and most likely will) start finding "justifications" based on their opinions, to not supply text alternatives rather than facts and needs. It suggests that it's OK to "sometimes" not provide text alternative. That "sometimes" will become open to interpretation, misuse and abuse (despite best intentions). It condones and permits the ability to create inaccessible content. All anyone will hear, if text alternative is optional, is that it is optional. They will not read anything else about it. Case closed, the end. Optional will equal don't need it. Optional will be the operative word. The law of conservation of Web production energy will demand an end to the entire practice of adding text alternatives. After all it is optional, not needed, out of sight out of mind, so 2007. Practically deprecated. Optional = not needed.
  7. Omitting the alt attribute leads screen readers announcing the value of the img element's src attribute when an image is in a link. In many cases the filename contained in the src attribute is pure nonsense that does not provide the user with any useful information about the image. Recent research suggests that encouraging omission will reduce the accessibility of images even under conditions where the quality of the alt text is poor.
  8. It promotes poor authoring tools. Flickr, Photobucket, and Wikipedia are examples of incorrect software implementation. Every author should be forced to make a decision about an text alternatives for every image, whether to write a real alt or to go with null text. In contrast, XStandard is a correct implementation. It prompts the user to identify if an image is decorative or not. The user makes the decision. If they say the image is not decorative, and in fact actual content, they must submit alt text before the image can be saved.
  9. The Private communication email exceptions in the spec are beyond the scope of both HTML5 and WCAG 2.0 and should be addressed at a policy level rather than the specification level. This rule digresses too far into business-process issues. This email exceptions rule makes assumptions about the lifetime of messages and takes a static approach to disability. Emails get forwarded and the degree of disability may vary over time. The intended recipient isn't always the actual recipient. The intended recipient may well be able to view images, but rendering them on a device unable to render images or have images switched off to save on downloads.
  10. The title attribute is not an acceptable text alternative as it's content is not displayed to the user unless they can use a mouse and beforehand know the content is there. The content of the image title attribute is also often not detected by AT by default unless the user makes an explicit choice in their preferences to announce the attribute contents. Authors are advised to only use the title attribute for "additional information" and not as a full equivalent alternative. Removing title would make the HTML specification in line with WCAG, and previous authoring practices.
  11. It is unreasonable to state that the output from authoring tools should always be considered valid, regardless of input from the user. Considering output to be correct regardless of input is at odds with the general garbage in garbage out (GIGO) principle. For example, an author can provide an address with the address element that isn't a contact address, which would not be considered compliant in HTML. The author obviously has a responsibility in using an authoring tool.
  12. An incomplete does not equal a passing grade. Optional should not be valid.
  13. Condoning the omission of text alternatives for "some" critical content is a slippery slope. At what level does it stop? If a person has 100 or 50 or 10 photos that they want to share, is it okay then to not include the text alternative? Then if its okay for ten why not one?
  14. Requiring the text alternatives is an undeniable advertisement that it is needed, and a chance to educate the author about proper usage. When a well meaning author validates their pages, they will come across the error, and be notified. The abuse of text alternative that is noted here (repeating text, useless information) is because when authors first discovered that they must use text alternatives, they were given poor instructions. With the improved specification of the usage of text alternatives, it makes all the more sense to keep it as a required. If text alternative is not required, all the existing content with abuse will remain. With it required, there is a better chance that authors will find out how to use it better.
  15. A valid page isn't necessarily an accessible page, but an accessible page's foundation is validity. This is the crux of the education argument. When the validator flags a missing text alternative it creates a teachable moment. A moment of great opportunity: a time to flag errors, educate, to make people aware, and to get action, to get people to actually fix their pages. Henri's image report feature on Validator.nu is a great step in the right direction. A W3C validator could do the same but with the teeth to flag missing text alternatives as an error or warning...and then explain or point people to what they need to do and why.
  16. Boiling the issue down to an image having or not having an text alternative doesn't cater for the third scenario: an image that is indeed a critical part of the content, but for which the author - through negligence, ignorance, or non ATAG-compliant authoring environments - has not provided an alternative. Being able to distinguish between images that are simply iconic/representative of surrounding text and those that have not been authored correctly is essential for signaling to assistive technology whether or not it should attempt heuristics (reading file name, for instance) or alert the user (by simply announcing 'image') in the latter case.
  17. Creating content on the web that is only accessible by one group of people is never appropriate. Sites like flickr that have tools which let photo contributors upload photos in batches is for convenience. As often happens, convenience for one group of people causes another group of people to be locked out.
  18. Mutual dependencies exist between W3C technical recommendations. Omitting the text alternative for critical content contradicts WCAG and ATAG. What kind of message would having conflicting guidelines send? Think of that. WCAG requires alternative text and that's not likely to change. If HTML5 doesn't consider this important enough to require, the spec might as well be saying WCAG's not really required either.
  19. Anyone suggesting not requiring text alternatives should demonstrate that doing so will be an accessibility improvement. Research must be completed into how user agents deal with the absence of the alt attribute and how this affects the end user. Suggestions of future heuristic tools providing useful content are still in the future.
  20. Allowing text alternatives to be optional in the structure doesn't address the problem of poor alternative text being provided by the author or the authoring tool they use - it is lowering the integrity requirements for conformance. The only obvious benefit is that most tool vendors will automatically adhere to HTML5, as very few adhere to existing standards.
  21. The phrase "When it is possible for alternative text to be provided, (...), text that conveys can serve as a substitute for the image must be given as the contents of the alt attribute" fails the W3C's quality assurance requirements, because "possible" is a subjective term (what is possible to one person may be impossible to another). This would be a discretionary item. Even discretionary items need to be well defined, which is not the case for "possible" in the current HTML 5 draft. The Specification Guidelines in the W3C QA Framework advise specification authors to "Provide as much information as possible to narrow the allowable choices and to increase predictability...Narrowing choices and increasing predictability enhance the likelihood of interoperability since the implementer chooses from a reduced sample space. Narrowing choices, providing more information, and eliminating incorrect choices increases the chances of correct implementations. An enumerated list of values is one way to constrain the choice of optionality." It needs to be shown that the phrase "When it is possible for alternative text to be provided" meets these guidelines.
  22. A language shouldn't have its accessibility features loosened for the benefit of people who consciously deny (or "who don't share the goals of") accessibility. Since people presently use HTML in a way that discriminates against people with disabilities HTML5 should not be complicit in that discrimination.
  23. Requiring the alt Attribute in HTML5 (Rationale roundup) - Gez Lemon
  24. Applicable Design Principles:
    • Accessibility: "Design features to be accessible to users with disabilities. Access by everyone regardless of ability is essential. This does not mean that features should be omitted entirely if not all users can make full use of them, but alternate mechanisms should be provided. The image in an img may not be visible to blind users, but that is a reason to provide alternate text, not to leave out images."
    • Pave the cowpaths: "When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new."
    • Evolution Not Revolution: "Revolutions sometimes change the world to the better. Most often, however, it is better to evolve an existing design rather than throwing it away. This way, authors don't have to learn new models and content will live longer. Specifically, this means that one should prefer to design features so that old content can take advantage of new features without having to make unrelated changes. And implementations should be able to add new features to existing code, rather than having to develop whole separate modes."
    • Solve Real Problems: "Changes to the spec should solve actual real-world problems. Abstract architectures that don't address an existing need are less favored than pragmatic solutions to problems that web content faces today. And existing widespread problems should be solved, when possible."
    • Priority of Constituencies: "In case of conflict, consider users over authors over implementors over specifiers over theoretical purity."

Rationale: Not Requiring a set of programmatically valid options/Text alternatives should be optional

  1. Mail.app and other mail clients don't put alt attributes on images generated in email. Maciej Stachowiak, April 11, 2007.
  2. Some people only imagine it being useful as an advanced feature for experts. Normal people won't understand why a mail program would prompt them to type in some text about an image, that will then not be visible to them or their recipient. - Maciej Stachowiak, April 19, 2007.
  3. Supplying text alternatives takes too much time for too little benefit. Providing accurate replacement text for about six hundred images is a pain. There are many observed cases where alternate text is simply unavailable and there's little that can be done about it. For example, most users of photo sharing sites like Flickr wouldn't have a clue how or why to provide alternate text, even if Flickr provided the ability. While everyone agrees that it would be wonderful if all users did indeed supply alt text and the spec strongly encourages it, in fact most users simply won't. It is unrealistic.
  4. "the single constrain I have: not finding it necessary to provide replacement text for all those images. This would take too much time for little benefit. Let alone the fact that I wouldn't even know how to adequately provide replacement text for those pictures that would still make the application enjoyable." alt attribute, Anne van Kesteren.
  5. "Anyone who honestly believes that there is a snowball's chance in hell that users of image gallery software are going to painstakingly provide alternative text for each and every image they upload is living in a fantasy world. It is unlikely that we can make much progress while people still seriously consider advocating for that as being a productive use of their time." - IMG section of HTML5 draft contradicts WCAG 1 & WCAG 2 - Ian Hickson, April 11, 2008.
  6. "To make a decision on this <img> issue I also have to make some ethical determinations. In particular there is a conflict between allowing any author to publish content, and requiring all authors to publish content that is usable by anyone. while not requiring the effort to create such alternative text to be so great as to take a disproportional amount of time and thus not requiring all authors to publish content that is usable by anyone. This is similar to how HTML5 doesn't require all content to be written to be understandable by 3 year olds or dogs." - The alt="" attribute, Ian Hickson, August 26, 2008.
  7. "it is not reasonable to expect an ordinary person to provide alternative text when bulk-uploading thousands of vacation photos. In the real world we accept that it is reasonable to place accessibility burdens on public accomodations, such as places of business, sidewalks, or public broadcasts, but not on private individuals." - Is Flickr an Edge Case?, Maciej Stachowiak, May 26, 2008.
  8. "most users of photo sharing sites like Flickr wouldn't have a clue how or why to provide alternate text, even if Flickr provided the ability. While everyone agrees that it would be wonderful if all users did - indeed, the spec strongly encourages that - most users simply won't." - Lachlan Hunt, August 23, 2007.
  9. It is a technical solution if you have these constraints: A.) The user is not going to be bothered providing replacement text. Or any other metadata for that matter. B.) The application author wants all his pages to be conforming. Well, at least for the machine checkable criteria. You can't use the concept of validity to stop people from achieving the results they want. They just figure out a way to do it in a less detectable way which means browsers have a harder time offering counter-measures to the users. Precedent suggests that in the case of validators, people will seek to fool them if the concept of validity stands in the way of the results they want and they have a requirement (for whatever reason) to be valid.
  10. An HTML5 authoring tool MUST NOT emit documents that do not conform to HTML5. Henri Sivonen, January 29, 2009.
  11. No practical accessibility benefits are lost by conceding the fact that you cannot force everyone to provide alternate text and making text alternatives optional for the purpose of document conformance. No-one is claiming that conformance to HTML5 equates to conformance with accessibility requirements. There are lots of things that are considered technically conforming in HTML, yet still inaccessible if used poorly.
  12. Making text alternatives technically optional doesn't stand in the way of accessibility requirements, nor greatly impact upon accessibility evangelism. It just acknowledges the reality of the situation in the hope of reducing the prevalence of poor quality, automatically generated alt text.
  13. No alt text is better than bad (not appropriate) alt text.
  14. People who truly care about accessibility will do alternate text properly (or at least try), no matter what the spec says. People who do not care about accessibility will not do alternate text properly, no matter what the spec says. In between, we have a real, demonstrated problem of software vendors who favor validation over accessibility to the point of actively hurting the latter to satisfy the former.
  15. It would not be effective to force tools to force authors to provide alt text. It won't work in all cases and the problem will still exist. It would seriously affect the usability of a site like Flickr for average users.
  16. The primary purpose of a markup language specification like HTML is that it be able to be used to construct a document with a specific meaning as determined by a publisher, and to permit a consumer to reconstruct that meaning when in receipt of the document. Whether a given document uses alt text or not matters not to that purpose. The optionality of text alternatives is therefore not the concern of the specification. Instead, it seems to be in domain of guidelines, best practices, and perhaps law.
  17. Requiring the alt Attribute in HTML5 (Rationale roundup) - Gez Lemon
  18. Applicable Design Principles:
    • Accessibility: "Design features to be accessible to users with disabilities. Access by everyone regardless of ability is essential. This does not mean that features should be omitted entirely if not all users can make full use of them, but alternate mechanisms should be provided. The image in an img may not be visible to blind users, but that is a reason to provide alternate text, not to leave out images."
    • Pave the cowpaths: "When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new."
    • Evolution Not Revolution: "Revolutions sometimes change the world to the better. Most often, however, it is better to evolve an existing design rather than throwing it away. This way, authors don't have to learn new models and content will live longer. Specifically, this means that one should prefer to design features so that old content can take advantage of new features without having to make unrelated changes. And implementations should be able to add new features to existing code, rather than having to develop whole separate modes."
    • Solve Real Problems: "Changes to the spec should solve actual real-world problems. Abstract architectures that don't address an existing need are less favored than pragmatic solutions to problems that web content faces today. And existing widespread problems should be solved, when possible."
    • Priority of Constituencies: "In case of conflict, consider users over authors over implementors over specifiers over theoretical purity."

Proposed Solutions

Mandatory Text Alternatives/Encourage Guideline Use

Restore the requirement for the text alternatives on all images. Encourage tools that adhere to Authoring Tool Accessibility Guidelines (ATAG), User Agent Accessibility Guidelines (UAAG), and have the ability/features to generate good alternate text. Plus educating users at all levels (professionals, and casual users of web services, such as Flickr) to use those features to adhere to WCAG.

Explicitly Noted Alternatives Via Multiple Methods

Explicitly note and provide as many other ways of providing text alternatives as possible. Having *any* of the methods below of expanding upon the visual-only content present would thus render the <img> element conformant. Any other HTML 5 implementation of <img> which lacks *any* of the provided means of "equivalent alternatives" be non-conformant. (Note: the editor picked up on a variation of a John Foliot proposal in his (Option F). 

 *@alt and/or @longdesc (if longdesc is put into the spec)
 *@alt and/or @legend
 *@alt and/or @id
 *@alt and/or @figure
 *@alt and/or @caption
 *@alt and/or (ARIA Variants suggested)
 *@alt and/or (suggested reserved values)
 *@alt and/or (open to further suggestions)

Option F

The wording in the editor's draft is Option F (a variation of John Foliot's proposal).

On August 26, 2008 the editor explained the proposal saying, "We could say that for these key content without alt text cases, we have the alt="" attribute omitted, but there must be at least one of the above, and the first of the above that is present must include sufficient information to orient the user." The example he gave:

  • title="" attribute on the <img> itself
  • <legend> of the <figure> that contains the <img>
  • heading of the section that contains the <img>

This idea has several ways of providing alternative text, which don't have to come from the alt attribute. That is fine. It's the user agent's job to provide that information through an accessibility architecture, so it could be made to work.

If the general phrase "key content without alt text" is changed to "images without alt text", "Option F" could work, as it requires that there must be at least one of the options. But "key content" is subjective and open to abuse.

There is a residual issue in that Option F doesn't specify that if no accessible option can be determined, then the resulting structure should be considered non-compliant. The real issue of ensuring that images have an accessible alternative is not addressed. Any page that lacks a text alternative for an image by at least one of the proposed methods needs the validator to flag the error and declare the page invalid. This is the missing point in the Option F idea. Requiring the text alternatives by at least one of the proposed methods is needed.

Missing Attribute

It is possible to require a set of programmatically valid options which maintains the integrity of the markup and aids accessibility while addressing business needs. WAI CG said that they would not oppose a "missing" attribute.

Creating "missing" attribute would address the business concern of authoring tools wanting to conform to HTML5, even if the author does not supply a text alternative. The outcome would be a practical method of detection, repair, and handling.

Outcomes of Creating a Missing Attribute
  • Allow each image without a text alternative to be honestly labeled for what it is: missing, incomplete, lacking substance.
  • Affirms that the author did not (and does not intend to) provide a text alternative.
  • Provide a machine checkable mechanism to pinpoint incomplete <img> elements and enable tools to quickly discern where "missing" has been used so mistakes can be fixed.
  • Provides assistive technology an image level "missing" hook.
  • It is a practical method of detection and handling.
  • Has possibilities for crowdsourcing.
  • Supports ethical accountability by promoting the development of responsible tools and by advocating an effective enabling environment.
Crowdsourcing

Possibilities for crowdsourcing exist with the addition of a dedicated "missing" "usergenerated" or "incomplete" or "altneeded" or "altunknown" attribute.

Matt May envisioned an attribute to facilitate crowdsourcing. He said,

I don't want to propose a solution to the problem when I think the status quo in HTML 4.01 doesn't need to be mucked with. But, okay, you read a big long accessibility article, so here's a thought experiment. Add an attribute. Call it @usergenerated. When a UA encounters this attrib, it indicates that the author has stated alt cannot be provided programmatically. It would be even better if other users could detect that attrib and annotate the attached image. If you could get around the spam potential, this could be a real winner. Crowd-sourced @alt. That’s actual accessibility progress, measurable today. If you can't do that much, leave @alt alone.

This idea would get around one of the biggest problems with images: that we can see something is wrong with someone else's content, but can't do anything about it. With this method people who know what they're doing could directly impact the accessibility of another organization's content. This is in the spirit of initiatives such as Webvisum and the Social Accessibility Project, a utility that enables volunteers to make Web pages accessible to the visually impaired. It might help image gallery sites since the image creator or anyone who views the image could propose usable text alternatives with an extremely low-bandwidth solution.

It should be reasonably easy to maintain a hash of images with a dedicated attribute and the obtain the value(s) submitted for them. We would need a canonical URI (or in HTML5, an 'origin') for the document and an ID for the image, but if we had a service (either local or remote) that accepted the URI and its @alt value, then users of AT could associate the values as needed. The worst case is that nothing is returned. (The second-worst case is that it's a bogus value, but the owner of the document could manage submitted @alt content.) The pointer to where to send this information could be in a <link> element, and it could be a standard HTTP request, or a transaction using the HTML5 Database object. It could be hosted locally, or by a third party.

If this method is accepted, the following would need to be specified:

  • a missing attribute
  • any image with a missing attribute also needs an ID, or it wouldn't be associable by the UA/AT.
  • rel attribute for the <link> to the mechanism for associating the alt attribute.

It is optional if this attribute is created per WAI CG advice.

Crowdsourcing References:

Generated Attribute

Create a "generated" attribute to indicate that a metadata repair technique is being used. It would enable tools to quickly discern where text alternatives are needed and allows for future improvement. It would provide a practical method of detection and handling.

A generated attribute would identify/stamp the metadata as indeed a metadata repair to make it clear it is a machine-generated patch-job and not a human-generated text alternative. The two aren't the same and shouldn't be confused or on purpose or otherwise. Machines may be capable of composing good alt text some day in the future. But until then if it is labeled for what it is, a mechanism is available to locate it. It enables tools to quickly discern where it has been used and allow for future improvement by a human.

Generated Example

  1. Author logs into the photo sharing site
  2. Author uses the uploader feature to upload 50 pics of a vacation (XYZ0001.png, XYZ0002.png,..., XYZ0050.png) into an album the author calls "Paris 2009".
  3. A prompt appears asking the author to write descriptive labels for each image to facilitate text searching and access by people with disabilities.
  4. The author logs off without adding individual text alternatives.
  5. The photo sharing site assigns the @alt strings "Photo 1 of 50 of album Paris 2009"
  6. The the author logs back in they still see indicators on the images and/or the album that reminds them that the images are still lacking descriptive labels.
  7. The page will be HTML5_valid because it includes @alt
  8. The feature will meet the PROPOSED ATAG2 requirement because the "After authoring session ended" repair used contextual information not available to the user agent.
  9. The page will NOT meet WCAG 2.0 because the text alternative does not serve the equivalent purpose

Conscious Decision with Error Handling

Have tools like Flickr default to images remaining invisible to the public until:

  1. Text alternatives are provided by the author or
  2. A conscious decision has been made by the author to deliberately publish them without text alternatives.

If option 2 is chosen use a metadata repair technique which identifies/stamps the metadata as indeed a metadata repair to make it clear it is a machine-generated patch-job and not a human-generated text alternative. The two aren't the same and shouldn't be confused or on purpose or otherwise.

Then something with no author input relying exclusively on metadata for a text alternative could be an error or a warning, or at least a nice debate could ensue regarding its severity level. Example:

<img src="http://flickr.com/noauthorinput.jpg" alt="JoeBlow's photo taken 22 November 1964 at 17:33:06" metadata="true">

This solution would:

  • provide a means for conscious author deliberation
  • provide error detection and handling
  • enable accessibility tools and validators to quickly discern where metadata has been used and allow for future improvement of the text alternative

Meta Data

Embedded metadata in images is an example of a simple fix to the "aggregator problem" -- how to provide human parseable metadata while bulk-uploading images. Another advantage of embedded metadata is that it makes possible a "central depository" which can be used to compare and/or overwrite the embedded metadata -- a mechanism akin to the database search one routinely performs for an audio CD; where multiple results are returned, one simply reviews each result, and picks that which best fills/meets one's needs at that particular time.

Embedding Metadata:

RDFPic [RDFPic] is a tool developed by the W3C to embed an RDF description of a picture into the picture itself, as described by Describing and Retrieving Photos using RDF and HTTP [PHOTO-RDF], a W3C Note describing a project for describing and retrieving digitized photos with metadata. It describes the RDF schemas, a data-entry program for quickly entering metadata for large numbers of photos, a way to serve the photos and the metadata over HTTP, and some suggestions for search methods to retrieve photos based on their descriptions. The RDF schema uses the Dublin Core schema as well as additional schemas for technical data. This is a tool which a user could use to add a terse and long descriptor to each image being bulk-uploaded.

Metadata Use Cases:

Scenarios for exposing Exchangeable Image File (EXIF), International Press Telecommunications Council (IPTC), and Extensible Metadata Platform (XMP) image descriptions so that users can access include:

  • A photographer takes a photo with his SLR digital camera. He describes the image in camera via text input (LCD monitor and multi-selector). It is stored in EXIF. He uploads that image to a photo image gallery application that does not offer a means to enter a text alternative. He would like to have that text description available for his visually impaired friends to access directly.
  • A graphic designer creates an image in Photoshop. From the file menu, he chooses "File Info" then enters a IPTC headline and description. He uploads that image to a web page. A visually impaired person wants to directly access that headline and description.

Meta Data References:

Mandatory alt with Child Exception

Make the alt attribute "required except when the element is a child of x". The use case for <img> without alt is the same use case for <figure>. So make <img> without alt only be allowed as a child of a <figure> element. (Note that images representing text inside a <legend> should obviously include @alt).

noalt Flag

Explicitly flag images that have the alt attribute omitted with something like a 'noalt' attribute that is to be used when alt text for some reason cannot be specified. This would make it known that the author (or authoring tool) has intentionally not supplied an alt text. It would also make it easier to use validation to check for mistakenly missing alt attributes and provide a clear indication that the image has no alternative text, but contains "critical content" rather than just being a decorative or layout image that the author has not provided an alt attribute for due to ignorance or laziness.

Reserved Value

Reserved value for alt like alt="_none" (with the underscore) for instances when automated tools do not allow for author supplied alt text. While it does not completely address the real problem (the image still is inaccessible to the non-sighted/non-visual UA), User Agents could be configured to deal with an expected value such as this consistently (as could Adaptive Technology), and equally important maintains the requirement of an alt value in an image. Will content authors continue to abuse this? Probably, but they will be making a conscious decision to 'abuse', rather than skate by their responsibility by pointing to a spec and saying "see, it's allowed".

Reserved Value Variation

User enters attribute "_none" (alt="_none"). This entered value signifies a conscious decision by the author that the associated image's alt attribute should be empty. Authoring tool (CMS) enters value "_omit" (or other) to signify that the content editor has omitted alt attribute. This is the equivalent generated value to hand-coded _none. (By providing this ability we make a clear distinction between user entered and Authoring Tool generated.). Authoring tool (CMS) enters value "_ignored". This generated value signifies that content editor ignored the alt attribute.

Generic Attributes

Use of generic attributes like ARIA labelledby and describedby.

"unready" Stamp

Use of an "unready" stamp, which all authors and all editing tools could use, when they need to offer HTML which they consider technically unready. (Because of the relativity of what e.g. a good 'alt' is, the author/editor judgment always matter.) When one sets the "unready" flag, it will never formally validate, even if there are no formal errors. If you don't include the 'unready' flag, then readers should assume that the author think it is technically ready.

Enumerated Labels

Use of enumerated labels such as alt="1", alt="2", etc.

New purpose or rel Attribute

Add an additional attribute to the image element called purpose or rel for meta information regarding the kind of image (e.g. user-uploaded image, photo, diagram).

Role Values

Curly Braces

Make alt="" required and say that when you don't know what the image is, you have to say what kind of image it is (e.g. "uploaded image", "photo", "thumbnail", or whatever) and put that in braces in the alt="" attribute, as in alt="{photo}".

HTML 5 Apathetic Doctype

The Solution is a HTML 5 Apathetic Doctype by Steven Clark

Alt as Role and New "importantimage" Attribute

Require alt="" to be specified on these images (e.g. with suggested "External Image", or "Photo", or whatever -- a caption, in this case, not an alternative) and then add a new attribute which means "This image is intended to be used as an image and cannot be considered equivalent to any text". Then, the alternative text (which would be required to be a short label for the kind of image being discussed, not its caption, not a description, and obviously not any kind of alternative or replacement) would be taken and made available to the user in a UI like this: [Image: Photo] ...in a manner clearly distinguishable from Photo and <img src="..." alt="Photo"> (and maybe more similar to <a href="">Photo</a>). Expected values for this attribute would be things like "Photo", "User- provided image", "Rorschach inkblot test", or similar; values that would otherwise be completely inappropriate for alt="". It would then be non-conforming to have such alt text (text saying what kind of image is present as opposed to text that can replace the image altogether) _without_ this new attribute. Example: 

   <figure>
    <img src="1100670787_6a7c664aef.jpg" alt="Photo"
         importantimage="importantimage"/>
    <legend>Bubbles traveled everywhere with us.</legend>
   </figure>

References

HTML 5 Draft: img element

HTML5: Techniques for providing useful text alternatives

Accessibility Task Force: Text Alternatives

General Alt Attributes, Alt Text articles

Issue 31 History, Actions, Bugs and Related Issues

Topic of <img> and the Alt Attribute First Raised at WHATWG:

WHATWG Announcement:

Request for PFWG CG WAI Review:

Issue-31: What to do when a reasonable text equivalent is unknown/unavailable?:

Related E-mail Threads

April 2007

June 2007

August 2007

September 2007

October 2007

February 2008

April 2008

May 2008

June 2008

August 2008

January 2009

February 2009

April 2009

June 2009

July 2009

December 2009

January 2010

February 2010

March 2010

April 2010

May 2010

June 2010

July 2010

August 2010

November 2010

February 2011

March 2011

April 2011

May 2011

Search on Markmail for Related E-mail

Retrieved from "https://www.w3.org/html/wg/wiki/index.php?title=IssueAltAttribute&oldid=13768"