Request for aria-description to set accessible description

[backwardok]

For the accessible name/label of an element, there is aria-label to set the label directly and aria-labelledby to set it via reference to another node. However, for the description of an element, there is only aria-describedby. This requires providing extra descriptive content in a node elsewhere in the DOM to be referenced by id, even if its only purpose is for the description of another node.

In developing, I've found that there are occasionally extra pieces of information that are visually understood but don't have a complete textual representation that need to be provided to AT users in order for it to make more sense. In order to provide that context, visually hidden nodes get added to the markup to expose them with aria-describedby. However, unless the nodes purely for description are also hidden from AT via aria-hidden or applying hidden CSS like display: none, an AT user will end up coming across that descriptive text separately, and potentially out of context.

An example I've seen of this is on Twitter, where each tweet has a button for reply, retweet, and like. The button also includes the number of replies/retweets/likes there are. In this context, it's important that the button label matches the actual action the button has (reply/retweet/like), but it's also important to expose the information that indicates how many existing interactions there were (replies/retweets/likes). Twitter currently uses aria-describedby with a set of nodes that are all at the beginning of the action section and it confusingly gets read out as text prior to reaching the related buttons.

Some of the benefits I see to having an aria-description attribute:

• Simplification/reduction of the DOM tree (and accessibility tree to some extent)
• Removal of need to create ids on several nodes
• Easier association of the actual description to the node itself
• Relates to an existing ARIA attribute and would therefore be less difficult to support, as a description is already supported for accessibility nodes

[accdc]

Hi, as an FYI in the short term, the title attribute will set the accessible description property, which might be useful in some cases where supplementary information is needed. Of course this will also result in a tooltip for sighted mouse users too though.

[carmacleod]

There's a long thread from 2011 that includes a request for aria-description.
I didn't follow the thread all the way through, but it seems to contain some useful discussion.

[stes-acc]

Using aria-describebdby with hidden extra nodes is already a widely adapted technique giving extra information for screen reader users. Of course it comes with the aforementioned disadvantages creating extra DOM stuff, therefore a property symmetric to aria-label is highly appreciated.

But its score and usage must be clarified.

ACCDC wrote: " Of course this will also result in a tooltip for sighted mouse users too though."

With other words, since both of them will be overriding mapped to accessibleDescription, the APG requirement would be in this case to use the same text both for aria-description and the title attribute?

Or can there be other visible alternatives for sighted users being recommended?

Or should the usage of aria-description being limited to certain information for blind users and therefore NO visual information is needed at all? This could be also a valid use case since aria-label is also "invisible".

Thoughts?

[DavidMacDonald]

There is a way to populate the accessible name with text offscreen using aria-label. How about a corresponding text based attribute that maps to the accessible description?

aria-description OR aria-textdescription

It would allow developers to add helpful notes for screen readers and would help in the following ways:

• overcomes the burden of creating ids and ensuring the id is not a duplicate, and placing the text somewhere else besides on the element,
• overcomes double speak which happens when a screen reader user arrows over a node that is referenced with aria-describedby before encountering the control that references it, where they hear it again.
• will avoid the confusing use of display:none on an node referenced by aria-describedby to overcome the issue in the bullet above.
• overcome accidentally overriding the Accessible Name when devs mistakenly add an aria-label when they want to add some helpful hints. This is a common problem, which might be minimized with the addition of this attribute.

[aleventhal]

PR: #1137

[pkra]

This was resolvd in #1137, cf. https://w3c.github.io/aria/#aria-description

[Wildebrew]

Given that user agent/AT support is widely spread for this attribute already, would it be possible to move it to ARIA 1.2?
It has a lot of practical uses an the accessibility mapping is pretty straight-forward.

[pkra]

Given that user agent/AT support is widely spread for this attribute already, would it be possible to move it to ARIA 1.2?

In a positive sense: hopefully not. ARIA 1.2 just reached Proposed Recommendation and should reach Recommendation status very soon.

1.3 should very quickly go into FPWD thereafter.