There is plenty of buzz surrounding web accessibility, and the internet is packed with information on this topic. When WebAIM conducted [a study of the top 1,000,000 websites, they found a total of 50,829,406 distinct accessibility errors – which is an average of 50.8 errors per page](https://webaim.org/projects/million/#errors). Accessibility testing efforts happen at the end of product development at many but not all companies. Hence, by training developers and prioritizing web accessibility during the development process, the number of accessibility errors can be significantly reduced. ` `

## Understanding Web Accessibility

In the simplest terms, web accessibility means that the web is accessible to those with disabilities. Here is an example to help understand further: Users who are blind typically navigate the computer with the help of a screen-reader, which is a text-to-speech tool that dictates information on the screen to them. When you make your website accessible, the screen reader can successfully deliver that information to the user. If your website is inaccessible, the screen reader delivers inaccurate or incomplete information to the user. In other words, using assistive technologies such as screen readers work well only if the websites they are interacting with are designed with accessibility in mind.

\
The word ‘accessible’ is different from ‘usable.’ A website may be accessible in the sense that it meets the bare minimum for a website to be legally compliant, but it still might not have the most user-friendly experience for people with disabilities. Hence, it is important to at least try going the extra mile to make your website accessible and usable to those with disabilities. We will discuss further in this article how to do so.

\
## Five Ways to Incorporate Accessibility Into Your Website

* **Set up an automated accessibility pipeline.**

  One of the easiest and fastest ways to start embedding accessibility in your application is to follow the philosophy of *Shift left* – which means accessibility testing should start as early as possible in the development process and not wait until the last moment. There are different accessibility checkers out there which can help in setting up automated accessibility testing for your website – ranging from something that you can run manually in your browser to tools that you can integrate into your CI/CD pipeline.

  \
  Free browser extensions include tools such as __[WAVE](https://wave.webaim.org/)__ and __[Accessibility Insights](https://accessibilityinsights.io/)__. Once installed, you can run them anytime on your webpage, and they will show you accessibility errors on your website ranging from missing ARIA labels for your forms to color contrast issues. These tools are a great way to start your automated accessibility journey with. Developers can also use code linters such as __[axe Accessibility Linter](https://marketplace.visualstudio.com/items?itemName=deque-systems.vscode-axe-linter)__ to catch issues as they are coding in your IDE. According to Deque, __[automated tools right now catch 57 percent of accessibility issues compared to the industry's believed rate of 20 percent.](https://www.deque.com/blog/automated-testing-study-identifies-57-percent-of-digital-accessibility-issues/)__

\
* **Learn from your automated accessibility results.**

  You’ve set up automated accessibility testing for your website – that's great. However, are you learning from the accessibility errors being caught? For example – if you’re running into a lot of errors related to missing labels for forms or missing alt text for images – it's important to make sure you do not keep repeating those errors in the future. If you are finding many contrast issues on your website, it might be a good idea to talk to your design team to evaluate your website’s colors and themes.

  \
  Another way to ensure that you’re not repeating simple accessibility mistakes is through code reviews – make sure to look for inaccessible code during code reviews! Some easy ones to spot are missing ARIA labels for elements that have no clear visible label, missing alt-text for images, and missing page titles. Using automated testing tools is great, but its efficiency can be improved further if you preemptively fix the issues it is commonly catching.

  \
* **Keyboard Navigation + Screen Reader Testing**

  If you want to go a step further than automated accessibility testing – make sure to test your website using a keyboard. All interactive elements must be accessible via tab keys, and elements such as dropdown menus should be accessible via arrow keys. More information on appropriate keystrokes for various UI elements can be found here: <https://webaim.org/techniques/keyboard/>

  \
  If you find that something is not accessible via keyboard, ask yourself: Is this supposed to be accessible? Elements such as a static table cell do not need to be accessible via a keyboard. If it is a custom interactive element required to be accessible via keyboard and it is not, you will need to programmatically make it accessible. This can be done by adding a tabindex of 0, which will add the element to the web page’s tab order, and then defining event handlers such as “onKeyPress,” which will invoke the necessary action on a key press.

  \
  For example, this code snippet adds a tabIndex of 0 to the button element, making it focusable and accessible via keyboard. The event handler listens for the "keydown" event and triggers a click on the button if the Enter key is pressed.

  \
  `<button id="myButton">Click me</button> `

  ` `

  `const button = document.getElementById("myButton"); `

  `button.tabIndex = 0; `

  `  `

  `button.addEventListener("keydown", function(event) { `

  `  if (event.key === "Enter") { `

  `    button.click(); `

  `  } `

  `});`

  \
  If you want to go a step further, try using a screen reader to test your website. This could be a good idea if your website doesn’t go through any third-party final accessibility vendor for manual testing. You do not need to perform detailed screen-reader testing as a developer, but you can try navigating the website with a screen reader. Check for things such as whether appropriate labels for form elements are announced, if any redundant information is being conveyed, if information in a table is accessible, etc.

  \
  Windows Narrator and Voiceover for Mac are good options for free screen readers. Screen readers synchronize with the usual keyboard navigation commands but additionally have specific commands to navigate various elements of a website. For example, for VoiceOver, you can look up those commands here: __<https://dequeuniversity.com/screenreaders/voiceover-keyboard-shortcuts>__.

  \
* **Get familiar with some accessibility debugging tools.**

  Tools such as the Browser Accessibility Tree can help you look at the accessibility states and properties of UI elements on your website. This tool is especially useful for fixing accessibility bugs, as it can show you what accessibility properties are being exposed to assistive technologies such as a screen reader. To see the Accessibility tree in Google Chrome, open Devtools on your browser and click on the Accessibility Pane. This should be next to the Layout Pane.

  \
  Learn more about Accessibility Tree here: <https://developer.chrome.com/blog/full-accessibility-tree/#what-is-the-accessibility-tree>

  \
  Another useful tool you can use is [Paul’s bookmarklets ](https://www.pauljadam.com/bookmarklets.html)which also highlight roles, states, and properties of elements. This also works on mobile phones. Both tools are helpful for knowing what information is being passed to assistive technologies and hence are extremely useful in fixing any bugs.

  \
* **Account for a variety of other disabilities**

  In addition to screen-reader and keyboard testing, which can help those who are blind or with motor disabilities, you should also consider accommodating the needs of people with other disabilities. If your website has videos, make sure to include accurate captions on them. For people with cognitive disabilities, WCAG has a [great guide](https://www.w3.org/TR/coga-usable/) on how to make content accessible for them. Consider other disabilities such as colorblindness as well. TPGi’s Color Contrast Analyzer has a [Color Blindness Simulator](https://www.tpgi.com/color-contrast-checker/), which can be an excellent tool to make sure your website is using accessible colors and themes.

  \
  Finally, if your website has custom speech-to-text functionality, ensure it is accessible to someone with speech disabilities. One way to do so can be to provide reasonable time for those with speech disorders to finish what they have to say.

\
## Conclusion

Digital accessibility is important so that the one billion disabled people on this planet can have equitable access to the web. Looking at the current state of digital accessibility – we may not be doing great. According to a __[recent report by UsableNet](https://info.usablenet.com/thank-you-2022-end-of-year-report-on-digital-accessibility-lawsuits?utm_campaign=2022%20Year%20End%20Report&utm_source=linkedin&utm_medium=social&utm_content=plain%20text%20and%20pdf%20access)__, “2022 marked another year of more than 4,000 \[accessibility\] lawsuits.” Using some of the strategies outlined above, developers can embed accessibility in the development process and catch and fix as many errors as possible before someone has a frustrating experience.

Read My Stories

Too Long; Didn't Read

Web Development & Ecommerce Writing Contest

Building a Better Web: A Guide to Accessibility for Developers

Too Long; Didn't Read

@meenakshidas

RELATED STORIES