Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request for aria-description to set accessible description #891

Open
backwardok opened this issue Jan 24, 2019 · 5 comments
Open

Request for aria-description to set accessible description #891

backwardok opened this issue Jan 24, 2019 · 5 comments

Comments

@backwardok
Copy link

@backwardok backwardok commented Jan 24, 2019

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
@jnurthen jnurthen added this to the ARIA 1.3 milestone Jan 24, 2019
@accdc

This comment has been minimized.

Copy link

@accdc accdc commented Jan 25, 2019

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

This comment has been minimized.

Copy link
Contributor

@carmacleod carmacleod commented Feb 19, 2019

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

This comment has been minimized.

Copy link

@stes-acc stes-acc commented Mar 29, 2019

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

This comment has been minimized.

Copy link

@DavidMacDonald DavidMacDonald commented Jun 4, 2019

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.
@jnurthen jnurthen moved this from Needs triage to High priority in Issues related to ARIA Annotations feature Nov 14, 2019
aleventhal added a commit that referenced this issue Dec 11, 2019
Closes issue #891
aleventhal added a commit that referenced this issue Dec 11, 2019
Closes issue #891
@aleventhal

This comment has been minimized.

Copy link
Contributor

@aleventhal aleventhal commented Dec 19, 2019

PR: #1137

aleventhal added a commit that referenced this issue Jan 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
7 participants
You can’t perform that action at this time.