Skip to content

Tests/Docs for aria hidden polyfill#725

Merged
devongovett merged 26 commits intomainfrom
tests-for-aria-hidden-polyfill
Jul 14, 2020
Merged

Tests/Docs for aria hidden polyfill#725
devongovett merged 26 commits intomainfrom
tests-for-aria-hidden-polyfill

Conversation

@snowystinger
Copy link
Member

Closes

✅ Pull Request Checklist:

  • Included link to corresponding React Spectrum GitHub Issue.
  • Added/updated unit tests and storybook for this change (for new code or code which already has tests).
  • Filled out test instructions.
  • Updated documentation (if it already exists for this component).
  • Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:

🧢 Your Project:

fix bug where index of 0 wasn't undoing and removing
- Discovered an issue in our DialogTrigger tests where if all tests before `should restore focus to the trigger when the dialog is closed` were commented out, then this test would fail. Discovered because it was the starting point for my tests in aria-modal-polyfill. Issue is that we were getting lucky with some timings. By explicitly running everything we can avoid stuff happening after an `it` clause concludes.
@adobe-bot
Copy link

Build successful! 🎉

@snowystinger snowystinger changed the title Tests for aria hidden polyfill Tests/Docs for aria hidden polyfill Jul 10, 2020
@adobe-bot
Copy link

Build successful! 🎉

@adobe-bot
Copy link

Build successful! 🎉

@devongovett devongovett changed the base branch from master to main July 12, 2020 00:52
@adobe-bot
Copy link

Build successful! 🎉

@adobe-bot
Copy link

Build successful! 🎉

@adobe-bot
Copy link

Build successful! 🎉

@adobe-bot
Copy link

Build successful! 🎉


## Introduction

Certain browser + screen reader combinations do not implement aria-modal correctly, allowing users to navigate outside of the modal.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Certain browser + screen reader combinations do not implement aria-modal correctly, allowing users to navigate outside of the modal.
Certain browser + screen reader combinations do not implement aria-modal correctly, which may unintentionally allow users to navigate outside of the modal.

## Introduction

Certain browser + screen reader combinations do not implement aria-modal correctly, allowing users to navigate outside of the modal.
This watches a container for aria-modal nodes and hides the rest of the dom from screen readers when one is open use the [aria-hidden](https://www.npmjs.com/package/aria-hidden) package.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
This watches a container for aria-modal nodes and hides the rest of the dom from screen readers when one is open use the [aria-hidden](https://www.npmjs.com/package/aria-hidden) package.
`react-aria-modal` watches a container element for `aria-modal` nodes and hides the rest of the dom from screen readers with `aria-hidden` when one is open. See the [aria-hidden](https://www.npmjs.com/package/aria-hidden) package for more details.

maybe also add something about when you'd need to use this? i.e. most of the time you don't need it, only if your app is not mounted at the root of the page.

watchModals();
```

You can also pass it a selector string, by default it will watch body, which is where most applications should have their provider.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
You can also pass it a selector string, by default it will watch body, which is where most applications should have their provider.
By default, `@react-aria/aria-modal-polyfill` watches the document body, but you can also pass it a selector string if your modals are mounted in a different container.

<FunctionAPI function={docs.exports.watchModals} links={docs.links} />

## How to use
Include this once in your application at the top level before modals are rendered.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Include this once in your application at the top level before modals are rendered.
Include `@react-aria/aria-modal-polyfill` once in your application and call `watchModals` before any modals are rendered.

keywords: [dialog, modal, aria]
---

# aria-modal-polyfill
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe make the title watchModals? All the other docs pages have the title be the function/component name but this one has the package name. If you change it, make sure to change the filename of this mdx file too.

*
* If a modal container is removed, then undo the hiding based on the last hide others. Check if there are any other modals still around, and
* hide based on the last one added.
* Acts as a polyfill for 'aria-modal' by watching for added modals and hiding the rest of the tree.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Acts as a polyfill for 'aria-modal' by watching for added modals and hiding the rest of the tree.
* Acts as a polyfill for `aria-modal` by watching for added modals and hiding any surrounding DOM elements with `aria-hidden`.

it('should hide everything except the modal', async () => {
watchModals();
let {getByLabelText, getByRole} = render(
<Provider theme={theme}>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would these tests pass without the watchModals call? Do we need to render something outside the provider? I believe the provider itself will get aria-hidden applied already, without watchModals.

If a dialog does not have a visible title element, an `aria-label` or `aria-labelledby`
prop must be passed instead to identify the element to assistive technology.

`useDialog` applies 'aria-modal' to the modal. This doesn't cover every browser/screen reader combination and should be combined with `@react-aria/aria-modal-polyfill`, see the [Aria Modal Polyfill docs](../react-aria/aria-modal-polyfill.html).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd move this after the last paragraph before the example below which talks about this already.

Suggested change
`useDialog` applies 'aria-modal' to the modal. This doesn't cover every browser/screen reader combination and should be combined with `@react-aria/aria-modal-polyfill`, see the [Aria Modal Polyfill docs](../react-aria/aria-modal-polyfill.html).
**Note:** `useModal` only hides content within parent `OverlayProvider` components. However, if you have additional content in your application outside any `OverlayProvider`, then you should use the `@react-aria/aria-modal-polyfill` package to ensure that this content is hidden while modals are open as well. See the [aria-modal-polyfill docs](../react-aria/aria-modal-polyfill.html) for more information.

Comment on lines 201 to 203
When a Dialog is open, then it should be the only thing that can be interacted with. For the most part this is
handled by aria-modal, however, there are some cases where this is not the case. In order to make aria-modal work
in all cases, we have a package `@react-aria/aria-modal-polyfill`, see the [Aria Modal Polyfill docs](../react-aria/aria-modal-polyfill.html).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
When a Dialog is open, then it should be the only thing that can be interacted with. For the most part this is
handled by aria-modal, however, there are some cases where this is not the case. In order to make aria-modal work
in all cases, we have a package `@react-aria/aria-modal-polyfill`, see the [Aria Modal Polyfill docs](../react-aria/aria-modal-polyfill.html).
When a Dialog is open, then it should be the only thing that can be interacted with. If your application's `Provider` is at the root of the page, this is handled automatically. However, if your application has content outside the `Provider`, then you should use the `@react-aria/aria-modal-polyfill` package to hide this content from assistive technology while a modal is open. See the [aria-modal-polyfll docs](../react-aria/aria-modal-polyfill.html) for more details.

import {triggerPress} from '@react-spectrum/test-utils';
import {watchModals} from '../';

describe('watchModals', () => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we have an example where watchModals is passed a selector?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@snowystinger follow up on this if needed ^


**Note: `useDialog` only handles the dialog itself. It should be combined with other hooks and
components as described below to create a fully accessible modal dialog.**
**Note:** `useModal` only hides content within parent `OverlayProvider` components. However, if you have additional content in your application outside any `OverlayProvider`, then you should use the `@react-aria/aria-modal-polyfill` package to ensure that this content is hidden while modals are open as well. See the [aria-modal-polyfill docs](../react-aria/aria-modal-polyfill.html) for more information.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

parent 'OverlayProvider' components reads weird to me. I'm wondering if you should remove parent or add child.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is hard to describe but I think both Devon and I had a go at explaining this and what Rob has feels like the best of the bunch.

@adobe-bot
Copy link

Build successful! 🎉

@adobe-bot
Copy link

Build successful! 🎉

devongovett
devongovett previously approved these changes Jul 14, 2020
dannify
dannify previously approved these changes Jul 14, 2020
@dannify dannify dismissed stale reviews from devongovett and themself via 776eba5 July 14, 2020 05:07
@adobe-bot
Copy link

Build successful! 🎉

@adobe-bot
Copy link

Build successful! 🎉

@devongovett devongovett merged commit 2148f90 into main Jul 14, 2020
@devongovett devongovett deleted the tests-for-aria-hidden-polyfill branch July 14, 2020 05:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants