-
Notifications
You must be signed in to change notification settings - Fork 375
fix(Modal): remove aria-hidden from siblings when unmounting the component
#9096
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
The component adds the aria-hidden attribute to its siblings when open and removes it when closed. However, if the component is mounted as open but then directly unmounted, its siblings will remain hidden from the accessibility API forever. Thus, the logic for removing these attributes is now also triggered when the component is unmounted.
012dfef to
cc08a57
Compare
|
Preview: https://patternfly-react-pr-9096.surge.sh A11y report: https://patternfly-react-pr-9096-a11y.surge.sh |
daf880f to
4a86c93
Compare
While unmounting the Sidebar is unlikely to happen, it's better to make the component a good citizen by "restoring" its siblings by removing the `inert` and `aria-hidden` attributes. That way, we're minimizing the risk of users being trapped in an issue similar to the one described at patternfly/patternfly-react#9096 Please note that at the time of writing it's not a real restore because the component isn't tracking the status of these attributes BEFORE adding them. However, removing the supposedly added attributes seems enough for now.
|
Hi @dgdavid. Thank you for the contribution. Our repo is code frozen right now and we are working towards a major release of PF. We can take a look at this issue and work on getting your PR in once we open repos again. Q3 is the earliest this would get released. |
When a PF4/Modal is unmounted instead of set as `isOpen={false}`, its
siblings remain as `aria-hidden`. To know more read
patternfly/patternfly-react#9096
When a PF4/Modal is unmounted instead of set as `isOpen={false}`, its
siblings remain as `aria-hidden`. To know more read
patternfly/patternfly-react#9096
When a PF4/Modal is unmounted instead of set as `isOpen={false}`, its
siblings remain as `aria-hidden`. To know more read
patternfly/patternfly-react#9096
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
|
Just for the record, this change was already merged in v5 (current |
It's no longer needed in PatternFly React >= 5.1.1 which merged the patch sent. Read more: * patternfly/patternfly-react#9110 * patternfly/patternfly-react#9096 * https://github.com/patternfly/patternfly-react/releases/tag/v5.1.1
It's no longer needed in PatternFly React >= 5.1.1 which merged the patch sent. Read more: * patternfly/patternfly-react#9110 * patternfly/patternfly-react#9096 * https://github.com/patternfly/patternfly-react/releases/tag/v5.1.1
What
At Agama project, we've found an issue with the
aria-hiddenattributes added by the PatternFly Modal component: some dialogs do not remove them.As far as I can see, this happens to us with open dialogs that are included dynamically. I.e., dialogs that are mounted as open and then simply unmounted instead of closed.
Of course, we should re-evaluate such a use case and stop doing so if we do not have strong reasons for it. However, it looks straight forward and safe to trigger the logic for removing these attributes when the component is unmounted too. I cannot envision a scenario where this would not be convenient
Additional issues
Prior to digging into the problem, I quickly searched the issue list and found #8925. Based on a quick glance at the linked source code, the problem appears to be the same: the MemberModal is unmounted, not closed, so the aria-hidden attributes remain.
Other notes
Just in case it can be useful for someone else doing a first contribution to patternfly/patternfly-react:
Getting the project working locally was a bit challenging to me because neither GETTING-STARTED.md nor the CONTRIBUTING.md helped me to understand the errors related to missing modules/dependencies I got at the beginning when trying either, to build the project and to run the test suite. The Getting Started as a Contributor guide looks outdated too.
Fortunately, I could get some hints about how to move forward from the Maintainer's Guide and the dist CI partial. Summarizing:
npm installyarn installinstead (you might need to installyarnfirst)yarn build && yarn build:umdyarn testFurthermore, I learned how to run a single test in a project using yarn workspaces. In my case, I have used below command from the root of the project
and also I run the linter with