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

James,

late replies to your questions (also as preparation for the calls).

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

Well its more about finding out what the *purpose* of the help should be. Is it

- how to *use* a particular type of control with respect to the device options (control help, this is especially important for non-standard UI elements)
- what to *do* with the element content in a given context (content help, leads to potentially huge info that gives a general background)

If we want and need both cases (SAP would need that in complex business UI's, really), then we need even *two* properties differently named.

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.

In any case, reusing @title or arguments like "we have @title" is not the way to go since it requires usage of a different property for the sake of visual display "because it's there", which may be a short-run workaround but not a long-term solution for the use cases given above.

What for instance if authors wants to give control usage instructions for a custom element AND want to use the @title attribute for something different (e.g. explain label abbreviations) AND want to give info/help for the given business context the user is in and about to manipulate with the element? The power of ARIA is that it is also always ahead of the host language when it comes to such cases and we should not limit its power by self-restriction.

Generally it should not be necessary to use AT to retrieve ARIA properties for the end user (notably hidden string-based info like aria-label). How elegant is it solved in Firefox - longdesc location is navigable by context menu - simple. This means additional requirements for user agents in the *UAIG 1.1 spec*, that is, exposing selected ARIA-based info as part of their UI's.  If necessary, I'll add respective action items for the spec.

best regards
Stefan




From: James Craig [mailto:jcraig@apple.com]

Sent: Mittwoch, 19. Februar 2014 20:45
To: Schnabel, Stefan
Cc: W3C WAI Protocols & Formats; Cynthia Shelly
Subject: 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<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 attributes :)).
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.