Title: Accessibility concerns Last modified: October 13, 2021 --- # Accessibility concerns * [Michael Bourne](https://wordpress.org/support/users/michaelbourne/) * (@michaelbourne) * [4 years, 8 months ago](https://wordpress.org/support/topic/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. Viewing 5 replies - 1 through 5 (of 5 total) * Plugin Author [Phil](https://wordpress.org/support/users/philsbury/) * (@philsbury) * [4 years, 7 months ago](https://wordpress.org/support/topic/accessibility-concerns/#post-14986396) * Hi [@michaelbourne](https://wordpress.org/support/users/michaelbourne/), * What are you looking to add? To be honest I expected it to be better than it actually was so have added tab indexing as a minimum in the latest release. * In the rebuild job (that has admittedly stalled a little) there is a method to add to pretty much any of the elements (bar a few that would break things), so thing like aria labels etc will all be possible on an element by element basis. I just need to find the time to finalise all the testing. * Thanks Phil * Thread Starter [Michael Bourne](https://wordpress.org/support/users/michaelbourne/) * (@michaelbourne) * [4 years, 7 months ago](https://wordpress.org/support/topic/accessibility-concerns/#post-14989657) * [@philsbury](https://wordpress.org/support/users/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. - This reply was modified 4 years, 7 months ago by [Michael Bourne](https://wordpress.org/support/users/michaelbourne/). * Plugin Author [Phil](https://wordpress.org/support/users/philsbury/) * (@philsbury) * [4 years, 7 months ago](https://wordpress.org/support/topic/accessibility-concerns/#post-14990048) * Hi [@michaelbourne](https://wordpress.org/support/users/michaelbourne/), * This is really great, thank you. * The first item about focus states I don’t feel necessarily falls into the plugin’s remit as those styles are inherited from the theme so if they’re missing from the age gate they’d probably be missing elsewhere too. * All the others are things I can address, but they aren’t without their challenges as the age gate isn’t always a modal – “standard” mode it’s arguably just _the content_ and there’s also a short code and some other things I’ll need to consider. * The focus trapping is probably going to be the most straight forward so I’ll probably start there! * Cheers Phil * Thread Starter [Michael Bourne](https://wordpress.org/support/users/michaelbourne/) * (@michaelbourne) * [4 years, 7 months ago](https://wordpress.org/support/topic/accessibility-concerns/#post-15005273) * Hey [@philsbury](https://wordpress.org/support/users/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.` - This reply was modified 4 years, 7 months ago by [Michael Bourne](https://wordpress.org/support/users/michaelbourne/). * Plugin Author [Phil](https://wordpress.org/support/users/philsbury/) * (@philsbury) * [4 years, 7 months ago](https://wordpress.org/support/topic/accessibility-concerns/#post-15016647) * Hi [@michaelbourne](https://wordpress.org/support/users/michaelbourne/), * That’s been added in the latest version. There’s also an option to turn it off now should you ever wanted to. * Thanks Phil Viewing 5 replies - 1 through 5 (of 5 total) The topic ‘Accessibility concerns’ is closed to new replies. * ![](https://ps.w.org/age-gate/assets/icon-256x256.png?rev=2783003) * [Age Gate](https://wordpress.org/plugins/age-gate/) * [Frequently Asked Questions](https://wordpress.org/plugins/age-gate/#faq) * [Support Threads](https://wordpress.org/support/plugin/age-gate/) * [Active Topics](https://wordpress.org/support/plugin/age-gate/active/) * [Unresolved Topics](https://wordpress.org/support/plugin/age-gate/unresolved/) * [Reviews](https://wordpress.org/support/plugin/age-gate/reviews/) * 5 replies * 2 participants * Last reply from: [Phil](https://wordpress.org/support/users/philsbury/) * Last activity: [4 years, 7 months ago](https://wordpress.org/support/topic/accessibility-concerns/#post-15016647) * Status: not a support question