ChangeProposals/notitle annotations

From HTML WG Wiki
< ChangeProposals
Revision as of 09:20, 4 April 2012 by Sfaulkne (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


Change proposal Accepted by Working Group decision Tue, 20 Mar 2012

Advice in spec about annotations promotes inaccessible content

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

Date: January 13th, 2012.


Summary

The section 4.13.5 Footnotes http://dev.w3.org/html5/spec/Overview.html#footnotes of the HTML5 specification recommends the use of a markup antipattern that makes it impossible for some user groups and very difficult for some other user groups to know of the presence or access footnote content. It advocates the use of the title attribute, yet historically and currently title attribute content is not available to a range of users. there is no indication from implementors that this is likely to change.


Rationale

Complete lack of support for recommended practice results in inaccessible content

The HTML5 spec currently recommends to HTML developers to use the title attribute as a method to mark up short footnotes:

HTML does not have a dedicated mechanism for marking up footnotes. Here are the recommended alternatives.
For short inline annotations, the title attribute should be used.

source

It is authoring advice, independent of the specification of the title attribute in HTML5. It is not provided to illustrate the use of the title attribute as specified in HTML5. It is not a best practice or practical, accessible method, yet it is being recommeded without caveat.

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

<span title="Colloquial pronunciation of 'What do you'">Watcha</span>

results in the user having access to the text "Watcha" and the title attribute text "Colloquial proninciation of 'What do you'"

For users who are not using a mouse or are using a screen reader or using a mobile/touch device all they get is "Watcha".

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 4.13.5 Footnotes

"For short inline annotations, the title attribute should be used.

In this example, two parts of a dialogue are annotated with footnote-like content using the title attribute.

<p> <b>Customer</b>: Hello! I wish to register a complaint. Hello. Miss?
<p> <b>Shopkeeper</b>: <span title="Colloquial pronunciation of 'What do you'">Watcha</span> mean, miss?
<p> <b>Customer</b>: Uh, I'm sorry, I have a cold. I wish to make a complaint.
<p> <b>Shopkeeper</b>: Sorry, <span title="This is, of course, a lie.">we're
closing for lunch</span>."

Modify the following spec text from 4.13.5 Footnotes by removing the word "longer":

For longer annotations, the a element should be used, pointing to an element later in the document

Impact

Positive Effects

The removal of the title attribute antipattern for footnotes will mean that spec recommends 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

Risks

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.