Re: ISSUE-406: Proposal for new aria-tooltip property. (Previously proposed as @aria-help)

On Feb 19, 2014, at 6:50 AM, Schnabel, Stefan <stefan.schnabel@sap.com> wrote:

> I think that many use cases for aria-tooltip can be covered by supplying the *title* attribute with the same kind of information.
>  
> Best NOT be to develop a concurrent attribute for the HTML *title* attribute before
>  
> -          clarify if we want aria-tooltip as valid alternative/substitute for title attribute. DO WE WANT THAT?
> -          most typical use cases of the title attribute are listed and evaluated
> -          advantages and disadvantages of using title are discussed (e.g. title is rendered on screen, an argument that is taken for alt, although there is no keyboard trigger for title display in most browsers)
> -          the display and communication to AT of title attribute on the various *mobile* applications is clarified
> -          the gaps where an additional aria-tooltip may beneficial are identified
>  
> When we name the thing instead *aria-Xhelp*, we have two options, as I see it (and mentioned it in last call):
>  
> 1.       aria-controlhelp: Denote it to instructions how to *use* a particular type of control e.g. with the keyboard or gestures if usage is not clear from the role of the element. 
> This can be simple string or pointers to object_id’s with more massive content (kind of *aria-controlhelpAt*).
>  
> 2.       aria-contenthelp: give context-sensitive help that exceeds a short tooltip-like info (remember, for short strings we have title attributes J). 
> Then also we will have pointers to object_id’s, something like *aria-contenthelpAt*

I’ll concede your point about the “aria-tooltip” name possibly being to narrow, but do we really need two attributes here? What’s the benefit of these over a single @aria-help?

> In both cases we automatically have the requirement that info is also query-able for non-blind people without AT, a clear ToDo for User Agents (e.g. by exposing the strings or the URL pointers in special dialogs).

You’re implying we should make a UA requirement in the mainstream interface to show this text string by default? I think that already exists, as @title.

> And not to forget, define that UA’s to show title attribute contents also as part of their UI on user request.

I don’t think anyone is recommending to use this over the native attribute where it exists and can be used as intended, but much of ARIA readily admits the fact that authors don’t, won’t, or can’t use the native attribute at times, so we’re allowing them to make it accessible.

James


> Regards
> Stefan
>  
>  
>  
>  
> From: James Craig [mailto:jcraig@apple.com] 
> Sent: Montag, 17. Februar 2014 23:50
> To: W3C WAI Protocols & Formats; Cynthia Shelly
> Subject: ISSUE-406: Proposal for new aria-tooltip property. (Previously proposed as @aria-help)
>  
> From the discussion on this morning’s call regarding @aria-help or @aria-tooltip. Note: If you want to 
>  
> 
> aria-tooltip (property)
> 
> Defines a string value that provides complementary tooltip or help text information for the current element. Also see aria-label.
> 
> The purpose of aria-tooltip is to provide additional information that complements the label text. For example, if the visible label of a tab is "General", the value of aria-help may be, "Displays general preferences for the application, such as home page, history, and download preferences." 
>  
> Authors SHOULD NOT provide a value for aria-tooltip that duplicates information already provided as all or part of the element's accessible name (label). Authors SHOULD NOT provide a value for @aria-tooltip if that information is already provided using the host language’s tooltip attribute, such as @title in HTML.
> 
> 
> Tooltip/Help Computation 
> 
> 1. If the element has a non-empty "aria-tooltip" attribute, user agents will expose the value of that attribute as the Tooltip/Help value in the accessibility API.
> 2. If the element has an explicitly empty "aria-tooltip" attribute, (aria-tooltip=""), user agents will expose no Tooltip/Help value in the accessibility API. 
> 3. If the element has no "aria-tooltip" attribute, but the "aria-describedby" attribute references a single element whose role is "tooltip", user agents must calculate the description using the text alternative algorithm and expose that string as the Tooltip/Help value in the accessibility API. 
> 4. Otherwise, if there is no ARIA-based tooltip, and the element includes the generic tooltip attribute (such as @title in HTML), and if the tooltip attribute has NOT been used in the name computation for the element, user agents MUST expose the value of the tooltip attribute (e.g. @title in HTML) as the Tooltip/Help value in the accessibility API.
> 
> 
> Related Concepts
> 
> Help Tag (Apple Human Interface Guidelines)
> http://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGUsingTechnologies/XHIGUsingTechnologies.html#//apple_ref/doc/uid/TP30000355-TPXREF9
> 
> AXHelp (Apple AX API)
> http://developer.apple.com/mac/library/documentation/Accessibility/Reference/AccessibilityLowlevel/AXAttributeConstants_h/CompositePage.html#//apple_ref/c/macro/kAXHelpAttribute
> 
> Cynthia, please provide a link to the UIA tooltip pattern you mentioned. I’ll add it.
>