-
Notifications
You must be signed in to change notification settings - Fork 794
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
support new aria-braille* properties #3899
Comments
Thanks for raising this. Since there's no support for this yet, the benefit of this will be minimal. I'm curious to see whether AT vendors even end up implementing this at all, since there's a high potential for problems with these. Regarding axe-core though, since these enhance an existing label / description, I see no reason why we couldn't add them, and so maybe encourage some early adoption. That seems fairly harmless to me. I do think we should put some guard rails in place though. It has kind of the same problem I'm inclined to add these, but then add a new rule that ensures these are only used on elements with a role and an accessible name. I think that would work for |
Thanks for the response, @WilcoFiers!
Just for those who don't want to look up the ARIA 1.3 milestone: all major browsers now have support. On the AT side, Orca supports them already. Since this idea came out of a workshop a few years ago where both NVDA and JAWS developers were involved, I'm hopeful they'll get around to it. Apple seems open to the properties as well (e.g., Safari already includes the webkit patches).
That would be great!
Right. A lot of wordsmithing went into warnings in the spec language to generally discourage their use. I'd say the properties are for extraordinary use cases where authors have highly specialized braille requirements (and knowledge), e.g., in education. I think it would not hurt at all if tools like axe would give similarly strong warnings. |
Product
axe-core
Feature Description
The new properties aria-braillelabel and aria-brailleroledescription are on track to be added to ARIA 1.3, see w3c/aria#1331 for additional details.
Basic support (i.e., not flagging them as invalid) would be great to have in time for 1.3.
The text was updated successfully, but these errors were encountered: