This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
HTML5 may need a better way to associate user-friendly help or hints with elements. There are cases where help text or hints should be available to any user, but are not appropriate to present by default to the average user. In some cases (e.g. the pattern attribute) the spec says that the title attribute should be used for this purpose, but the Accessibility Task Force doesn't believe the title attribute should be overloaded in this way. Instead, a new global attribute called hint or helptext should be created for this purpose, or a method analogous to the label element could allow identifying content as the help or hint for a specified element. Issue: How would this be presented to the user? If an element has a title and helptext, do we really want users to have to have two separate mechanisms for getting access to hint and helptext, perhaps two different hotkeys and two different shortcut menu items? This suggests that there's good reason to leave it mingled in with the content of the title attribute. On the other hand, browsers already handle title badly, and it's hard to say whether it would be worse to encourage long title text that some browsers will truncate or to have another thing like title text that they may not handle at all. Issue: Should this be an attribute, and thus limited to a simple text string, or might it be better to define a mechanism that allowed identifying a separate block of content as help for another element, analogous to how the details or label elements already work? That would allow rich, styled content for the help. It would certainly require new UI for displaying and hiding, but that might be no worse than if we merely define a new hint attribute.
mass-move component to LC1
(In reply to comment #0) > HTML5 may need a better way to associate user-friendly help or hints with > elements. > > There are cases where help text or hints should be available to any user, but > are not appropriate to present by default to the average user. What cases? What do you mean by "by default". > In some cases > (e.g. the pattern attribute) the spec says that the title attribute should be > used for this purpose, but the Accessibility Task Force doesn't believe the > title attribute should be overloaded in this way. Why? > Instead, a new global > attribute called hint or helptext should be created for this purpose The name makes it sound like a text that should be available to any user. > , or a > method analogous to the label element could allow identifying content as the > help or hint for a specified element. How would that differ from "aria-describedby"? > Issue: How would this be presented to the user? If an element has a title and > helptext, do we really want users to have to have two separate mechanisms for > getting access to hint and helptext, perhaps two different hotkeys and two > different shortcut menu items? This suggests that there's good reason to leave > it mingled in with the content of the title attribute. On the other hand, > browsers already handle title badly, and it's hard to say whether it would be > worse to encourage long title text that some browsers will truncate or to have > another thing like title text that they may not handle at all. If implementors are not implementing display of long "title" text, why do you think they would do the same thing for a whole new attribute? > Issue: Should this be an attribute, and thus limited to a simple text string, > or might it be better to define a mechanism that allowed identifying a separate > block of content as help for another element, analogous to how the details or > label elements already work? That would allow rich, styled content for the > help. It would certainly require new UI for displaying and hiding, but that > might be no worse than if we merely define a new hint attribute. I think this would be better. Typically, help is given for controls. Can you give an example where some combination of "label", "details", and "aria-describedby" would not already address this use-case?
Greg, this bug is waiting on you to respond to that questions in comment #2
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, 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 Status: Did Not Understand Request Change Description: no spec change Rationale: see comment 3