[Vertical Tab Button]: accessibility issues related to the component

[mari-shakhanava]

Case №1

Selected tab does not have accessible state. When User navigates through tabs with launched screen reader, then screen reader does not pronounce state of the selected tab, so it is not clear which tab is active.

Precondition

Screen Reader is ON

Steps to Reproduce

1. Open Vertical Tab Button
2. Using keyboard navigate through tabs
3. Note the announcement.

Actual result

Screen reader does not pronounce the information about which tab is active.
Failed WCAG checkpoint:
4.1.2 Name, Role, Value (Level A)

Expected result

Screen reader should pronounce the information about which tab is active (or selected).

Environment

• UUI version: 5.12.1

Case №2 - out of UUI scope, #2742 (comment)

There is no notification for screen reader about tab with pointer (withNotify={true})

###Precondition

Screen Reader is ON

Steps to Reproduce

1. Open Vertical Tab Button
2. Using keyboard navigate through tabs
3. Note the announcement.

Actual result

Screen reader does not pronounce the information about the 'notification' mark on the tab.

Failed WCAG checkpoint:
4.1.2 Name, Role, Value (Level A)
1.1.1 Non-text Content (Level A)

Expected result

Screen reader should pronounce the information about the 'notification' mark on the tab.

Environment

• UUI version: 5.12.1

[AlekseyManetov]

related to #2525

@mari-shakhanava Thanks for the issue. Did you find any specification or rules about second case? How we should mark tab with notification dot?

[mari-shakhanava]

@AlekseyManetov I couldn't find a specific example in the WCAG specification, but there are two common ways to add screen-reader-only content: using the aria-label attribute or the CSS-based approach.

Here’s an example of using the sr-only class. I think it would be great to pass this text as a prop so that users can get clear information about what this marker specifically means.

[AlekseyManetov]

The .sr-only class feels like a hack to me. It requires adding some text directly to the DOM and then hiding it manually, which could lead unexpected issues and corner cases bugs. I also couldn’t find any evidence that it’s a standard—it seems to come from the Bootstrap framework, and screens readers learns how to handle it. This option feels risky.

The second option, using aria-label, seems like a better solution. However, it should be added on the project side using rawProps={{ 'aria-label': '' }} because the label is specific to the project. It might include more details than just the information about notification dot. Therefore, I think, if you want to improve accessibility in these cases, you’ll need to set the aria-label by yourself, since we doesn’t have any other built-in way to handle this case.

[mari-shakhanava]

The .sr-only approach isn’t a hack—it’s based on a WCAG-recommended technique, though primarily for links. However, I understand your concerns about adding hidden DOM elements, as it might not align with library standards.

I agree that aria-label is a more flexible option, allowing project-specific customization. We’ll proceed with this approach using rawProps={{ 'aria-label': '' }}.

Thanks again!