ChangeProposals/EnTitle

From HTML WG Wiki
Jump to: navigation, search

Make it REQUIRED for HTML5-compatible user agents to provide default or optional access to title in general, and in particular for the img element whenever alt is omitted

Change Proposal relating to the HTMLwg Decision on alt validity requirements and Resolve ISSUE-80: Document conformance and device dependent display of title attribute content.

Proposed by Leif Halvard Silli


Summary

(New info sections are marked up with "New info:".)

When alt is omitted, then HTML5 currently says that UAs may provide contextual information in response to navigation resulting in access to the content of title or, eventually, the figcaption element. But before it can be permitted that a non-empty title makes an img element conforming, the may must become a must.

Additionally, in order to a) promote that such cases are "kept to an absolute minimum]" and to b) work against the historical confusion of title and alt and to c) make authors aware of many legacy user agent's failure to adequately present img elements where alt has been omitted, HTML5 should recommend conformance checkers to issue a warning whenever advisory content (via figcaption or title) is the only text alternatives for an img element.

Rationale

New info: HTML5 does not make it REQUIRED that UAs make title available whenever alt is omitted

The Decision does not properly discuss the fact that HTML5 does not make it REQUIRED that the content of the title attribute is presented for an img element whose alt is omitted. HTML5 currently states:

If the image is available … snip ….

Otherwise, the user agent … snip … may, if requested by the user, or if so configured, or when required to provide contextual information in response to navigation, provide caption information for the image, derived as follows:
1. If the image has a title attribute whose value is not the empty string, then the value of that attribute is the caption information; abort these steps.

2. If the image is a descendant of a figure element … snip … figcaption … snip …

If the caption is offered via conforming use of the figcaption element, then it will default to be presented for the user anyway, even if the user agent fails to present the caption when the user pokes the img element. Hence a must with regard to user agents is somewhat less of a concern in that case. Whereas for title, then it is often the case that it defaults to be inaccessible whenever the image resource cannot be displayed as well as when mouse navigation is unavailable (such as when using a mobile phone web browser or when operating a desktop browser with the keyboard). Hence HTML5 needs to do a better job in making sure that title actually does get presented.

That said, the must also seems relevant for figcaption: if the img, when graphic display is disabled, becomes inaccessible due to lack of alt and/or due to lack of element dimensions, then it becomes difficult to poke the element for info from title as well as from figcaption.

New info: authors must not rely on alt repair

The Decision failed to discuss that authors are not permitted to rely on alt repair.

WAI-ARIA requires, as a last resort, UAs/ATs to look inside title for a text alternative. Likewise, textual UAs and Webkit based UAs as well as (to some extent) legacy-AT do make use of the title attribute to: 

"repair cases of missing alt attributes"

However, HTML5 nevertherless requires that 

"authors must not rely on such behavior".

Therefore it is inconsistent to honor such content as valid with the justificaiton that some user agents uses title to perform alt repair. Only if it becomes a MUST to present the title in such situations (se above), can alt repair with help of the title attribute be counted in as something that makes the element valid (because, in that case, the repair would only represent a simplified access to something the user nevertheless could give access too).

New info: authors mistakenly or deliberately omitting alt

The Decision asked for: 

"Examples of authors mistakenly or deliberately omitting alt when
 they might have otherwise, due to the generator mechanism exception."

While this was asked in regard to the generator exception, it seem obvious that making it valid to omit alt when title is present, could lead authors to mistakenly or deliberately omit the alt not only - as HTML5 permits - when no alternative text is available and none can be made available, but also because the visual tool-tips in combination with the validity stamp might calm the author to think that everything is optimal. Such confusion can be nourished by the fact that Internet Explorer in quirks-mode displays alt as a tool-tip. This is a reason to make conformance checkers issue a warning or advice whenever alt is omitted.


New info: authoring tools making wide use of the exemption and in a way which interferes with proper inclusion of alt

The decision also asked for: 

"Evidence that a great number of authoring tools are making wide use
 of the generator exemption, and that this interferes with proper
 inclusion of alt. (A list of possible generator values was provided
 in a Change Proposal, but there was no explanation of where it came
 from. Testing of content generators or direct statements of intent
 from implementors would provide sufficient evidence.)"

While this was asked in regard to the generator excemption, it is obvious that authoring tools — for example a photo sharing site, service or programme — could easily, for whichever reason, fill up title with advisory content, which would then make the page validate, and hence cause that the omitted alt to get unnoticed. This is a reason to issue a warning or an advice whenver alt is omitted.


New evidence: exposing title in an accessible way

The decision asked for: 

"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."

This is a not straight forward question to assess. As discussed below, from one angle, increased access to title seems to be the trend. But from another angle, less frequent access to title is also the case in som browser segments. This is a reason to make it a MUST to make title available, so that we steadily move in one, accessible direction, for all HTML5-compatible user agents.

New evidence: Is accessible title exposure decreasing?

The answer depends a little on whether the src attribute resource is displayed or whether its display is disabled.

Whenever display of the src attribute resource is enabled

the general challenge is that title presentation for non-AT users dependends on active interaction from the user, but that many devices by default do not offer users to interact with elements so that they actually can expose it. Examples: key(board) users in general and mobile browsers in particular. For example, the add-ons Vimperator and Pentadactyl, which allows keyboard operating of Firefox in a VIM inspired way, lets users open a link by typing its link text. For image links, they use the alt as link text. But if the image link contains no alt, then Vimperator/Pentadactyl do not provide directly typed access to the image link.

While an AT implementing WAI-ARIA would present title as if it was the alt, even AT would be helped by having keyboard access to title. However, for AT, the benefit of key access is perhaps greater whenever alt is present than when it is not present (because when alt is present, the title might not default to be presented). Nevertheless, the issue at hand is access to title whenever alt is lacking and the src resource is enabled, and only UAs/AT which not fully implement WAI-ARIA fail to give access to title in that case.

It seems to be the case that for the mobile browser platform, then at least VoiceOver+Safari offers non-visual access to title. Information on other ATs for mobile browser has not been provided, but it cannot be assumed that AT access is better on the mobile platform than on the desktop platform - rather it is the opposite.

Whenever display of the src attribute resource is disabled,

including in textual browsers without graphics support, we have yet another situation. Then some UAs are known to use title to perform alt repair. This in theory makes the title accessible to all users even without particular interaction. (Examples of UAs with this behaviour: textual user agents (Lynx/W3m/Links/Elinks) and webkit based user agents.) However, it has to be added that alt text display (including display of repaired alt) in Webkit has tended to depend on the alt text length as well as on CSS.

In other user agents (though it depends on the author's use of CSS), alt omittance when the src resource is disabled/unavailable, can cause the image to more or less disappear (as if it had an alt with the empty string), something which in turn can make it difficult to interact with the title attribute as it is impossible hover above a dimensionless element. (Example: Firefox.) The hover-ability can be solved by giving the element dimension — e.g. via CSS. But even so, Firefox will — by default — not display anything that identifies the element as anything else an empty area.

Oportunity to help user agents to present title

OTOH, due to better support for CSS generated content, and due to what WAI-ARIA's says about how AT may include generated content when computing text alternatives, authors and plug-in makers have some possibilities to repair for these deficits by making title displayed on focus - e.g. check the Key Title extention of Opera's desktop browser. Another option is to use generated content to, upon hover or focus, replace the graphic with its title or alt attribute - this is possible in Safari.

Even Firefox 3 and 4 can display title upon hover or focus, however, in Firefox, this requires that image display is disabled in the first place (which in turn creates other problems). Another uncertainty is whether Firefox currently makes generated content available to AT.

Example: the following CSS replaces the displayed image with title and alt on focus in desktop versions Opera and Webkit (and in Firefox, when image display is disabled):

[title]:focus { content:"";} [title]:focus:before { z-index:1000; position:relative;background-color: lime; content:attr(alt);display:inline-block;margin:1px;padding:1px;} [title]:focus:after { z-index:1000; position:relative;background-color: #ffb; content:attr(title);display:inline-block;margin:1px;padding:1px;}

When it comes to making use of title when images are disabled, then this is - on the surface - a simpler task which is possible for authors to achieve in both Opera, Firefox and Webkit, and in both desktop and mobile browsers. However, authors are lacking a way make sure that the stylesheet only takes effect whenever images are not displayed. (Though, for desktop, a user could make user of user CSS.)

Conclusively: In the desktop browser segment, access to title is increasing rather than descreasing, especially when we count in what author's have the option of doing in order to help browsers. Whereas for the increasingly popular, mouseless mobile browser segment, then :focus CSS and even :hover CSS is known to not have any effect. On the positive side, mobile phones is a platform where turning off image display is rather common, so that title displayed as alt text is theoretically possible to experience. (On iOS, however, the default browser does not offer ability to hide the image.) However since CSS lacks an obvious way to let a stylesheet take effect only when image display is disabled, this seems in reality only possible to experience in mobile browsers which, when alt is lacking, uses title to perform alt repair.

New info: Are vendors willing or unable?

Steve Faulkner recently made a request to browser vendors for information about their intentions to provide device independent access to title attribute content, something which resulted in interesting replies from 4 vendors:

  1. A Mozilla reply indicated willingness and put forward several implementation ideas, but wasn't optimistic about a satisfactorily design and implementation soon. This has to be counted as willingess but a short term inability.
  2. A Microsoft reply concurred with the Mozilla reply.
  3. An Apple reply pointed to VoiceOver's current ability to present title and promised to give consideration to how the experience can be improved when VoiceOver is not in use. This seems to demonstrate both current ability and interest in future improvment. When we look at what is already possible to achive in Webkit via CSS, this seems credible.
  4. An Opera reply on one side joined Apple in not revealing timelines for future development, but OTOH used the occasion to demonstrate Opera's ability to display tool-tips via generated CSS and subsequently releasing a tool-tip extension for Opera. This seems to demonstrate both willingness and ability.

Conclusively: Two vendors demonstrated both willingness and ability. While two vendors demonstrated only willingness - these two vendors are also the ones that could seem to lag the most behind w.r.t. CSS generated content for replaced elements.

New info: HTML5 versus accessibility standards

By not providing input device independent access to title attribute content, a user agent fails to implement:

W3C User Agent Accessibility Guidelines 2.0 (draft) 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."

Conclusively: If title can make an img valid, then HTML5-compatible user agents should be required to provide device independent access to title whenever alt is omitted.

Details

  1. Let the authoring advice which currently says to at least provide a title whenever the author is incapable of providing an alt remain as it is.
  2. Let the section '4.8.1.1.14 Guidance for conformance checkers' state that an omitted alt in combination with non-empty title or a non-empty figcaption should be flagged with a warning message.
  3. When the spec says that 'user agents are encouraged to repair cases of missing alt attributes', add that displaying the title attribute as if it it were the alt attribute is a possible way to repair for lack of alt. By mentioning title in this context, it becomes clear that authors should not rely on this form of repair.
  4. Make it REQUIRED that HTML5-compatible user agents provide device independent access to title whenever alt is omitted by replacing the may with a must in the following statement: "may, if requested by the user, or if so configured, or when required to provide contextual information in response to navigation, provide caption information for the image, derived as follows"
    • Notes:
      1. Any UA which displays title when alt is lacking would fulfil this requirement
      2. Any UA which provides device independent access to the title attribute in general, would fulfil the requirement
  5. Inside the specification of the title attribute, make it REQUIRED that UAs give device independent access to the content of the title attribute.

NOTE: With regard to the suggested MUST language in point 5, then another option could be to move it to HTML5's rendering section. For instance, a CSS based implementation of device indpenden title access could go into that section. The Rendering section uses the term "expected" in the same meaning as "must" for, quote "user agents designated as supporting the suggested default rendering".

Impact

Positive Effects

  • By requiring device inpendent access to title, we make title useful also on other elements, such as abbr element, which in turn would mean that we could avoid current and future disputes about the usefulness of title based on (lack of) technical, devise inpdendent access to it - for instance see Steve Faulkner's warning against using title even for the abbr element. Also, this way we make sure that the user can access the title even when there is an alt.
  • By advicing UAs of the option to use title to user agent vendors (and authors) about possibility of repair for lack of alt via title, we provides better advice about repair.
  • By requiring device inpendent access to title, vendors must work on the issue that IMG elements currently often disappears whenever an alt is unavailable so that it becomes impossible to give them focus. This implies that vendors such as for example Mozilla must work harder with the issue of missing alt repair. Simply put: better access to title implies better access to alt (or to anything else that can represent the image when it isn't dispalayed) as well.
  • By issuing a warning whenever only advisory content is available, authors will get the chance to improve their code instead of being lulled to believe that, because the validator doesn't whine, they have fullfilled the minimum requirement . This is especially important until HTML5 — aka the device independent access required by this change proposal — is fully implemented in user agents.
  • In contrast to another, re-open change proposal, which requires authors to move the advicory content to a figcaption, this change proposal does not require authors to re-author their image presentation.
  • In contrast to another, re-open change proposal, which presupposes that UAs and AT support the figure element and the figcaption element, this change proposal allows authors to use a mechanism which is already supported and described in for instance in WAI-ARIA 1.0.
  • In contrast to another, re-open change proposal, which advices authors to use an implicit way to associate caption content (namely the figcaption element inside the figure element), the title attribtue is explicitly attached to the IMG element. This is sometimes a benefit.
  • By making title device indepently accessible, we avoid that authors has to duplicate content - e.g. inside a hidden element, see Steve's recommendations - in order to be accessible for all.
  • By making it a must to: "provide contextual information in response to navigation"", this change proposal makes sure that not only title but also figcaption can be accessed as contextual information. This is also likely to make it more acceptable (to those of us who are sceptical) that alt may be omitted whenever figcaption is present.
  • Based on the feedback from the vendors, device independent access to title looks like a that requires some implementation planning but which nevertheless is a realistic goal to reach with regard to reaching PR.

Negative effects

  • This CP requires a little bit more whining from the validator, compared with the current situation. However, it requires a warning/accessibility check message rather than a error message, which should be tolerable.
  • Simply changing the may to a must means that presentation of figcaption and title falls under the same requirement - may be it should be seen as separate issues. Unlike for title (where e.g. Charle's Key Title extension for Opera shows a clear example), it is not clear to me what provide contextual information in response to navigation with regard to figcaption, given that the caption is expected to be visible. However, this is probably only a rather minor issue.

Conformance Classes Changes

The presence of a title attribute of — or figcaption for — an IMG without an alt attribute will cause a validator warning.

Risks

  • Be making it even more common to render @title as an @alt, it's possible that authors get confused, like the display of @alt as tool-tip has already been creating confusion. Hopwever, device independent access to @title on :focus — but not to @alt — could work in the opposite direction, by making users and authors see that they work in different ways.
  • Authors will be encouraged (read: warned) if they don't provide @alt but do provide title. This could perhaps have the effect that author uses an empty alt or white-space filled alt etc, to make the validator stop whining. An ARIA supporting AT will still get access to the title, per its Text Alternative Computation algorithm. However, keyboard access users might then be prevented from access, until the state of keyboard access to title improves.
  • If authors are encouraged to use figcaption rather than title, then users might get a better experience since the ement allows author to use mark-up. But OTOH, it is highly likely that when users pok the IMG for information about it its caption, then the caption will be presented as a string of text rather than as rich content.

References

Retrieved from "https://www.w3.org/html/wg/wiki/index.php?title=ChangeProposals/EnTitle&oldid=10728"