Omitting alt Attribute for Critical Content

Issue

The img element in the current HTML 5 Draft allows instances where content may have no alt attribute, not just a null alt attribute for eye candy, but no alt attribute 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."

Alternate text is 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. Emperical studies to date indicate that a missing alt is generally an indicator of ignorance (not knowing or caring to add alternative). An alt="" either means the author knew enough to not want to put an alternative in (e.g. decorative/spacer image), or it was automatically put in for them.

Tracker status

Open Issue:

Issue 31: missing-alt

Actions:

Table of Contents:

Contents

Omitting alt Attribute for Critical Content

Proposed Solutions

Restore the requirement for the alt attribute on all critical content.
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 associate text content with an image for cases where the image does not have a "text alternative" provided. In cases such as photo galleries some or all of the markup containers may initially be empty allowing users to provide text content. Programmatically define the relationship between image and potentially related text content. For instance the legend element could explicitly provide text alternative. <figure> <img><legend>image caption</legend></figure>
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).
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 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".
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.
Use of generic attributes like ARIA labelledby and describedby.
Images uploaded in bulk, through a camera (or FTP), are not Web content. They are just files which a Web application may use to decorate a Web page. These images are no different than Word documents or TIFF files uploaded via FTP. All that has happened is that non-HTML files have been uploaded in bulk, no content has been authored here! Since there files (images) are not Web content, the Web application should generate the img element with alt="".
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.
Use of enumerated labels such as alt="1", alt="2", etc.
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).
Use a role attribute for meta data. As more and more photographs are taken with digital cameras it is very easy to tag them as role='photo' from the internal metadata of the image format.
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}".
Explicitly note and provide as many other ways of providing alt text 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.
- @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)
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>

Rationale: Why Alt Should Not Be Optional

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 the alt attribute 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 alt attributes. After all it is optional, not needed, out of sight out of mind, so 2007. Practically deprecated. Optional = not needed.
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.
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.
Condoning the omission of the alt attribute 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 alt attribute? Then if its okay for ten why not one?
Requiring the alt attribute is an undeniable advertisement that alt exists, 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 alt that is noted here (repeating text, useless information) is because when authors first discovered that they must use alt, they were given poor instructions. With the improved specification of the usage of alt, it makes all the more sense to keep alt as a required attribute. If alt is not required, all the existing content with alt abuse will remain. With alt required, there is a better chance that authors will find out how to use it better.
Boiling the issue down to an image having or not having an alt attribute 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 signalling to assistive technology whether or not it should attempt heuristics (reading filename, for instance) or alert the user (by simply announcing 'image') in the latter case.
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.
Mutual dependencies exist between W3C technical recommendations. Omitting the alt attribute 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.
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.
Anyone suggesting not requiring alt 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.
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.
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.
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.
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."

Rationale: Why Alt Should Be Optional

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.
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.
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.
Making alt 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.
No alt text is better than bad (not appropriate) alt text.
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.
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.
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 alt is therefore not the concern of the specification. Instead, it seems to be in domain of guidelines, best practices, and perhaps law.
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."

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

Use Cases

XStandard 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.
flickr
photobucket
Other software with Web Photo Album features like snapfish, smugmug and shutterfly.
Most "social network" type sites such as myspace and facebook also feature photo galleries. deviantart also provides image galleries but focuses on artwork rather than photos.
alt use cases
Re: alt and authoring practices - Steve Axthelm
Nvu - Daniel Glazman

Policies, Guidelines, and Law

B.2.4 Assist authors to ensure that equivalent alternatives for non-text objects are accurate and fit the context. - Authoring Tool Accessibility Guidelines 2.0
3.4 Authoring Tool Accessibility Guideline (ATAG). "Do not automatically generate equivalent alternatives. Do not reuse previously authored alternatives without author confirmation, except when the function is known with certainty...prompt the author for a text equivalent of an image. If the author has already provided a text equivalent for the same image used in another document, offer to reuse that text and prompt the author for confirmation."
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
Section 508
Dutch Accessibility Law see section R-pd.7.1; English Translation: "Alt (alternative) attribute must be used on every img (image) and area element and must become to provide with an effective alternative text."

References

HTML 5 Draft: img element

img element

Relevant Cited Blog and Wiki Posts

Relevant IRC Logs

General Alt Attributes, Alt Text articles

Alt Attributes, Alt Text References

Related E-mail: August 2007

Thread: Investigating the proposed alt attribute recommendations in HTML 5

Thread: Alt Text for A Key Part of the Content

Related E-mail: September 2007

Thread: a question about alt

Thread: Investigating the proposed alt attribute recommendations in HTML 5

Thread: More about <alt>

Thread: testing versus expert opinion

Thread: alt options

John Foliot (Friday, 21 September)

Omitting alt Attribute for Critical Content

Issue

Tracker status

Proposed Solutions

Rationale: Why Alt Should Not Be Optional

Rationale: Why Alt Should Be Optional

Research

Advice From Accessibility Authorities

WAI and the PFWG

Use Cases

Policies, Guidelines, and Law

References

HTML 5 Draft: img element

Relevant Cited Blog and Wiki Posts

Relevant IRC Logs

General Alt Attributes, Alt Text articles

Related E-mail: August 2007

Thread: Investigating the proposed alt attribute recommendations in HTML 5

Thread: Alt Text for A Key Part of the Content

Related E-mail: September 2007

Thread: a question about alt

Thread: Investigating the proposed alt attribute recommendations in HTML 5

Thread: More about <alt>

Thread: testing versus expert opinion

Thread: alt options

Thread: [html4all] 5 gears in reverse - anne v k enters the alt attributedebate

Thread: [html4all] the alt attribute debate

Thread: alt attribute comments?

Thread: Investigating the proposed alt attribute recommendations in HTML 5

Related E-mail: October 2007

Thread: What now ALT?

Thread: Request for PFWG WAI review of Omitting alt Attribute for Critical Content

Related E-mail: February 2008

Thread: Request for PFWG WAI review of Omitting alt Attribute for Critical Content

Related E-mail Threads: April 2008

Related E-mail Threads: May 2008

Related E-mail Threads: June 2008

Related E-mail Threads: August 2008