kensgists
commented
8 years ago W3C Aria best practices and key examples:
- ARIA Authoring Practices: http://www.w3.org/TR/wai-aria-practices/#dialog_modal
- Example 1: http://assets.cms.gov/resources/framework/3.4.1/Pages/#dialog
- Discussion: http://accessibility.oit.ncsu.edu/blog/2015/02/13/the-incredible-accessible-modal-window-version-3/ (this is the last post in a long blog series that handles all of the ins and outs)
For compliance with Web Content Accessibility Guidelines (WCAG)
Keyboard focus management:
Send focus to modal
Ensure that the focus goes to the modal when it is activated. If it's a simple ok/cancel modal, then the focus should go on the ok button. MODx seems to do this well in the places I've looked.
Restrict keyboard access to the modal while it is active:
Ensure users can't tab to links underneath the modal or use a screen reader to access other elements beneath the modal. One technique to accomplish the latter is to set everything underneath the modal to aria-hidden="true". This will not hide it from visual users, but it will make the content unavailable to screen reader users, which is what you want in this case. Use JavaScript to control focus so that keyboard users can't tab forward or backward (shift+tab) out of the modal.
Completely hide inactive modals (and other similar dynamic content):
Ensure the modal is completely hidden from all users, including from screen reader users by using display:none on the element if it is in the DOM already. Be sure to revert it back to display:none at the appropriate time too, after the user or script is done with it. So far I haven't encountered any problems with modals in MODx being read by screen readers when they're inactive, but it's something to watch out for.
From the accessibility guide at https://dequeuniversity.com/modx-accessibility.html#modals
here is a good presentation on what needs to happen for a modal dialog to be accessible: http://www.slideshare.net/maxdesign/accessible-modal-windows.