ChangeProposals/ImgElement20090126

Correct and Improve <img> Conformance Checker Guidance

Summary

The Web Initiative Accessibility Coordination Group (WAI CG) [3] convened a special task force in 2009 to study HTML ISSUE-31 comprehensively. The group provided a holistic solution to the problem [4] which contains a number of pieces that work together to enable automatic validators to programmatically determine [5] the presence or absence of text alternatives [6] on the <img> element in order for <img> to be considered valid.

This proposal implements WAI CG's recommendation for short text alternatives. It improves the current conformance checkers guidance [7] by:

  • Correcting the spec to disallow <img> to be valid with the generator mechanism, email exception, and title attribute.
  • Strengthening the spec to allow <img> to be valid with aria-labelledby or the role attribute with a value of "presentation".


Rationale

Text alternatives (even if that alternative is to indicate an image is presentational) for the <img> element are needed to provide equal access to users.

To this end,

  • HTML5 should require structural integrity for the <img> element.
  • HTML5 should help facilitate accessibility awareness and education.
  • HTML5 should not facilitate the creation of inaccessible content.
  • HTML5 should not make rules beyond its scope.
  • HTML5 should not provide inaccessible text alternative features.
  • HTML5 should provide for new and better text alternative features.

HTML5 Should Require Structural Integrity for the <img> Element

Requiring a set of programmatically determinable valid options helps ensure that images have complete structure. Complete structure of the <img> element requires both src and text alternatives.

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.

Lowering standards to move away from a situation that explicitly requires the language of the web to be non-discriminatory, to one where the language of the web allows discrimination to be valid would be a step backward. "There is little dispute that we should work towards a Web for All" as Jeff Jaffe said in the The Mission of W3C [8]. United Nations Article 9 declares people with disabilities shall be ensured equal access to information and communications technologies and systems [9].

Addressing the Authoring Tool Rule

The authoring tool rule states, "Authoring tools and markup generators must generate conforming documents. Conformance criteria that apply to authors also apply to authoring tools, where appropriate." [10].

It grants an exception to the address element because, "authoring tools are not yet able to determine author intent".

As in the case of an authoring tool not knowing author intent for an address element, it cannot know author intent in the case of text alternatives. Gez Lemon has stated the situation clearly [11],

When an authoring tool doesn't have anything useful to put in for the alt text, the tool shouldn't put anything in. A good authoring tool will check for missing alt text and offer to assist the user in repairing the content. If an author is adamant they're not going to provide alt text, there is no requirement that says the authoring tool should provide it in place of the author. In fact, it's just the opposite, as the authoring tool could not possibly know the author's intent. In this scenario, the authoring tool should not include the alt attribute at all, and the resulting markup should be considered invalid. It should be considered invalid because it is inaccessible, and not perceivable by some people. If the tool allows alt text to be provided, then the tool would be considered compliant (on this particular issue), even though the resulting markup would not be compliant, as the user chose not to make the content compliant.

HTML5 Should Help Facilitate Accessibility Awareness and Education

Enabling automatic validators to programmatically detect the presence or absence of text alternatives (as 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. More people use the W3C validator than read the specs. 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 [12].

Requiring a set of programmatically determinable validity options aids in accessibility education [13]. In other words, validators create a teachable moment. Indeed, the W3C validator is currently used for university classes as a valuable teaching and learning tool. For example, a first lesson in teaching good authoring practice is to have developers and students 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 for valid HTML as well. When accessibility is an integrated part of authoring good HTML, the outcome is more perceivable content.

People fix errors. Directly pointing authors who encounter a missing text alternative error to advice on how to fix it will offer an especially powerful learning method exactly when it is needed called Just-in-Time Training (JITT). Mike Smith is working on a pilot validator implementation for missing text alternative error reporting. As the accessibility task force recommendation stated, the "error text is expected to reference additional guidance on text alternatives in WCAG support materials".

HTML5 Should Not Facilitate the Creation of Inaccessible Content

The generator mechanism not only allows incomplete and inaccessible structure of single <img> elements, it facilitates the creation of full documents of content not perceivable to some people.

The current spec pardons complete pages of content containing from one to an infinite number of missing text alternatives and allows them to be valid when software automatically inserts meta name="generator". A few samples include:

  • <meta name="generator" content="Dreamweaver">
  • <meta name="generator" content="Adobe InDesign">
  • <meta name="generator" content="Microsoft Word">
  • <meta name="generator" content="WordPress">
  • <meta name="generator" content="BBEdit">
  • <meta name="generator" content="TextMate">
  • <meta name="generator" content="StarOffice/OpenOffice">
  • <meta name="generator" content="Joomla!">

This would affect an astronomical quantity of pages.

The generator mechanism is actively harmful to accessibility. If the generator option is left at document level, it would be far too easy for authors to have the software automatically insert "generator" and then forget to provide any text alternatives for images. Well meaning authors, do indeed do the right thing when confronted with an error. "Conformance is about trying to advise authors to do the right thing", as Ian Hickson has said [14].

The generator mechanism emasculates the vaildator as learning tool and renders it worthless for teaching text alternatives for all pages created with an authoring tool that inserts meta name="generator".

The generator mechanism breaks standards and guidelines requiring text equivalents on an individual element basis. These include but are not limited to:

  1. 508: Standards issued by the Access Board under Section 508 of the Rehabilitation Act cover access to electronic and information technology procured by United States Federal agencies and require a text equivalent for every non-text element [15].
  2. Section R-pd.7.1: Dutch Accessibility Law 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" [16].
  3. States and State Agency Policy and Standards: For instance many University Web Standards such as the University of Minnesota Standard state "Include alternative text for all graphics" [17].
  4. WCAG: Text alternatives are required for "any non-text content" [18].
If any generated or missing mechanism is included in HTML5, it should only be included at the element level where it could be dealt with on an image-by-image case with a detection method such as a generated or missing attribute, rather than at the document level. At least an attribute would provide a practical method of detection and handling on an individual element, granular basis rather than sweeping a whole inaccessible page under the rug and proclaiming it valid. This would:
  • Allow each image without a text alternative to be honestly labeled for what it is: missing, incomplete, lacking substance.
  • 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.
  • Provide assistive technology an image level "missing" hook.
  • Have possibilities for crowdsourcing [19].
  • Support ethical accountability by promoting the development of responsible tools and by advocating an effective enabling environment.

Allowing text alternatives to be optional in the structure doesn't address the problem of text alternatives being provided by the author or the authoring tool they use - it is lowering the integrity requirements for the sake of tools passing the validator. The only benefit is that most tool vendors will automatically adhere to HTML5, as very few adhere to existing standards. The exception is a way to codify and bless bad tools. It sanctions them at the sacrifice of accessibility.

HTML5 Should Not Make Rules Beyond Its Scope

Private communication and email exceptions undermine text alternatives as a needed structural part of the <img> element, and goes beyond the scope of HTML5. It clutters the specification with an off-topic assertion:

When an image is included in a private communication (such as an HTML e-mail) aimed at a specific person who is known to be able to view images, the alt attribute may be omitted.

The HTML specification should be about the markup.

  • It is an author's prerogative not to provide text alternatives for images because they're writing for themselves, close friends or relatives. However, a HTML <img> element without both src and text alternative is still not complete. Therefore, it should not be considered valid.
  • It is a company's prerogative to allow inaccessible content on a private intranet. However, a HTML <img> element without both src and text alternative is still not complete. Therefore, it should not be considered valid.
  • It is a tool's prerogative not to follow ATAG [20]. However, a HTML <img> element without both src and text alternative is still not complete. Therefore, it should not be considered valid.

The out of scope rule itself makes assumptions regarding:

  1. Profiling, targeting, and discriminating between people on the basis of ability or disability.
  2. Degrees of disability. It may vary over time. The rule takes a static approach to visual impairment.
  3. Lifetime of messages and private documents: Emails get forwarded. The addressed recipient isn't always the actual recipient. Documents can go from being private to being public.
  4. Sighted recipients. They
    • May have a slow connection and turn off images to speed download.
    • May have an expensive data roaming connection (that is not slow).
    • May have images turned off to decrease bandwidth use in order to lower their Internet usage fees.
    • May have a text-only user agent.
    • May be 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.

In addition the United States Twenty-first Century Communications and Video Accessibility Act of 2010 (S. 3304) requires accessibility of advanced communications equipment and services, such as text messaging and e-mail [21].

HTML5 Should Not Provide Inaccessible Text Alternative Features

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 [22].

Steve Faulkner's Change proposal for ISSUE-80: title-alternative provides full rationale for removing this exception [23].

HTML5 Should Provide for New and Better Text Alternative Features

WCAG2 allows a text alternative to be expressed in other programmatic containers besides the alt attribute. Two cases in particular distinguish syntax for cases, which yield more accessible content.

aria-labelledby Attribute

For visual users an image can have an implied label due to proximity and placement in relation to the image. The aria-labelledby attribute provides a method to explicitly associate a text alternative with an image, like the alt attribute. The difference being that the text is available to all by default facilitating universal design.

This technique would be especially useful for image galleries with the:

  • Developer adding the aria-labelledby attribute to the template.
  • Author adding a text alternative via a text field.

Example markup:

<h1 id="heading">wind dog</h1> 
<!-- Flickr Markup* -->
<img aria-labelledby="heading">

Between heading and image in the aria-labelledby example is Flickr Markup* from the source wind dog.

aria-labelledby advantages include:

  • Short text alternatives elsewhere in a document can be explicitly associated with the image.
  • Short text alternatives can be available for all users.
  • Text from several sources within the same document can be explicitly associated with an image.

role="presentation" Attribute

role="presentation" programmatically conveys to assistive technology that an image is presentational and not of interest. It can be placed on any element to indicate that it should not be included in the accessible tree by the browser. It is intended that user agents do not expose the element role via accessibility APIs when role="presentation" is present on an element.

As per the current spec (3.2.6 Annotations for assistive technology products (ARIA)) [24], alt="" on an image has an implied ARIA role of presentation, although current implementations do not honor this.

The use of alt="" does not result in the <img> element being removed from the accessible tree by browsers. Assistive Technology recognize alt="" as indicating that the image can be safely hidden from the user, but their ways of handling this are not uniform. So in the spec role="presentation" and alt="" are equivalent. Allowing role="presentation" to be a conforming replacement for alt="" simply recognizes what the spec states.

Why allow role="presentation" to act as an alternative to alt="" ?

  • It is specified and implemented to do what alt="" is specified to do.
  • It is non specific, it works on all elements.
  • As per the rules specified in current spec pertaining to its use [24], the use of role="presentation" is not dis-allowed on the img element it is in fact stated that it is the only role that can be applied to an img that has an alt="", so you can do this:
<img role="presentation" alt="">

and no where in the aria section [24] does it state you can't do this:

<img role="presentation">

but it will result in a conformance error, which appears both incongruous and illogical.

Details

Replace the Current Text:

A conformance checker must report the lack of an alt attribute as an error unless one of the conditions listed below applies:

  • The title attribute is present and has a non-empty value (as described above).
  • The img element is in a figure element that contains a figcaption element that contains content other than inter-element whitespace (as described above).
  • 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.
  • The document has a meta element with a name attribute whose value is an ASCII case-insensitive match for the string "generator". (This case does not represent a case where the document is conforming, only that the generator could not determine appropriate alternative text - validators are required to not show an error in this case to discourage markup generators from including bogus alternative text purely in an attempt to silence validators.)

With Suggested Text

A conformance checker must report the lack of a text alternative as an error. The image element <img> is only valid when at least one of the following is true. The

  • alt attribute is present (empty or non-empty), or
  • aria-labelledby attribute present (non-empty only), or
  • <img> element is located within a <figure> element that has a non-empty <figcaption> element, or
  • role attribute is present and has a value of "presentation".

Impact

  • Declares resulting structure invalid, if one of the listed options is not determined.
  • Upholds the structural integrity of <img> element.
  • Enables automatic validators to programmatically detect occurrences of the presence or absence of text alternatives. Bug 8716, Bug 9218.
  • Facilitates accessibility awareness and education.
  • Corrects the spec to disallow <img> to be valid with the email exception Bug 8646.
  • Corrects the spec to disallow <img> to be valid with the title attribute.Bug 7362. Also Bug 9215 (WebCam), Bug 9216 (CAPTCHA).
  • Corrects the spec to disallow <img> to be valid with the generator mechanism. Bug 9212.
  • Strengthens the spec to allow <img> to be valid with aria-labelledby. Bug 6496.
  • Strengthens the spec to allow <img> to be valid with role="presentation" on img. Bug 9214.

References

Detailed Three Year History of the Issue

A detailed three year history of the issue includes issue description, time line, proposed solutions, rationale - pros and cons, research, advice from WAI, use cases, policies/guidelines/law, and email threads:

Related Bugs

Last modified on 5 October 2010, at 19:48