What is Web Accessability?
Web Accessibility is the process of making your website accessible and removing barriers of use to those with a range of disabilities.
Someone with a disability may use assistive technologies such as a screen reader to access your website if they are visually impaired, or require additional support to consume your content. If your website is not built with accessibility in mind, then they may not have proper access to your website and its content.
Many businesses and services also require a certain standard of accessibility or ADA compliance on their projects. It’s always the right thing to do to develop your website and applications with accessibility from the start. It can also save you countless hours of headaches in the future.
What Is ADA Compliance?
In 1990, the United States first signed into law, the Americans with Disabilities Act (ADA). This civil rights legislation guarantees that people with disabilities have the same opportunities as everyone else. Under Title III of the ADA, it is states that there should be no discrimination on the Basis of Disability in Public Accommodations and Commercial Facilities. Law makers have gone back-and-forth as to if “public accommodation” also extends to websites.
Whatever the law may currently be, there are many reasons to make your websites accessible as well as fully ADA compliant. This includes increasing your target audience to adhering to the business requirements.
The Challenge
Developing a truly accessible and ADA compliant website can be both equal parts rewarding and frustrating. While much of the work is easy to understand and implement, there are other aspects that are more complex and can eat up much of your development time.
Debugging accessibility issues can also become a hassle when you factor in the inconsistencies between different browsers, screen readers, and devices.
There is no truly standardized set-up or collection of tools when getting started with accessibility development and testing but hopefully this outline will give you a good ground to start on when developing your next accessibility-minded project.
Tools
There are numerous tools out there that aid your development when it comes to web accessibility. By utilizing a range of tools and resources, we can be better equipped to build accessible websites:
Browser extensions
Browser extensions such as aXe and WAVE provide us with toolkits that can test your website and its content within your browser. This allows you to visually catch errors and inconsistencies such as missing attributes, color contrast issues, incorrect element structures and so on.
Two of the most popular and useful of these browser extensions are aXe and WAVE which can be downloaded here:
Screen Readers
Visually impaired users often rely on assistive tools such as screen readers, which audibly announce your websites content and controls as they navigate. The two most widely used tools in this case are JAWS and NVDA for desktops, and the built in assistive mobile technologies VoiceOver and Talkback.
For testing screen readers on Desktop, it is recommended you download and use both for your testing purposes:
Note that NVDA is usually used in combination with Firefox and Chrome, as JAWS is generally used with Internet Explorer.
Also note that, when testing accessibility on mobile, both Android and iOS have built in tools specifically for this. These can be found in your settings configuration on your devices.
Pitfalls
JAWS is not yet fully compliant with Edge. Also, screen readers are somewhat inconsistent between browsers. Using NVDA on IE for example, may produce a different result than NVDA on Firefox. This is why it is laid out above to adhere to the combination of NVDA <-> Firefox (or chrome), and JAWS <-> IE.
Aria and Semantic HTML
Utilizing Semantic HTML and logical document structuring in code not only helps with SEO, but greatly improves accessibility on your website. However, this alone will not cover all cases for accessibility. Thats where ARIA comes in.
Accessible Rich Internet Applications (ARIA) is a set of attributes that would be added to your HTML Elements such as links, controls, inputs, and so on to assist assistive technologies such as screen readers.
While this article is not meant to provide you with an introduction to the basics of ARIA (there are plenty of resources out there), you can find more information as well as examples at MDN
Considerations and things to avoid
As stated earlier, the majority of the work devoted to accessibility is simple and straight forward using ARIA attributes, however, you will inevitably run into seemingly unsolvable issues. To avoid this as much as possible, here are a few things that should be avoided or considered early on in your development that can save you headaches in the long-run:
Avoid third-party plugins.
While it can save you time to add in and implement that plugin for that sortable tables or that carousel, is it going to play nice with assistive technologies? The truth of the matter is that most do not, and even those that claim to be accessible, usually do not live up to ADA standards. If at all possible, write all of your components in-house with accessibility in mind and save yourself the trouble and avoid future headaches.
Avoid “non-standard” UI components
Assistive technologies such as screen readers rely on an easily parsable DOM. Adding in a fly-out menu, for example, is not intuitive to screen readers in relation to the page flow. This will inevitably require more code to be written to notify the screen reader of the new state of the application as well as the new flow of standard keyboard controls.
Avoid CSS Generated content
Standard form inputs can be pretty ugly, but think twice before adding in that css ::after content pseudo-element for a custom dropdown icon on a select. In fact, the CSS `content` property is not an accessible DOM element. That means it is not announced by screen readers and we cannot apply an ARIA attribute to it. Currently, mobile voice technologies will treat these as independent, selectable elements, but will not announce it’s purpose which can confuse the visually impaired and those relying on keyboard/motion accessibility.
Avoid placeholder content elements for content population
It is a pretty common pattern in web development to have an empty element such as a `div` that will later be populated by content from an XHR request. However, any empty element on the page will be flagged and reported as non compliant for accessibility.
Avoid Gradient and multi-colored backgrounds
Having multiple colors and shades of a background can cause color contrast issues with the content. Even when it initially passes, a responsive background may reveal that that shade of brown on the lower half of the background does not play well with the black text in the header when the viewport is shrunk.
learn more about color contrasts and accessibility here.
Make use of Media Queries / Mixins
Did you know there are CSS media queries designed specifically for accessibility? Not just for screen readers, but as well as those with vestibular disorders, epilepsy, and migraine and Scotopic sensitivity. You can find more info on MDN.
Also, if you happen to use bootstrap on your project, there is an ‘sr-only’ class which can be utilized specifically for screen reader dictation.
Test early, Test often
Accessibility testing shouldn’t be an afterthought. In fact, if you delay your testing until after your components are fleshed-out, you will most likely face delays and possible refactoring when you inevitably run into accessibility issues. Before completing that pull request, do yourself a favor and utilize the tools above to test your new features.
Conclusion
Accessibility development and testing is necessary if you want to reach as many people as possible. You may find yourself on a new project in which you have to live up to some set of set standards such as a level of ADA compliance. While many of us think of accessibility as an afterthought, the best approach is to start every project with accessibility in mind. This can potentially save you hours of frustration in the future.
Leave a Reply