Accessibility concerns
-
Hey Phil,
I added your plugin to a site undergoing a full accessibility audit so we could get a definitive list of changes that need to be made to bring it up to par with modern (and legal) standards.
A lot of this is small changes I could submit in a PR, but some of it will require more in depth coding and scripting.
Curious if you were: A) Up to the challenge of making this plugin accessible for web site visitors, and B) open to going through the audit results to make a plan for getting the plugin updated.
Let me know and we can take this to email if desired.
-
@philsbury Here’s a quick rundown from the 3rd party audit. These are all verifiable.
Visible Focus State
All interactive elements must have a visible focus state. If you are providing a custom visible indication of focus, it must reach a 3:1 contrast ratio against the background.The button containing the text “I’m not 21 years old yet” does not receive visible indication of focus.
Dismissing Modal Dialogs
Modal dialogs must trap the keyboard focus (ie. focus must not move out of modals unless the user dismisses/closes it).The 21+ age check modal does not trap keyboard focus.
Design Pattern: Modal
A modal is a window that overlays other content on the page. While a modal is exposed, content outside of it is not operable.Modals need to follow the roles, states & properties, as well as the keyboard interaction requirements, as defined by the ARIA Modal Design Pattern.
This modal is missing aspects of the Modal design pattern.
Remediation Recommendation
Modals must be coded to follow the ARIA Design Pattern specifications:The element that serves as the dialog container needs role=”dialog” and aria-modal=”true”
All elements required to operate the modal must be descendants of the element that has role=”dialog”.
The element with role=”dialog” needs either:
– A value set for the aria-labelledby property that refers to a visible modal title (use this method if there is a visible title for the modal. The value of the aria-labelledby property will be the ID of the element holding the visible label).
– A label specified by aria-label. (Use this method if there is not already a visible label for the modal present. The value of the aria-label property will be the text that you would like to act as a label- it should be descriptive of the modal’s purpose)Optionally, the aria-describedby property can be set on the element with the role=”dialog” to indicate which element or elements in the dialog contain content that describes the primary purpose or message of the dialog. Specifying descriptive elements enables screen readers to announce the description along with the dialog title and initially focused element when the dialog opens.
Some semantic HTML changes, some small CSS tweaks, and a focus trap (lightweight libraries exist you could import).
Happy to help in testing if needed.
Hey @philsbury
Testing the recent changes, appreciate the fast turnaround!
Looks like the only issue I can find is the Esc key on the modal. It removers the focus trap, but doesn’t dismiss the age gate. In practice, I don’t think the age gate should be dismissible with the Esc key since it’s a legal barrier, so if you could prevent the Esc key from unbinding the focus trap, I think that would work best.
escapeDeactivates {boolean} | (e: KeyboardEvent) => boolean): Default: true. If false or returns false, the Escape key will not trigger deactivation of the focus trap. This can be useful if you want to force the user to make a decision instead of allowing an easy way out. Note that if a function is given, it's only called if the ESC key was pressed.
- The topic ‘Accessibility concerns’ is closed to new replies.
