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

ChangeProposals/notitlev2

From HTML WG Wiki
Jump to: navigation, search


Change proposal Accepted by Working Group decision Fri, 30 Mar 2012

Reopen "Do not consider the title attribute as a possible conforming source for caption information for an image that lacks a text alternative"

The following Change Proposal relates to: the HTML WG decision on alt validity requirements and Resolve ISSUE-80: Document conformance and device dependent display of title attribute content. Because the above issue is closed, this change proposal applies to ISSUE-192, or may be taken as a reconsideration request for ISSUE-80.

Editor: Steve Faulkner (faulkner.steve@gmail.com)

Date: February 09 2012.


Summary

The title attribute does not fulfill basic user requirements as a substitute for a text alternative in cases where an alt attribute is absent. It therefore should not make an image without an alt attribute conforming.

The title attribute

  • does not convey the semantics of a caption and no mechanism to provide the semantics has been proposed.
  • has a 17 year history of poor accessibility support.
  • as implemented its use results in HTML content that fails recognized accessibility standards.
  • no browser implementors have public plans to improve accessibility support.
  • on touch and mobile devices its content is not displayed to any user.

HTML5 however does provide a new feature (figure/figcaption) that does provide device indendent access to caption content across all user agnets and interfaces, and has already been implemented (in firefox) to provide the appropriate semantics.Its use is currently conforming in cases where an alt attribute is not present and therefore there is no need to allow the use of a vastly inferior mechanism.

Rationale

New information: Browser vendors have not made a commitment to provide (input) device independent access to title attribute content

In the HTML WG Chairs decision on alt validity requirements (in the "Revisiting this Issue" section) it states:

"Evidence that the number of implementations exposing title in an accessible way is decreasing, 
or that some existing implementations are unwilling or unable to expose it in an accessible way."

Below is new evidence:

The requirement to provide

"Evidence that the number of implementations exposing title in an accessible way is decreasing"

It is impossible to fulfill as no graphical browsers provide input device indpendent access to title attribute content, so how is one supposed to show a decrease in a zero current support environment?

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 recent request to browser vendors for information about their intentions to provide device independent access to title attribute content has so far resulted in 4 vendors (Microsoft (mailing list response) and Mozilla (mailing list response) 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 (mailing list response) only made an equivocal statement, citing "company policy":

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

Opera responded (mailing list response) 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.

validation rule implemented

In regards to the implementation of the HTML5 alt validation rules in conformance checkers, the evidence is to the contrary. An implementation is already in place in the W3C Validator so already


<IMG  title=arrow src="/images/choose.jpg">


is not flagged as an error when the HTML5 doctype is used. This puts the cart before the horse, no error is raised even though the suitability of title attribute either as a caption or a substitute when alt is not provided is in dispute and input device independent access to the title attribute content is non existent.

Response to Feedback

feedback from Maciej:

"The evidence presented shows that browser vendors are unwilling to publicly commit to offering more device-independent access to 
the title attribute. It would be more effective to have statements where browser vendors say on the record that they absolutely won't 
implement, or believe it is not possible to do."

It is not a fair bar to set, to expect implementors to absolutely rule out providing input device independent access to title attribute content. Anything is possible, it has never been argued that it not technically possible. What is clear is that they have had 17+ years of opportunity to do so and have not, which shows a lack of will and none of the responses from vendors display any increase in their willingness.

Relevant accessibility standards

The counter proposal cited issues of equality and discrimination in support of allowing the use of title when alt is omitted,which were in turn cited in the decision. If these issues were factors in the decision then the following should also be taken into account: By not providing input device independent access to title attribute content user agents fail:

W3C User Agent Accessibility Guidelines 2.0 PRINCIPLE 2. Ensure that the user interface is operable

"Keyboard Operation: All functionality can be operated via the keyboard using sequential or direct keyboard commands 
that do not require specific timings for individual keystrokes, except where the underlying function requires input 
that depends on the path of the user's movement and not just the endpoints (e.g., free hand drawing). This does not 
forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation. (Level A)" 


Section 508 § 1194.21 Software applications and operating systems.

"(a) When software is designed to run on a system that has a keyboard, product functions shall be 
executable from a keyboard where the function itself or the result of performing a function can be discerned textually."

Browsers on mobile platforms do not display title attribute content

The display of title attribute content in both browsers and OS's has decreased markedly in the last 5 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.

New information: title attribute semantics and usage is ambiguous

In order for the title attribute to be suitable in place of the alt, it's semantics and implementation need provide clear differentiation for the end user, for AT users it does not. All browsers (except Safari on Mac, but the difference in mapping does not equate to the two being differentiated by VoiceOver) treat these 2 cases the same in regards to accessibility API mapping:


example 1
<img src="2421.png" title="Image 640 by 100, filename 'banner.gif'">


example 2
<img src="2421.png" alt="Image 640 by 100, filename 'banner.gif'">

Authoring as in example 2 is non-conforming, authoring as in example 1 is conforming, yet they are presented as the same to users of assistive technology: "graphic, Image 640 by 100, filename 'banner.gif'"

In the cases above both title and alt are mapped to the accessible name property in accessibility APIs, this has always been the case and as there is no practical alternative (most accessibility APIs do not provide properties that differentiate between alt/title attributes when only 1 is present and this will continue to be the case. So for a screen reader user there is no difference in how the two are presented to the user and no differentiation method is suggested or defined.

The only difference in the HTML5 specification are authoring rules about what each attribute can contain, the alt attribute rules are precisely and normativley described, while for the title attribute there are no normative restrictions:

"The title attribute represents advisory information for the element, such as would be appropriate for a tooltip."

Response to feedback

feedback from maciej:

"It would improve the reopen request to explain why the title attribute's "semantics and implementation need provide clear 
differentiation for the end user", and why this is relevant to the decision (as opposed to something that could be filed as a separate bug)."


Why is a distinction important?

A text alternative and a caption have different semantics. The alt is defined to be an alternative representation of a non text object, while a caption is meant to be an adjunct to an image (or other object),it is not meant to replace the image. Users who cannot view an image are not well served by the provision of a caption using an attribute as its role is not and cannot be identified using most current accessibility APIs, unlike an element such as figcaption which can have a clearly defined role assigned ('caption' as defined in a number of accessibility APIs (IA2 & AT-SPI), which provides a clear distinction to the end user that the text is not a replacement for the image.

New information: Most Graphical browsers do not display title text when images are not displayed

the decision did not take into account the negative effects that allowing title without alt will have on users who have images turned off. title should not be considered adequate fallback for alt text if it does not fulfill one of the alt primary functions. On the contrary figcaption text is displayed at all times by default and there will serve as an identifier for images when users have images turned off and no alt text is provided. One of the 2 functions of alt attribute is that its content is displayed when images are turned off or the image src is incorrect.

"the value of the alt attribute provides equivalent content for those who cannot process images or who have image loading disabled."

Results from testing in popular browsers showed that in all browsers except Safari title attribute text is not displayed when a image is missing or not displayed.

Details of support in 2010 for title and alt display on images is available:

Title attribute content is not displayed in Firefox, Internet Explorer or Opera when images are turned off or missing. So title does not fulfill a major requirement of the alt attribute. One browser vendor (Opera) has indicated they have no plans to display title content when images are turned off/missing and have futher indicated they don't think its a good idea for it to be displayed. Refer to the next sections for more details.

New information: decision promotes convergence of alt and title behaviours

In the decision on alt validity requirements (in the "Revisiting this Issue" section) it states:

"One might wonder: since the use cases for omitting alt when title is
specified are described as being served by either title or figcaption,
is it necessary to allow omitting alt in both cases, or only for one
of these constructs? However, both advocates and opponents of these
mechanisms pointed out important and relevant differences in
behavior. In any case, no objection was made on the grounds of
redundancy between these features. Nor was any specific reason given
to pick one or the other. Thus, the use cases for title were not found
to be redundant."

It is not the redundancy between title and figcaption that is an issue, its the title attributes unsuitability as implemented and used that is the issue. From an accessibility standpoint figcaption is a far superior mechanism for providing a caption as it is an element not an attribute. Its text content is visible by default, It can contain:

  • structured content
  • flow content
  • semantics can be added; such as abbreviations, citations, identification of different languages.
  • most importantly the role of figcaption can be identified as having a 'caption' role via accessibility APIs unlike the title attribute.


In response to the citing of information about how title and alt content is displayed in browsers Maciej replied:

"Historically, some older browsers displayed alt text as a tooltip. This led to authors choosing alt text which was 
advisory in nature and suitable for use in a tooltip, rather than alt text which could act as a textual equivalent 
for the image. By this standard, it's not necessarily wrong to show the title text on a missing image when alt is 
missing, though it does seem the letter of the spec would forbid this behavior."

In versions of IE prior to IE8 (and still is in quirks mode in 8/9) alt attribute content is

  1. displayed as a tooltip (when a non-empty title is not present)
  2. exposed as the accessible name property in accesssibility APIs
  3. displayed when the image is not rendered

The behaviour was considered bad because it lead "to authors choosing alt text which was advisory in nature and suitable for use in a tooltip"

as a consequence the HTML5 spec forbids user agents displaying alt attribute content as a tooltip:

"The alt attribute does not represent advisory information. User agents must not present the contents of 
the alt attribute in the same way as content of the title attribute." 

So instead in HTML5 it is now conformant to leave out alt and use the title attribute which is:

  1. displayed as a tooltip
  2. exposed as the accessible name property in accesssibility APIs
  3. displayed when the image is not rendered. (in some browsers)

Maciej went on to say:

"I think the spec requirement should be changed to say something like 'User agents must not present the contents of the alt attribute 
as if they were  advisory information, e.g. as a tooltip.' The requirement as stated seems wrong, because the spec does allow using 
title as a  effectively a textual replacement when alt is not available."


So user agents cannot display alt as a tooltip because it promotes bad authoring behaviour, but authors should now be allowed to use the title attribute to achieve the same result: text that is shown as a tooltip AND in place of an image when it is not rendered AND as the accessible name for the image in APIs.

This convergence will likely lead to authors using title in place of alt, if it covers all the functionality of the alt (as it already does in webkit browser), the alt becomes redundant, we have a difficult enough time getting people to provide alt as it is, without providing an allowable mechanism to achieve the same outcome using the title attribute. Making it non-conforming for authors does not mean that implementors will not be allowed to use it as accessibility fallback.


note: In answer to the question:

"Do any vendors have plans to follow webkit's lead and display the title attribute 
content in place of an image when the image is not rendered?"

Chaals from Opera replied:

"I don't believe we have any such plan (I hope not, too)."

Clarification of decision in regards to the need for 2 mechanisms to provide captions

the decison states:

"One might wonder: since the use cases for omitting alt when title is
specified are described as being served by either title or figcaption,
is it necessary to allow omitting alt in both cases, or only for one
of these constructs? However, both advocates and opponents of these
mechanisms pointed out important and relevant differences in
behavior. In any case, no objection was made on the grounds of
redundancy between these features. Nor was any specific reason given
to pick one or the other. Thus, the use cases for title were not found
to be redundant."

The original change proposal did not consider the question of an alternative (figcaption), the counter proposal only contained the following in reference:

"There are two mechanisms in HTML for
providing titles or captions for an image: the title="" attribute,
which acts on a per-image basis, and the <figcaption> element, which
acts on a per-<figure> basis.

There is nothing in the HTML5 specification that discourages or forbids authors from using the figcaption on a per image basis. The counter proposal provided no reasons for why both are needed to fulfill the edge case described. So it is very difficult to understand how the chairs reached the conclusion that "both advocates and opponents of these mechanisms pointed out important and relevant differences in behavior" which rsulted in the chairs deciding "omitting alt when title is specified was found to serve valid, non-redundant use cases."

Clarification on decision in regards to AT support

the decison stated:

"Since at least one product is known from testing to expose title="" in
an accessible way, and since no evidence was provided that other
products cannot or will not do so, the objection that title is an
inaccessible mechanism was taken to be a weak objection."

Neither the original change proposal or the counter proposal discussed support for title attribute content by AT, it was only mentioned in one poll comment, but it appears that this aspect has been given much weight and had a major effect upon the decision. The original proposal was based on the issue of title content not being input device independent.

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.
    • there is no semantic differentiation between content provided by the title attribute and content provided by the alt attribute on images.
  • Users with fine motor skill impairments.
    • placing the mouse over a link or a button 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

change summary:

Removal of the following (under "Images whose contents are not known"):

<li>The <code title=attr-title><a href="dom.html#the-title-attribute">title</a></code> attribute is present and has a non-empty value.</li>

and (under "4.8.1.1.14 Guidance for conformance checkers"):

<li>The <codetitle=attr-title><a href="dom.html#the-title-attribute">title</a></code> attribute is
present and has a non-empty value (as <a href="#unknown-images">described above</a>).</li>

Impact

Positive Effects

The removal of these conditions pertaining to the presence of the title attribute will reflect the reality that putting content in the title attribute is not a good alternative to use of the alt attribute as the content of the title attribute:

  • not available to keyboard only users
  • has ambiguous semantics for AT users

Conformance Classes Changes

The presence of a title attribute on an img without an alt attribute will no longer be conforming.

Risks

Authors will be required to use an element rather than an attribute to provide captions.

References