Closed Gesh4o closed 1 year ago
This is an interesting one. The order in the DOM is fine (don't get mislead by the IDs numbers). But in the A11Y tree it's bugged:
The A11Y tree is managed by the browser. Not sure why it does not get updated, but semantically, our tabs are organized as list element items (LI) inside an Unordered list (UL). So it can't be unexpected that they don't keep track of the order.
Maybe we can try changing the UL to something else.
@AmyLiNow Amy, does the A11Y team have any observations on similar cases, or comments about my thoughts on the Unordered list?
Hi @Jinnie this is working as intended by the ARIA implementation. The issue here is what the reporter @Gesh4o pointed out in the screenshot, which is the order in aria-owns attribute value (aria-owns="clr-tab-link-0 clr-tab-link-1 clr-tab-link-2"
) does not reflect the intended reading order because it is out of order in the tablist id's (clr-tab-link-0
,clr-tab-link-2
, and then clr-tab-link-1
). So the screen reader will read the last 2 out of order due to how it is listed (I've confirmed with screen reader on the stackblitz by removing aria-owns in the DOM).
Additionally, aria-owns should never be used when the DOM order already reflects the intended reading order.
The solution here is to remove aria-owns completely and let the natural DOM order dictate the reading order for assistive technologies, you can see also that W3C Manual Tab Example doesn't use aria-owns
either.
If you like to learn more, this MDN aria-owns article does a great job explaining aria-owns attribute.
Hope this helps!
It helped a lot, thanks. PR is ready.
:tada: This issue has been resolved in version 13.11.3 :tada:
The release is available on:
v13.11.3
Your semantic-release bot :package::rocket:
Hi there 👋, this is an automated message. To help Clarity keep track of discussions, we automatically lock closed issues after 14 days. Please look for another open issue or open a new issue with updated details and reference this one as necessary.
Describe the bug
When using clarity tabs alongside structural directives like
*ngIf
the order in which they are announced by the screen reader will be messed up:Example:
Expected order announced by screen reader: Organization - 1/3 Recommended - 2/3 All - 3/3
Actual: Organization - 1/3 All - 2/3 <--- wrong Recommended - 3/3 <--- wrong
This issue was originally logged under VPAT-16650 (in internal vmware JIRA).
How to reproduce
Steps to reproduce the behavior:
Notes
My understanding of the problem is that:
*ngIf
and it will be scheduled for rendering after all the other tabs andaria-owns
attribute that is used internally for theul
element.Versions
Clarity version:
Framework version: ie: Angular 14
Device:
Additional notes
Add any other notes about the problem here.