Omitting Text Alternatives on <img>

Issue

The img element section in the latest published HTML 5 Draft 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.

It says: "In a rare subset of these cases, there might be no alternative text available. This could be the case, for instance, on a photo upload site, if the site has received 8000 photos from a user without the user annotating any of them. In such cases, the alt attribute may be omitted, but the alt attribute should be included, with a useful value, if at all possible. In any case, if an image is a key part of the content, the alt attribute must not be specified with an empty value."

Text alternatives are essential for accessibility. HTML 5 should have a markup technique to indicate whether or not the alternate text of an image is critical to understand the content, though differentiating reliably between ignorant and intentional lack of text is a challenge. The issue is ensuring images have accessible alternatives.

Status

Open Issue:

Option F

The current 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:

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.

Issue and Action History

Announcement

Request for PFWG CG WAI Review

ISSUE-31

ACTION-54 Draft text to require producers/authors to include @alt

Call for Papers

ISSUE-31 Curly Brackets

Note: The Curly Brackets idea was taken out of the editor's draft and replaced by Option F (a variation of John Foliot's proposal).

ISSUE-66

ACTION-98 Discuss missing-alt with the WAI CG and report back

Bug 6494

Bug 6496

Contents

  1. Omitting Text Alternatives on <img>
    1. Issue
    2. Status
        1. Option F
    3. Issue and Action History
      1. Announcement
      2. Request for PFWG CG WAI Review
      3. ISSUE-31
      4. ACTION-54 Draft text to require producers/authors to include @alt
      5. Call for Papers
      6. ISSUE-31 Curly Brackets
      7. ISSUE-66
      8. ACTION-98 Discuss missing-alt with the WAI CG and report back
      9. Bug 6494
      10. Bug 6496
    4. Proposed Solutions
      1. Conscious Decision with Error Handling
      2. Explicitly Noted Alternatives Via Multiple Methods
      3. Mandatory alt with Child Exception
      4. noalt Flag
      5. Reserved Value
      6. Reserved Value Variation
      7. Generic Attributes
      8. "unready" Stamp
      9. Enumerated Labels
      10. New purpose or rel Attribute
      11. Role Values
      12. Curly Braces
      13. Alt as Role and New "importantimage" Attribute
      14. Mandatory Text Alternatives/Encourage Guideline Use
    5. Rationale: Why alt Should Not Be Optional
    6. Rationale: alt Should Be Optional
    7. Research
    8. Advice From Accessibility Authorities
      1. WAI and the PFWG
      2. WAI CG and the PFWG
      3. WCAG 2.0 WG
        1. Comment 2615: Image use cases that WCAG doesn't address
        2. Resolution
    9. Use Cases
    10. Policies, Guidelines, and Law
    11. References
      1. HTML 5 Draft: img element
      2. Relevant Cited Blog, Wiki Posts and Papers
      3. Relevant IRC Logs
      4. General Alt Attributes, Alt Text articles
    12. Related E-mail Threads
      1. August 2007
      2. September 2007
      3. October 2007
      4. February 2008
      5. April 2008
      6. May 2008
      7. June 2008
      8. August 2008
      9. January 2009
      10. February 2009
      11. April 2009
      12. June 2009
    13. Search on Markmail for Related E-mail

Proposed Solutions

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:

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, and further suggest that this result with the most drastic of consequences: image non-rendering. (Give out more rope, but increase the risk of hanging oneself). These (and perhaps other) means/tools at their disposal, would cover the the end (human) author or at the "program" level (WYSIWYG/file upload site/etc.) scenarios. (Note: the editor picked up on a variation of this proposal in his (Option F).

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}".

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 <span>Photo</span> 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>

Mandatory Text Alternatives/Encourage Guideline Use

Restore the requirement for the text alternatives on all images. Encorage 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.

Rationale: Why alt Should Not Be Optional

  1. It creates a scenario where authors can (and most likely will) start finding "justifications" based on their opinions, to not supply alt text rather than facts and needs. It suggests that it's OK to "sometimes" not provide alternative text. 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.

  2. 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.

  3. 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 alt text 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.

  4. 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.
  5. An incomplete does not equal a passing grade. Optional should not be valid.
  6. 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?
  7. 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.
  8. 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 alt 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. From an architectural point of view, the structure of an image isn't complete without alternate text, so it should be a required attribute for that reason alone.
  14. 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.
  15. Allowing alternate text 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.

  16. 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.

  17. 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.

  18. Requiring the alt Attribute in HTML5 (Rationale roundup) - Gez Lemon

  19. 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: alt Should Be Optional

  1. Supplying alt attributes 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.
  2. 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.
  3. An HTML5 authoring tool MUST NOT emit documents that do not conform to HTML5.
  4. No practical accessibility benefits are lost by conceding the fact that you cannot force everyone to provide alternate text and making the alt attribute 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.
  5. 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.
  6. No alt text is better than bad (not appropriate) alt text.
  7. 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.
  8. 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.
  9. 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.

  10. Requiring the alt Attribute in HTML5 (Rationale roundup) - Gez Lemon

  11. 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."

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

WCAG 2.0 WG

Comment 2615: Image use cases that WCAG doesn't address

"This comment is about Guideline 1.1 Text Alternatives, and this comment is about the substance of the guideline. The HTML5 draft[1] gives advice and examples for including text alternatives for a variety of image uses cases. As far as I can tell, the following use cases aren't addressed by WCAG 2.0:

Source: Henri Sivonen

Resolution

"We try to make our guidelines match technical standards to the extent possible. We have looked at the HTML 5 standard and we note that although many of the examples match the WCAG 2.0 guidelines - some do not, including the ones you mentioned. (although the second example you mention seems to have been removed from the September editors draft) We are adding one sufficient technique to make it clear that some of the examples in HTML 5 do conform with WCAG. The new technique is: G196: Using a text alternative on one item within a group of images that describes all items in the group (http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-TECHS/G196.html) As for the other one you cite above, we think that WCAG currently draws the line in the right place and changing the standard would create problems for accessibility." WCAG WG

Source: Comment 2615, WCAG 2.0

Use Cases

Policies, Guidelines, and Law

References

HTML 5 Draft: img element

Relevant Cited Blog, Wiki Posts and Papers

Relevant IRC Logs

General Alt Attributes, Alt Text articles

*Alt Attributes, Alt Text References

Related E-mail Threads

August 2007

September 2007

October 2007

February 2008

April 2008

May 2008

June 2008

August 2008

January 2009

February 2009

April 2009

June 2009

Search on Markmail for Related E-mail

HTML/IssueAltAttribute (last edited 2009-06-21 17:46:19 by LauraCarlson)