Change proposal Accepted by Working Group decision Mon, 26 Mar 2012

Replace poor coding example for figure containing multiple images

The following Change Proposal is for the the HTML WG Issue 190 Editor: Steve Faulkner (faulkner.steve@gmail.com)

Date: January 18th, 2012.

Summary

The spec currently includes examples using the title attribute to provide captions for images. This results in caption text not being available to a range of users. The required implementation in browsers to make title attribute content available to all users has not occured in over 12 years and no browser vendor has indicated a commitment to implement. Until such times that interoperable device independent support for title attribute display is on the horizon, examples in the spec should be replaced with more practical real world examples that actually work. There is no downside to removing the examples, only positives for users and authors.

Rationale

Complete lack of support for recommended practice results in inaccessible content

The HTML5 spec currently contains an exampleof use of the title attribute to provide captions for images:

In this example, which could be part of a much larger work discussing a castle, the figure has three images in it.
<figure>
<img src="castle1423.jpeg" title="Etching. Anonymous, ca. 1423."
     alt="The castle has one tower, and a tall wall around it.">
<img src="castle1858.jpeg" title="Oil-based paint on canvas. Maria Towle, 1858."
     alt="The castle now has two towers and two walls.">
<img src="castle1999.jpeg" title="Film photograph. Peter Jankle, 1999."
     alt="The castle lies in ruins, the original tower all that remains in one piece.">
<figcaption>The castle through the ages: 1423, 1858, and 1999 respectively.</figcaption>
</figure>

source

The example is implicit authoring advice, independent of the specification of the figure and figcaption elements in HTML5. It is not a best practice or practical, accessible method, yet it is being used in an illustrative way without caveat. Using the title attribute in this way is an anti-pattern that hides content from keyboard and touch interface users and it advoactes the use of an ambiguous semantic container for plain text only.

Example: for users who can use a mouse the following code:

<img src="castle1999.jpeg" title="Film photograph. Peter Jankle, 1999." alt="The castle lies in ruins, the original tower all that remains in one
piece.">

results in the user having access to the title attribute text "Film photograph. Peter Jankle, 1999."

Users who are not using a mouse or are using most screen readers or using a mobile/touch device simply do not have access to the text or even know it is there.

On the contrary use of the figcaption element for captions provides access to captions for ALL users regardless of OS, input device or ability. Browser are now starting to implement semantics for figure and figcaption. For example in Firefox 11 the following semantics are exposed via accessibility APIs:

figure: role=grouping, IA2 object attribute xml:role figure. accessible relationship to figcaption, type=labelledby.

figcaption: role=caption provides accessible name for figure element.

As a consequence it is suggested that the current example containing poor markup should be replaced with an example containing markup that authors can use now and will be beneficial to a range of users.

Implict recommendation relies on a 12 year old HTML feature with no input device independent user agent support

The implementation of the title attribute in graphical browsers does not provide accessible access to its content. Content is hidden from the user by default and its display is dependendent on the type of input device a user is able to operate. There is no requirement on user agents to provide input device independent access to title attribute content, a request to make it a requirement was rejected.

A request to browser vendors in April 2011, for information about their intentions to provide device independent access to title attribute content has so far resulted in 4 vendors (Microsoft and Mozilla) indicating that they have no plans to do so:

On Wednesday, April 20, 2011 9:04 AM, David Bolter wrote:
No concrete, scheduled, plan at this time.

Adrian Bateman:
Same at Microsoft for IE.

While Apple only made an equivocal statement, citing "company policy":

"Apple does not generally give specific details regarding future product plans."

Opera responded with:

"As Maciej said about Apple, Opera generally doesn't make statements about  
timelines for future development."

So no vendors have indicated any plans to implement device independent access to title attribute content as a feature. No user agents have implementedinput device independent support for the title attribute in the intervening 9 months or indeed in the last 12 years since specced in HTML 4.01.

Browsers on mobile platforms do not display title attribute content to ANY USERS

The display of title attribute content in both browsers and OS's has decreased markedly in the last 6 years due to the increase in mobile browsers and touch interfaces. No mobile browsers are known to display title attribute content.

suggested reasons

• touch interfaces do not lend themselves to the 'incidental behaviour' paradigm that tooltip based disclosure of content relies upon.
• small screens do not work well with tooltips (same issue as for screen magnifier users).
• title attributes are commonly misused providing redundnant content.

Situations in which the the title attribute is not useful due to lack of support

Reference: Using the HTML title attribute

• Displaying information for web content viewed on mobile phone browsers. Typically in desktop browsers title attribute content is displayed as a tooltip. From what I could find, tooltip display is not supported in any mobile browser and alternative visual methods of accessing title attribute content are not provided.
• Providing information for people who cannot use a mouse. Typically in desktop browsers, title attribute content is displayed as a tooltip. Although the tooltip behaviour has been supported for 10+ years, no browser as yet has implemented a practical method to display title attribute content using the keyboard.
• Using it on most HTML elements to provide information for users of a variety of assistive technologies. Access to title attribute information is not supported uniformly by screen readers

User groups not well served by use of the title attribute

• Mobile phone users.
  • title attribute content is not displayed on mobile phone browsers or touch based interfaces.
• Keyboard only users.
  • keyboard users can neither access title attribute content or are aware that it is there.
• Screen magnifier users.
  • The style of tooltips containing title attribute content cannot be modified by authors so that it readable by screen magnifier users. This results in in title attribute content being obscured and unreadable if it is more than a few words long.
• Screen reader users.
  • typically screen reading software only supports the announcing of title attribute content on interactive controls.
• Users with fine motor skill impairments.
  • placing the mouse over a word or phrase to view a tooltip can be difficult.
• Users with cognitive impairments
  • Typically tooltips only appear for a short duration < 5 seconds, some users are unable to read the text in a tooltip in such a short time.

Details

Remove the following spec text from the figure element

In this example, which could be part of a much larger work discussing a castle, the figure has three images in it.
<figure>
<img src="castle1423.jpeg" title="Etching. Anonymous, ca. 1423."
     alt="The castle has one tower, and a tall wall around it.">
<img src="castle1858.jpeg" title="Oil-based paint on canvas. Maria Towle, 1858."
     alt="The castle now has two towers and two walls.">
<img src="castle1999.jpeg" title="Film photograph. Peter Jankle, 1999."
     alt="The castle lies in ruins, the original tower all that remains in one piece.">
<figcaption>The castle through the ages: 1423, 1858, and 1999 respectively.</figcaption>
</figure>

Replace it with:

In this example, which could be part of a much larger work discussing a castle, nested figure elements are used to provide both a group caption and
individual captions for each figure in the group.
<figure>
<figcaption>The castle through the ages: 1423, 1756, and 1966 respectively.</figcaption> 
<figure>
<img src="castle-etching.jpg" alt="The castle has one tower, and a tall wall around it.">
<figcaption>Charcoal on  wood. Anonymous, circa 1423.</figcaption>
</figure>
<figure>
<img src="castle-painting.jpg" alt="The castle now has two towers and two walls.">
<figcaption>Oil-based paint on canvas. Eloisa Faulkner, 1756.</figcaption>
</figure>
<figure>
<img src="castle-fluro.jpg" alt="The castle lies in ruins, the original tower all that remains in one piece.">
<figcaption>Film photograph. <span lang="fr">Séraphin Médéric Mieusement</span>,
1936.</figcaption>
</figure>
</figure>

Impact

Positive Effects

The spec will provide an example of using nested figure elements, where currently it does not.

The example uses markup that adds useful semantic information not provided using the title attribute.

The removal of the title attribute antipattern for captions will mean that spec illustrates a method that is accessible to all users instead of one that is:

• not available to keyboard only users
• typically not available to AT users
• difficult to access for users with fine motor skill impairments
• not available to users of touch and mobile devices

The change would also be more in line with the HTML design principle:

3.2. Priority of Constituencies
In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the
user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more
weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone. Of
course, it is preferred to make things better for multiple constituencies at once. 

As it puts users and authors before specifiers or theoretical purity.

Conformance Classes Changes

none

Negative effects

If at some point in the future, the markup method omitted actually becomes usable in an accessible way, the spec will not reflect this. This is mitigated by the fact that if this situation does arise, the method can be easily added to a future iteration of HTML. Authors

Authors will be encouraged to use more verbose markup for providing captions for images.