-
Notifications
You must be signed in to change notification settings - Fork 125
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
add note to aria-roledescription #1666
Conversation
closes #1651 adds a note indicating that `aria-roledescription` may not be conveyed depending on the element/AT defaults or user settings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one question! :)
<ol> | ||
<li>The element to which <code>aria-roledescription</code> is applied has a valid <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> role or has an implicit WAI-ARIA role semantic.</li> | ||
<li>The value of <code>aria-roledescription</code> is not empty or does not contain only whitespace characters.</li> | ||
</ol> | ||
<p class="note">Depending on the assistive technology, user verbosity settings, or other factors, certain elements' role descriptions might not be conveyed. If specifying <code>aria-roledescription</code> on such elements, then the custom role descriptions may also not be conveyed by these assistive technologies.</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure, but should the first sentence be: "certain elements' role might not be conveyed" instead of "certain elements' role description might not be conveyed"?
When a AT does communicate the role like "link", we say the "role" is being communicated not the "role description" is being communicated, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was trying to use similar language per James's comment in the original issue](#1651 (comment)). specifically "At low verbosity, most role descriptions (custom or otherwise) should not be spoken at all"
That said, i'm honestly open to either wording. whatever people think is most appropriate
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see! then I'm agnostic too -- so long as @jnurthen thinks it the correct term.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"role description" is used in https://w3c.github.io/aria/#terms
When the button receives focus, assistive technologies may concatenate the platform's role description with the accessible name. For example, a screen reader may speak "push-button OK" or "OK button". The order of concatenation and specifics of the role description (e.g., "button", "push-button", "clickable button") are determined by platform accessibility APIs or assistive technologies.
So I think this is good to go.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this comes across well. 👍
@jnurthen anything else you'd like to see here, or this ok to merge? |
adds a note indicating that `aria-roledescription` may not be conveyed depending on the element/AT defaults or user settings. closes #1651
adds a note indicating that `aria-roledescription` may not be conveyed depending on the element/AT defaults or user settings. closes #1651
closes #1651
adds a note indicating that
aria-roledescription
may not be conveyed depending on the element/AT defaults or user settings.Preview | Diff