I remember when I was younger how I would imagine how different people did different things; a distinct memory I have involved sitting in the car driving down the road and wondering how blind people drove, as the bumps separating the lanes was like brail. But how would they know when to stop I wondered? Well there must be a detector that would let them know they need to stop at a stop sign (I was not good at use cases back then). But how far would the detector need to alert them they are in terms of distance from the stop sign. Three feet would probably do it, which is laughable as an adult. Into my years as an adult I think of this memory often when working on making web applications accessible to all users.

What is accessibility? It can be described as a subset of usability, making the user interface compatible with assistive technologies, and making the web accessible to all users. Essentially equal access for all web users based on the following four criteria: perceive, understand, navigate, and interact. Making a site accessible can be a straightforward challenge, but making a site behave in a way that is audibly perfect across all OS’s, screen readers, and browser combinations is damn near impossible. Instead there are a number of techniques that can be applied in a way that provides a smooth user experience and provide accessibility for all users. The first technique is to know what level of accessibility you will be providing and the second technique is to have a defined test plan that is complete with what browsers and screen readers will be supported.

As for standards that govern accessibility, there are a number of bodies that provide guidance on how a fully accessible experience should cater. For government agencies (and only government), they are bound by Section 508 of the Americans with Disabilities Act. For the rest of us there is the bible for accessibility known as the WCAG (Web Content Accessibility Guidelines). WCAG was created in… due to ….. The WCAG focuses on the areas of Perceivable, Operable, Understandable, and Robust with a three rating levels. The WCAG levels A, AA, and AAA are used to denote where A is, AA is, and AAA is. Presently the Section 508 is undergoing a refresh to align it more with WCAG level AAA, as WCAG 2 provides …..

Accessibility is not a legal requirement for the majority of products, however ethically it is essential to prevent inhibiting inclusion of some users based on simple differences in the way they interact with online products. Benefits, everyone: disabilities, aging population(better navigation, clear content, increased usability), users(improved navigation and non ideal use cases), stakeholders (SEO, market share). As for market segmentation, it is estimated that 1 billion users around the world use assistive technologies.

The biggest concern when thinking about accessibility is how a screen reader will read the content on the screen. Screen readers provide a contextual overview of what the page is, reading aloud as the user navigates through the browser. Jaws, NVDA, ChromeVox, and VoiceOver are screen reader applications. Each screen reader has its own nuances, so it is important to have a firm requirement that will make design, development, testing, and sales more explicit. These screen readers function by rendering the content in specific way which makes using semantic HTML via a lists of links, headings, and ARIA landmarks. A good rule is that all features and functions of a site or web application must function with at least one screen reader.

While proper and semantic HTML is crucial for a strong accessibile experience, there are a set of tags which are used to enhance the non-sighted user experience called WAI-ARIA (Web Accessibility Interactive – Accessible Rich Internet Applications). ARIA tags can be used to better define the experience by providing screen readers with the context and well defined actions.

Automated Tools are a great way to augment manual testing. There are varying levels of these. To do it from within a browser a plugin line HTML CodeSniffer will suffice. For automated testing on a magnitude greater is the npm module pa11y.

Overall accessibility is a big deal, not only to users who rely on it but also the engineers that are ensuring it is baked in from the beginning. By ensuring that the UX caters to all users, we can ensure that what is being crafted is accessible for all.