AVT 3 - Modal React Component: iOS Focus Trap

[snidersd]

Environment
iOS 12.2
Safari & VoiceOver

Issue:

1. With VoiceOver on, swipe left or right or use the arrow keys in quick nav mode until you find the button to activate the modal.
2. Double-tap on the button to launch the modal.
3. The close modal button will be announced and will have focus.
4. Swipe left and right to explore the modal, you can read the text and focus on the cancel and save buttons.
5. The issue is that navigation is not restricted to the modal only, once it is open there is no way to know if there is an open modal present, the user needs to remember it.

[elizabethsjudd]

@snidersd I'd like to get your opinion on the close button being the first button. In WH we moved the close button to be the last item in the modal because it didn't make sense to us to have the close button first... the user hasn't even read the content and they are focused on the button to close it? We felt having the modal be the first focused item so they were informed of the heading and then could navigate through the modal then they would reach the close button was a more accurate workflow. Thoughts?

[snidersd]

@elizabethsjudd Modal accessibility is not a one size fits all, but I do see that the React Modal Components do not follow the ARIA Authoring Practices Guidelines. It's interesting that the Vanilla Components place the focus correctly, but the React components do not. The default Modal & the passive Modal should have the focus on the Primary button. The Input Modal should have the focus on the first input field in the Modal.

[snidersd]

@dakahn Please add the react label to this issue. Thx!

[snidersd]

@dakahn This issue needs to be added to the IBM Carbon Copy Milestone

[dakahn]

@snidersd getting to this now. Just want to make sure we're testing against the same thing. I'm looking at our transactional modal here.

I'm researching a fix for specifically trapping the screen reader's virtual cursor. Here's the article I'm referencing. Specifically the section "Updates to ARIA and using inert".

It seems to say that aria-modal attribute set to true communicates to screen readers that the virtual cursor should be bound to the modal until it is closed somehow. But it requires there to be a corresponding <dialogue> element.

Looking at our Modal component I see that we have aria-modal="true", but the wrapping element is a <div>. Could this be the problem?

[dakahn]

@snidersd doing further research on this -- it seems like Webkit browsers currently do not support the <dialogue> element. So trapping a screen reader's focus using this technique isn't possible.

From this article by The Paciello Group: The native dialog element, what’s the hold up?:
"Where aria-modal still has some kinks to work out with WebKit, improved inert polyfill support (Google inert or WICG inert) can be paired with aria-hidden="true" on elements outside of a modal dialog to ensure that keyboard focus and screen reader virtual cursors will be less likely to interact with the content obscured by an active modal dialog."

🤔 Not sure how we would implement this feature from the library side though.

ref: Webkit bugzilla issue requesting <dialogue> support
ref: Current browser compatibility for <dialogue>

[stale]

We've marked this issue as stale because there hasn't been any activity for a couple of weeks. If there's no further activity on this issue in the next three days then we'll close it. You can keep the conversation going with just a short comment. Thanks for your contributions.

[dakahn]

Just tested using VoiceOver on Safari in iOS at https://carbondesignsystem.com/components/modal/code and although browser focus was trapped to the modal -- I was able to leave the modal using VoiceOver and focus unseen links for frameworks behind the modal. Reopening for now while I investigate further

If this is specific to the vanilla implementation we can change the ticket title, haven't had a chance to test using the env you describe for react tho @asudoh

@snidersd you had a sandbox where modal was tested, if I'm not mistaken which is how we ended up opening this ticket, right?

[asudoh]

Thanks @dakahn - I can see the issue at https://carbondesignsystem.com/components/modal/code, too.

[asudoh]

Well, tried to access https://carbondesignsystem.com/components/modal/code with my iPhone with VO now, and somehow I can no longer reproduce the issue. I cannot reproduce the issue at the-carbon-components.netlify.com, either. Not sure what may have changed in the website, though.

@dakahn Can you still reproduce the issue?

[dakahn]

I don't have reliable access to ios -- @snidersd can you confirm this for us if you have a chance?

[snidersd]

@dakahn If I test the modal in CodePen https://codepen.io/team/carbon/full/QPNEOv/, I no longer see a failure but testing the modal example at https://carbondesignsystem.com/components/modal/code it fails.

[dakahn]

could be our Story implementation of modal. I'll dig in and report back with whatever I can find 👍

[aledavila]

Tested in iOS 13.3

Website:
When you first open the modal the first item announced is "Primary Button". You cannot see the bottom buttons. They are past the bottom of the page but you can still navigate to them when swiping. However, you can still navigate outside of the modal. When swiping back to the close and you close the modal. The Modal physically closes but for voice over it still thinks it's in the modal on the close button. If you try swiping it just keep repeating 'close modal' and is highlighting where the close button was.

Codepen: You are also still able to navigate outside of the modal and the first item announced is "primary button" however this time you can see the buttons.

@snidersd can you confirm

[snidersd]

@dakahn Looking at the input modal and the transactional modal I'm seeing the same issue as @aledavila, after the close button is pressed the focus is still in the modal. Also when navigating backward, the focus moves out of the modal while it is still open.

[joshblack]

Next steps before starting work (good catch @tw15egan) to verify before starting work:

• Verify issue still exists in iOS 13 and iOS 14

[tw15egan]

Just checking in on this and I was unable to reproduce the issue on iOS 14.4. The focus was trapped correctly inside of the Modal, and when the Modal was closed focus was not retained in the modal content. Is anyone able to test on iOS 13? Otherwise, we can close this issue as resolved.

[dakahn]

It looks like this bug still exists, but has changed somewhat. The trap works backwards, but not forward through the focus ring.

I tried the composed modal one with trigger button and it trapped it at the start of the trap but not at the end

😕

[tw15egan]

No longer able to reproduce running iOS 17.0.1