[a11y]: Tabs [dismissible] - unable to dismiss in iPhone

[andreancardona]

Package

@carbon/react

Browser

Safari & iPhone

Package version

@carbon/[email protected]

Automated testing tool and ruleset

Manual QA

Assistive technology

JAWS & VO

Description

"No way of interaction available for VO users to delete A tab in iPhone.

NOTE: In call its understood there is delete icon which helps the visual users to delete the TAB but its not read by Voiceover."

Recommended Fix

Provide Delete Name and Button Role for Delete ICON and make it keyboard operable

When the standard interaction is not possible, user is unable to accomplish A task.

WCAG 2.1 Violation

4.1.2 Name, Role, Value

[alisonjoseph]

Question for @kingtraceyj as I believe you worked on dismissable tabs initially. Or any @carbon-design-system/design that wants to chime in.

Currently the only way to access the delete icon by keyboard is by using the delete key, this obviously doesn't work on phone/tablet devices.

Would you be opposed to moving the delete action into the tab order for keyboard? So a keyboard user would tab to focus the tab, then tab again to focus the delete icon, then if they tab again it would go into the content, or if they pressed the right/left arrows it would switch the tab focus the same way it does now?

[mbgower]

So, I think it's a good idea to flag that there are two different considerations here: discoverability AND operability.

1. how is any screen reader user to know there is a dismissible tab?
2. how is a mobile screen reader to trigger the dismiss function when it is not in the tab order, but instead relies on a dismiss key to activate?

I think the first consideration is discovery. Then, depending on what is communicated to a user, and what methods are available, the second issue may or may not still be valid.

[mbgower]

I have just checked this component with JAWS, and discoverability is a problem for any screen reader user, not just an iOS VocieOver user.

This requirement, IMO, is a larger issue than a user's ability to activate that tab dismissal, which is the focus of PR #16033. Even if a mechanism existed, if the user is unaware of the option, it's meaningless.

There are several ways a dismiss function could be surfaced to a screen reader user. Some of those would also consideration #2 -- how to activate the funciton.

[mbgower]

There seems to be an easy fix to the discoverability problem, BTW. The div containing the tab item has aria-hidden="true" on it. Remove that, and the announcement "Press delete to close tab" is announced by the screen reader.
The svg has aria-hidden set to false, but because it is a child of the div, it is inheriting the hidden attribute.

[alisonjoseph]

@mbgower oh yea, that part seems like something we could easily fix with aria-hidden. That still wouldn't allow a user using voiceover on iphone to dismiss it though, since they don't have a delete key to press?

[mbgower]

That still wouldn't allow a user using voiceover on iphone to dismiss it though, since they don't have a delete key to press?

Yep, agreed, that this idea of the delete key is interesting -- for those iOS VoiceOver users who do not use a bluetooth keyboard. But that's also a consideration beyond just the dismissable tabs. For instance, there are lots of popups that don't have dismiss functions in the tab order, which users close with Esc. On some, a touch user dismisses by clicking outside the overlay. How does a iOS VoiceOver user dismiss those?

iOS VoiceOver also has a slightly different style of navigating than tab order. The chunks of information can be more granular than what we would think of as tab order. In example you can swipe left through chunks of non-interactive information. You can also reach disabled components with VoiceOver, where you cannot with some other forms of navigation.
I wonder if there isn't already a rotor setting that would let me get to navigable chunks of information that are NOT in the tab order but have a -1 tabindex, such as these X mechanisms on dismissible tabs.

[mbgower]

Here's what the ARIA Authoring Practices says in their tabs pattern:

Delete (Optional): If deletion is allowed, deletes (closes) the current tab element and its associated tab panel, sets focus on the tab following the tab that was closed, and optionally activates the newly focused tab. If there is not a tab that followed the tab that was deleted, e.g., the deleted tab was the right-most tab in a left-to-right horizontal tab list, sets focus on and optionally activates the tab that preceded the deleted tab. If the application allows all tabs to be deleted, and the user deletes the last remaining tab in the tab list, the application moves focus to another element that provides a logical work flow. As an alternative to Delete, or in addition to supporting Delete, the delete function is available in a context menu.

They do hold out this concept of a context menu. That may be an avenue to pursue, although frankly iOS through its rotor, could likewise offer a means of issue Esc and other basic key responses. IMO, the attitude of the APG could well be that someone who sets up a keyboardless interaction pattern needs to provide a mechanism for supporting basic established keyboard interaction. In other words, this might be Apple's issue to address.

[mbgower]

I also think it's worth opening an issue against the APG on this and seeing their response, in regard to the Delete key function on mobile-based screen reader without use of a keyboard. I will take that on.

[mbgower]

w3c/aria-practices#2973

[mbgower]

I got a response back form the aria-practices working group

this type of pattern is addressed by the new aria-actions property that should be in ARIA 1.4 and is a 2024 priority for the ARIA WG.
The APG TF is looking for an engineer who wants to be part of the team to build our first example that uses aria-actions. Both this tabs example and tree are strong candidates. Thank you for raising this idea.

You'll note in issue w3c/aria#1805 that there is discussion about exactly how this would be enabled, which ties in with prior comments on how VO might enable this.

What is problematic about it? Users should be able to close a dialog by pressing the escape key (or platform-specific dismiss trigger like VO's scrub), or navigating to a activating the close button, so what's wrong with another way to trigger that?