Interactivity API: aria-modal is not sufficient to hide content from assistive technology

[afercia]

Description

DIscovered while reviewing #61313

The aria-modal attribute is supposed to hide from assistive technology the rest of the page outside of a 'modal' element. A modal element can be, but not limited to, a dialog.
That is: an element with role-dialog and aria-modal=true.

Unfortunately, aria-modal is not fully supported by Safari and VoiceOver. This was first noted on May 2018 when implementing the Modal component. That's the reason why the Modal component doesn't use aria-modal. Instead, it uses a small helper to hide the rest of the page by setting aria-hidden=true on all the first children of the body except the modal dialog itself (and except live regions and script elements).

The Interactivity API does use aria-modal for the navigation and the image block. Unfortunately, that fails with Safari and VoiceOver. This was probably missed when implementing the modal dialogs for navigation and image but shoudl be remediated with an approach similar to the one used for the Modal component.

It would be great if aria-modal worked as expected but unfortunately it doesn't. Until support improves, WordPress should make sure content outside of any modal dialog is effectively hidden from assistive technologies.

Also, I'd think that having a consistent implementation (in terms of actual behaviro and interaction, not code) between back end and front end is important.

Step-by-step reproduction instructions

Compare the behavior of a Modal component in the editor with the one of the Image 'Expand on click` feature.

Use Safari and VoiceOver.

Modal component:

• Go to the Post editor.
• Navigate to Options > Preferences to open the Preferences modal dialog.
• Tab a few times within the modal dialog.
• Press Control + Option + Left arrow until you reach the main heading of the modal dialog.
• VoiceOver should announce 'Heading level 1, Preferences'.
• Press Shift + Control + Option + Left arrow to move to the modal dialog container.
• VoiceOver should announce 'Preferences, web dialogue'.
• Press Control + Option + Left arrow.
• Observe you can't exit the modal dialog.
• Press Control + Option + U to open the VoiceOver rotor.
• Press Control + Option + Right arrow to navigate the various panels ofd the VoiceOver rotor.
• Observe the various panels list only the content (e.g. Headings, Form controls) that is inside the modal dialog.

This proves all the content outside of the modal dialog is effectively hidden from VoiceOver.

Test the Image 'Click to expand' modal dialog.

• Add an Image block. Click 'Link' in the block toolbar and click 'Expand on click'.
• Publish and view the post on the front end.
• Tab to the image. A button will be revealed on focus. VoiceOver will announce 'Enlarge image, button'.
• Activate the button to open the enlarged image modal dialog.
• Once within the modal dialog, repeat the steps above.
• Observe that you can exit the modal dialog by arrowing away from the modal dialog container.
• When inside the modal dialog, observe the VoiceOver rotor lists also content that is outside of the modal dialog.

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[afercia]

Noting that the Navigation block, when set to open in an overlay, works differently from the Image block lightbox.

The lightbox modal dialog markup is a first children of the body, which makes easy to hide all the other children with aria-hidden=true.

Instead, the navigation block modal dialog markup is nested within the content of the page. This isn't ideal. It would be way better if it was rendered as a first child of the body.

[luisherranz]

@afercia, as this seems to pertain to implementations of the Navigation block and the Image block, and not a direct bug of the Interactivity API, I’m going to change the labels. But feel free to respond if you think this is incorrect.

[afercia]

@luisherranz I have no strong opinions but I'd tend to think that if data-wp-bind-- supports aria-* attributes including aria-modal then it should make sure the implementation works as expected.
Otherwise, setting only aria-modal is incorrect and the API should not allow it.

[luisherranz]

What do you suggest?

[afercia]

I would expect this to work out of the box for developers using the API. A bind data attribute like this:
data-wp-bind--aria-modal="state.ariaModal"
makes the modal dialog have an aria-modal="true" attribute. Unfortunately that's not sufficient to provide the expected behavior. I'm not sure it would be good to delegate the necessary scripting to add aria-hidden=true to the rest of the page to the implementation. Developers / content creators will miss it.

[luisherranz]

What I mean is, could you describe what you think the Interactivity API should do when encountering a directive data-wp-bind--aria-modal? What other elements of the page should it modify? How should it identify those elements?

[afercia]

I tried to describe it in #61944 (comment)

When the element with data-wp-bind--aria-modal is a first children of the body, it would be pretty easy to get all the other first children of the body and hide them from assistive technology with aria-hidden="true". See the modalize / unmodalize / elementShouldBeHidden functions in the modal dialog aria-helper for an implementation example.

Worth noting in #61313 (comment) I suggested to abstract these functions and logic to a generic component that can be used for other components as well because the 'modal' behavior isn't exclusive to modal dialogs.

Instead, when the element with data-wp-bind--aria-modal is not a first children of the body, that is a problem. I'm not sure how to effectively hide the rest of the content from assistive technology in this case.

[luisherranz]

Ok, I understand, now. Thank you 🙂

Should we first manually fix the problem on the Image and Navigation blocks and then think about which abstraction we could build on top of the Interactivity API so that this is done automatically?

[afercia]

It would be great to at least fix the modal 🙂 Not sure what to do with the navigation.

[luisherranz]

Are there already any issues for these two problems with the Image Block and the Navigation Block? If not, could you open them?