Bug 7362 - inclusion of the title as a case where the alt may be omitted is problematic
inclusion of the title as a case where the alt may be omitted is problematic
Status: RESOLVED FIXED
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson)
unspecified
All All
: P2 normal
: ---
Assigned To: Ian 'Hixie' Hickson
HTML WG Bugzilla archive list
: a11y, a11ytf, a11y_text-alt, NE, WGDecision
Depends on: 8171
Blocks: 8716
  Show dependency treegraph
 
Reported: 2009-08-18 10:20 UTC by steve faulkner
Modified: 2012-04-20 02:56 UTC (History)
10 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description steve faulkner 2009-08-18 10:20:35 UTC
Inclusion of the title as a case where the alt may be omitted is problematic
why?

1. no user agents that i know of display  title attribute text in a device
independent way, regardless of whether images are enabled or disabled or not
supported. So the title attribute text is only available to users when they mouse over the image place holder (if a placeholder is displayed by the browser)
non mouse users do not have a way of viewing the title attribute content.


2. currently the spec specifically disallows the rendering of the title
content in the same way as alt content or visa versa, so in the case of images beingdisabled it could not be rendered as text content as  the alt is.
"User agents must not present the contents of the alt attribute
in the same way as content of the title  attribute"


therefore recommend removing this
"The title attribute is present and has a non-empty value." from http://dev.w3.org/html5/spec/embedded-content-0.html
Comment 1 Ian 'Hixie' Hickson 2009-09-17 21:56:16 UTC
Why can't browsers improve their behaviour? It seems like whatever we say here, it'd be pretty important for users to be able to find the value of the title="" attribute.
Comment 2 steve faulkner 2009-09-18 05:50:25 UTC
(In reply to comment #1)
> Why can't browsers improve their behaviour? It seems like whatever we say here,
> it'd be pretty important for users to be able to find the value of the title=""
> attribute.
> 

Do you or anybody have any commitment from browser vendors that they will improve the behaviour so that the content of the title attribute will be displayed when images are not? When there is a commitment to implement this from the major browser vendors, feel free to add it into the spec. The cases for when alt can be omitted should not include situations where the text alternative is not displayed when an images are not.
Comment 3 Anne 2009-09-18 08:46:05 UTC
If something is not implemented at the end of the CR period it must removed from the specification so this issue should resolve itself by then.
Comment 4 steve faulkner 2009-09-18 08:58:55 UTC
(In reply to comment #3)
> If something is not implemented at the end of the CR period it must removed
> from the specification so this issue should resolve itself by then.

The issue in question affects what is considered an adequate text alternative in situations when the alt text is not available. I suggest this will be implemented in validators long before CR and before browsers implement the display of the title attribute content in a manner that makes the ommisssion of alt acceptable,until such times and before last call it should be removed so that the spec better reflects real world issues with access to title attribute content.
Comment 5 Anne 2009-09-18 09:09:35 UTC
If you're worried about the validator not matching implementations you should tell the maintainer of the validator to add a warning of some sorts. If we drop the idea of the specification it will not get implemented. The whole point of putting things in the specification is to get them implemented in due course. We cannot just start dropping everything that is not perfectly implemented at this point in time. That makes no sense.
Comment 6 steve faulkner 2009-09-18 09:18:37 UTC
(In reply to comment #5)
> If you're worried about the validator not matching implementations you should
> tell the maintainer of the validator to add a warning of some sorts. If we drop
> the idea of the specification it will not get implemented. The whole point of
> putting things in the specification is to get them implemented in due course.
> We cannot just start dropping everything that is not perfectly implemented at
> this point in time. That makes no sense.

There is nothing in the specification that recommends or even suggests that the title attribute content be rendered in place of an image when it has no alt text and that it not be conditionally displayed in this case dependent on the use of the mouse.

if this was an implementation requirement ie that title attribute content accessible in a device independent manner and that if an image has a title attribute, but the user agent has images disabled or cannot display images the title attribute content will be displayed in text, then i will happily withdraw my objection.

Comment 7 Ian 'Hixie' Hickson 2009-09-19 21:51:17 UTC
The spec says:

"user agents are expected to render an element so that it conveys to the user the meaning that the element represents, as described by this specification"

...and:

"The title attribute represents advisory information for the element".

This is the same requirement that requires <p>s to be visible, or that requires <title> to be conveyed, or that requires alt="" to be visible, for that matter.

Why would it be enough for <p>, <title>, and alt="", but not title=""?
Comment 8 steve faulkner 2009-09-20 08:46:54 UTC
(In reply to comment #7)
> The spec says:
> 
> "user agents are expected to render an element so that it conveys to the user
> the meaning that the element represents, as described by this specification"
> 
> ...and:
> 
> "The title attribute represents advisory information for the element".
> 
> This is the same requirement that requires <p>s to be visible, or that requires
> <title> to be conveyed, or that requires alt="" to be visible, for that matter.
> 
> Why would it be enough for <p>, <title>, and alt="", but not title=""?
> 

what is in the spec in regards to <p> and <title> is irreleveant.

the commonly implemented behaviour in browsers for content contained in an alt attribute is that it is dislayed to users when images are unavailable. This is not so for the title attribute content. therefore it is not suitable as currently implemented in browsers to be considered and alternative for alt text as it is not displayed when images are unavailable.

therefore recommend removing this
"The title attribute is present and has a non-empty value." from
http://dev.w3.org/html5/spec/embedded-content-0.html
Comment 9 Ian 'Hixie' Hickson 2009-09-20 11:29:19 UTC
I agree that today people shouldn't do this, because today most browsers have an accessibility bug in that they don't expose title="" attributes to users who do not have pointing devices.

However, HTML5 requires that the title="" attribute be exposed just like it requires everything else to be exposed, and it makes sense, therefore, to rely on the title="" attribute for giving the title of the image.

Removing the recommendation that the title="" attribute be used in this way would make as much sense as removing _any_ new features in the spec on the grounds that they're not implemented yet. Obviously these features don't work yet, they're new. The spec is not even in "last call" yet. We can't base authoring advice on legacy browsers when writing a spec for future browsers, we have to write the advice based on what we intend the future browsers to be.

I've added a paragraph to the title="" attribute subsection in the rendering section encouraging UAs to provide keyboard access for tooltips.

See also UAAG Guideline 4.1.

If you disagree with this resolution, please escalate this issue to the chairs.
Comment 10 contributor 2009-09-20 11:31:33 UTC
Checked in as WHATWG revision r3919.
Check-in comment: Encourage UAs to make tooltips keyboard-accessible.
http://html5.org/tools/web-apps-tracker?from=3918&to=3919
Comment 11 steve faulkner 2009-09-20 11:52:42 UTC
(In reply to comment #9)
> I agree that today people shouldn't do this, because today most browsers have
> an accessibility bug in that they don't expose title="" attributes to users who
> do not have pointing devices.
> However, HTML5 requires that the title="" attribute be exposed just like it
> requires everything else to be exposed, and it makes sense, therefore, to rely
> on the title="" attribute for giving the title of the image.
> Removing the recommendation that the title="" attribute be used in this way
> would make as much sense as removing _any_ new features in the spec on the
> grounds that they're not implemented yet. Obviously these features don't work
> yet, they're new. The spec is not even in "last call" yet. We can't base
> authoring advice on legacy browsers when writing a spec for future browsers, we
> have to write the advice based on what we intend the future browsers to be.
> I've added a paragraph to the title="" attribute subsection in the rendering
> section encouraging UAs to provide keyboard access for tooltips.
> See also UAAG Guideline 4.1.
> If you disagree with this resolution, please escalate this issue to the chairs.

I do not consider the resolution you have provided to be satisfactory, so will add the issue to the html issue tracker.
Comment 12 steve faulkner 2009-09-20 12:08:51 UTC
(In reply to comment #9)
> I agree that today people shouldn't do this, because today most browsers have
> an accessibility bug in that they don't expose title="" attributes to users who
> do not have pointing devices.
> However, HTML5 requires that the title="" attribute be exposed just like it
> requires everything else to be exposed, and it makes sense, therefore, to rely
> on the title="" attribute for giving the title of the image.
> Removing the recommendation that the title="" attribute be used in this way
> would make as much sense as removing _any_ new features in the spec on the
> grounds that they're not implemented yet. Obviously these features don't work
> yet, they're new. The spec is not even in "last call" yet. We can't base
> authoring advice on legacy browsers when writing a spec for future browsers, we
> have to write the advice based on what we intend the future browsers to be.
> I've added a paragraph to the title="" attribute subsection in the rendering
> section encouraging UAs to provide keyboard access for tooltips.
> See also UAAG Guideline 4.1.
> If you disagree with this resolution, please escalate this issue to the chairs.

created issue in tracker: http://www.w3.org/html/wg/tracker/issues/80
Comment 13 Laura Carlson 2010-02-03 18:17:32 UTC
This bug also relates to an Issue and the Change Proposal: "Replace img guidance for conformance checkers with suggested text"[1] 

Please see the "title Attribute Is Not An Acceptable Text Alternative" section of the Change Proposal.

[1] http://esw.w3.org/topic/HTML/ChangeProposals/ImgElement20090126

References:

Omitting Short Text Alternatives on <img>
http://esw.w3.org/topic/HTML/IssueAltAttribute

HTML TRACKER ISSUE-31
http://www.w3.org/html/wg/tracker/issues/31
Comment 14 Michael Cooper 2010-02-11 17:17:55 UTC
The HTML Accessibility Task Force intends to track these issues, per the proposal at http://lists.w3.org/Archives/Public/public-html-a11y/2010Jan/0245.html.
Comment 15 Maciej Stachowiak 2010-03-14 14:49:42 UTC
This bug predates the HTML Working Group Decision Policy.

If you are satisfied with the resolution of this bug, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
  http://dev.w3.org/html5/decision-policy/decision-policy.html

This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.
Comment 16 Michael[tm] Smith 2010-03-18 15:46:07 UTC
Reopened per discussion on a11y TF telcon 2010-03-18
Comment 17 Maciej Stachowiak 2010-03-18 16:52:42 UTC
Shouldn't be reopened since it's already escalated.
Comment 18 Laura Carlson 2010-03-22 16:23:24 UTC
(In reply to comment #17)
> Shouldn't be reopened since it's already escalated.

Maciej set the status of this bug to VERIFIED FIXED after it was reopened through a misunderstanding of the decision process at the a11y teleconference.

Maciej's rationale is that this bug is already escalated to a tracker issue. VERIFIED with a TrackerIssue keyword is indeed the correct state for a bug that has been "resolved" by the editor but has not yet in fact been decided by the working group via the escalation process. Maciej was correct to move the bug back to VERIFIED. It shouldn't have been REOPENED per HTML working group process.
http://dev.w3.org/html5/decision-policy/decision-policy.html#states-and-keywords

However, it should have been left in the state that it had last been set it to. Ian did not FIX this bug. It is not FIXED. 

Relabeling this bug VERIFIED WONTFIX as that is what the editor had last set it to.
http://lists.w3.org/Archives/Public/public-html-bugzilla/2010Mar/0889.html