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

aria-description: Newish attribute is not supported #3121

Closed
tmcconechy opened this issue Aug 16, 2021 · 13 comments · Fixed by #3956
Closed

aria-description: Newish attribute is not supported #3121

tmcconechy opened this issue Aug 16, 2021 · 13 comments · Fixed by #3956
Labels
feat New feature or enhancement pr A pr has been created for the issue rules Issue or false result from an axe-core rule
Milestone

Comments

@tmcconechy
Copy link

Product: axe-core

Expectation:
Using axe jest plugin and and axe scanner in chrome we found out that using aria-description is reported as invalid. But it is in fact a newish valid property.

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Annotations#aria_annotations_features
facebook/react#21035

Actual:
"Invalid ARIA attribute name: aria-description" is reported

Motivation:
Would like to use this new attribute.


axe-core version: 4.12.2
axe-webdriver, extension or other integration version:  4.12.2
@straker
Copy link
Contributor

straker commented Aug 16, 2021

Thanks for the issue. Last we checked aria-description wasn't well supported in most screen readers and browser combinations. However if you wan't to support it you can use axe.configure to allow support of them.

@tmcconechy
Copy link
Author

tmcconechy commented Aug 16, 2021

OK you might have a point about it maybe not working everywhere. But was copying what is used here http://whatsock.com/Templates/Comboboxes/Native%20Inputs,%20Editable%20and%20Readonly/index.htm and it seems to work well.

How would i use axe.configure in the chrome extension?

@straker
Copy link
Contributor

straker commented Aug 16, 2021

In the chrome extension you'll have to be logged into your deqeue account and then you'll get the functionality to configure axe. Otherwise you'd have to use axe-core directly (the JS code) to be able to do it.

@WilcoFiers
Copy link
Contributor

You should use the title attribute.

@tmcconechy
Copy link
Author

The title attribute is used for the tooltip. Im sort of trying to use multiple labels/attached information

@neaumusic
Copy link

My current thinking is that developers should add aria-description even if screen readers and their versions aren't caught up to the specification. TLDR I think throwing an error prevents good context from reaching users who would appreciate it -- the developer chooses between deploying code with or without errors, potentially side-lining end users.

We use the axe-core Chrome Extension and Apple's VoiceOver, which does read the aria-description. Wondering if there could be some sort of support matrix or configuration within the extension similar to caniuse

@tmcconechy
Copy link
Author

I agree @neaumusic - it does work and it does solve our use case. So why not validate against it. Its not incorrect its just newer

@straker
Copy link
Contributor

straker commented Apr 5, 2022

The main problem is that since not all browsers / assistive technologies support aria-description, there will be users that do not get the information. Since we can't say how important that information may be, we can't just allow it to pass. For example, with the following code:

<input type="password" aria-label="password" aria-description="Password requirements: at least 8 characters"/>
  • VoiceOver / Safari - does not announce the aria-description
  • JAWS / IE11 - does not announce the aria-description
  • JAWS / Edge - Announces the aria-description
  • NVDA / FireFox - Announces the aria-description
  • Talkback / Chrome (Android) - Announces the aria-description

This means that using IE11 and Safari, you'd miss the critical information provided by the description. Best we can do is mark it as Needs Review. Right now it looks like it's marked as a violation, so let me see if we have enough support to turn it on with Needs Review.

@WilcoFiers
Copy link
Contributor

The ARIA working group hasn't even put aria-description out in a public working draft yet. It is experimental at best.

@straker straker added the needs discussion More discussion is needed to continue label Apr 14, 2022
@woody-li
Copy link

@straker
Copy link
Contributor

straker commented Sep 12, 2022

@woody-li Thanks for letting us know. We'll add this to the 4.6 milestone.

@straker straker added this to the Axe-core 4.6 milestone Sep 12, 2022
@straker straker added feat New feature or enhancement rules Issue or false result from an axe-core rule and removed needs discussion More discussion is needed to continue labels Sep 12, 2022
@WilcoFiers
Copy link
Contributor

I wrote a proposal on how to address both this, and the aria-braille* props here:
#3899 (comment)

The gist is, yeah we should add them, but we'll need a rule that ensures these aren't used on element without a role or accessible name.

@padmavemulapati
Copy link

Validated with the latest axe-core-develop branch code base,
aria-valid-attr is now allowing the attributes aria-braillelabel and aria-brailleroledescription with these two attributes its passing.

Image

where as in the earlier versions if we keep - aria-braillelabel, aria-brailleroledescription and aria-description attributess
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat New feature or enhancement pr A pr has been created for the issue rules Issue or false result from an axe-core rule
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants