Proposal for new aria-hint property. (Previously proposed as @aria-help)

[jnurthen]

https://www.w3.org/WAI/ARIA/track/issues/406

aria-hint (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-hint 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-hint may be, "Displays general preferences for the application, such as home page, history, and download preferences."

Authors SHOULD NOT provide a value for aria-hint that duplicates information already provided as all or part of the element's accessible name (label). Authors SHOULD NOT provide a value for @aria-hint if that information is already provided using the host language’s tooltip attribute, such as @title in HTML.

Hint Computation

1. If the element has a non-empty "aria-hint" 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-hint" attribute, (aria-hint=""), user agents will expose no Tooltip/Help value in the accessibility API.
3. If the element has no "aria-hint" 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 hint, 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

[carmacleod]

2 concerns:

1. Isn't this basically the same as aria-describedby, and will just add confusion? Authors would need to know the subtle differences between label, description, hint, title... and how browsers resolve conflicts & render each one.
2. Bigger concern - any time we add something else that isn't visibly rendered, it creates yet another difference between "the AT version of the page" and "the non-AT version of the page", which is an anti-pattern.

[johnfoliot]

I sort-of echo Carolyn's concerns, the difference here seems quite nuanced (i.e., is aria-hint supposed to be rendering an accessible name, an accessible description, or something completely different than that? an accessible 'hint'? does that exist?) Additionally, is there an expectation that browsers will render @aria-hint text strings visually on-screen, similar to @title? (The text *"...**provides complementary tooltip..." *seems to suggest that.) Have the browser vendors signed off on that idea? Or, instead, is the @aria-hint text supposed to be like hidden text that augments visible labels on screen? (See below) Finally, is this really just intended for HTML parity in other host languages that do not have @title or an equivalent? Or is it envisioned to see this frequently in our HTML going forward? Example usage code would be extremely helpful. Would this be correct? (based upon my reading of the draft text): <div class="tab"> <button class="tablinks" onclick="openCity(event, 'London')" aria-hint="London is one of the most diverse cities in the world">London</button> <button class="tablinks" onclick="openCity(event, 'Paris')" aria-hint="Also known as the City of Lights">Paris</button> <button class="tablinks" onclick="openCity(event, 'Tokyo')" aria-hint="The most populated city in the world">Tokyo</button> </div> What is the expected behavior of screen readers here? Are they intended to concatenate the [visible text + hint text] (in that order) to 'augment' the Accessible Name? What happens with the first tab (where "London" is 'repeated' both as on-screen text and in the @aria-hint value)? Is this good practice, bad practice, no impact? (i.e what is the relationship between the hint and the label?) Sorry to be asking so many questions, but this seems quite, erm... unusual. JF

…

On Mon, May 7, 2018 at 4:03 PM, Carolyn MacLeod ***@***.***> wrote: 2 concerns: 1. Isn't this basically the same as aria-describedby, and will just add confusion? Authors would need to know the subtle differences between label, description, hint, title... and how browsers resolve conflicts & render each one. 2. Bigger concern - any time we add something else that isn't visibly rendered, it creates yet another difference between "the AT version of the page" and "the non-AT version of the page", which is an anti-pattern. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#739 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABK-c0OZ5swxi9qQOn2fyPpVFsRp36xYks5twLaLgaJpZM4T1afz> .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com Advancing the mission of digital accessibility and inclusion

[jnurthen]

I appreciate the discussion. As we prepare to leave tracker behind (finally) we are migrating all old issues over. I would not expect to even look at this one until ARIA 1.4 (at least) so I wouldn't spend too much time discussing this right now.

[jnurthen]

lets close this as overcome - it hasn't had discussion in years