Top Tips from a Web Accessibility Evaluator at WebAIM

Introduction

I’ve been evaluating websites for accessibility with WebAIM for nearly two years. Evaluating a website can be a daunting task, as there are many components to evaluate: images, color, page structure, and more. Other important aspects to test include keyboard navigation, reflow, and screen reader compatibility.

So, where should you begin? Here are a few things I’ve learned so far in my time as WebAIM’s lead web accessibility evaluator.

Evaluate Piece by Piece

Web pages are typically made up of three distinct regions: the header (which usually contains the navigation region), the main region, and the footer region. The header and footer regions should be consistent across the site. This consistency can be used to simplify the evaluation process: evaluate the header and footer as distinct pieces before moving on to the main region of each page individually. This not only cuts down on evaluation time, but can make a project seem less daunting by identifying repeated sections or widgets on the site.

Search for Patterns

It is rare that web pages throughout a site will have completely unique issues page-to-page. With the exception of complex widgets, which should be evaluated carefully, finding patterns of accessibility issues can help uncover site-wide issues. Do images across multiple pages need alternative text? Does the site’s overall color scheme have insufficient contrast? Asking and answering questions about site-wide patterns can help to address the most significant accessibility issues throughout a website.

Create a Checklist

Just as patterns can help simplify the evaluation process, creating a checklist for a site evaluation can help ensure a more thorough evaluation. 

A checklist can be created page-by-page or on a site-wide basis. For example, if the site being evaluated contains images, create a checklist item for images with sub-items like alternative text (Do all images have alternative text? Does each image on the page have an appropriate alternative text value?) and images of text (Are images of text present on the page? Can images of text be replaced with true text?).

Important accessibility features like reflow and keyboard navigation should be tested on each page being evaluated. A checklist item for keyboard navigation should have sub-items like testing for visual focus indicators, logical focus order, ensuring all interactive elements receive keyboard focus, and confirming no keyboard traps are present.

WebAIM’s WCAG Checklist and Web Accessibility Evaluation Guide provide useful checklists that you can use.

Keep Things Simple

When evaluating a page for accessibility, it is important to remember the first rule of ARIA, which states that if native HTML elements containing the desired semantics and behavior can be used, they should be. For example, often when evaluating a page, I come across complex widgets with various ARIA attributes that could be replaced with a <select> input or the <details> element. Using native HTML not only ensures that screen reader and keyboard users are supported, but also makes the element easier to evaluate and maintain by developers and administrators. For more complex widgets, be sure to refer to the WAI-ARIA Patterns to find examples of common widgets and their accessibility properties.

Be Patient

Evaluating a website for accessibility takes time and is a continuous process. When starting out on an evaluation project, be patient. Some errors may be predictable, but others may be surprises. Ultimately, evaluating and fixing accessibility issues should be prioritized as crucial parts of the ongoing maintenance and development of a site.