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

This is a bit of an aside to the tooltip discussion - but should we also 
discuss the ability to associate other message types to a field? My 
primary use-case here is inline error messaging.
Most people are using aria-describedby to associate these but some user 
agents seem to treat aria-describedby as unimportant and delay reading 
this text too long. It would be very helpful to have some sort of 
associated text which could be flagged as important so user agents can 
treat it with appropriate priority.

Regards,
James


On 2/19/2014 11:44 AM, James Craig wrote:
> On Feb 19, 2014, at 6:50 AM, Schnabel, Stefan <stefan.schnabel@sap.com 
> <mailto: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 
>> attributesJ).
>> 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./
>>
>