A button is clicked, a modal opens, and a form requests more information. A lot of information to parse, but visually, such things are easy: the button has a visual indicator of when it has been pressed: the modal grays out the site as it opens, bringing visual focus to it; and the form has a message in its space so that the context is not lost.
The tricky part comes when accounts for those with disabilities: that button may not account for keyboard presses, the modal may not request screen reader focus when it opens, and the form message may not offer any context for those who cannot see the visual space it's in.
Americans with Disabilities Act (ADA)’s Title III requires that private institutions make accommodations for those with disabilities. Unfortunately, even today, some companies do not ensure their websites are ADA Compliant and end up getting slammed with a lawsuit and a court order to make themselves compliant.
In order to make the internet open to all, the World Wide Web Consortium (W3C) has devised the Web Content Accessibility Guide (WCAG), now in version 2.1, for defining standards such as button size, color contrast), and even number of flashes. The Guide itself is a fantastic resource for understanding both why that standard is there, and how to ensure your site meets it.
There is also the Web Accessibility Initiative - Accessible Rich Internet Applications (WAI-ARIA). This is mainly a suite built by W3C to support our javascript generated HTML with semantic meanings and provide other options for this rich content to improve the experience of users, such as enabling a button to declare that it will launch a pop-up when pressed. That said, it is preferred to use semantic HTML tagging (eg: <h1>, <table>) when available as defined in the very first rule of using ARIA.
Testing our sites to ensure they are accessible is easier than it sounds. Chrome has extensions WAVE and Colorblinding for a quick test of how your site looks to screen readers and color blind users. WAVE itself is a simple press of a button and it will highlight all warnings and errors related to ARIA attributes. Of course, if you want to get our hands dirty, you can always use Freedom Scientific's Job Access With Speech (JAWS, the screen reader that has become the golden standard) to test your website experience first hand, but I encourage that you bear in mind the tools that JAWS gives, including heading level searches, and page scans.
All of these standards and tools come together to at least try to ensure that the web is truly open to all. Pragmatic goals are there, too, of ensuring a customer isn’t turned away from your business by an inaccessible, or worse, barely accessible website. We only scratched the surface, however, and there’s much to consider with a11y. While technology may one day cure many disabilities, they are either a long way away, or viewed as a social problem rather than a medical one (this gets into models of disability, which can easily be a blog post on its own, suffice to say that a11y focuses on the social model). There will always be something new to learn about a11y, and I hope to document further lessons I’ve learned over my a11y journey.
