During the first meeting for a website redesign project with my new company, I suggested that accessibility be a priority. The project manager said Great Wendy, take a look at the current site and figure out what we need to do.

The site had more than 1,000 pages. I had no idea where to begin.

Then, I remembered Luke’s checklists. Luke’s series of checklists for the Web Content Accessibility Guidelines (WCAG 2.0) would be the perfect guide.

Use Luke’s WCAG 2.0 Checklists as Your Guide

Luke’s checklists are among the resources I keep within reach, pegged on the wall next to my desk. I turn to them when I’m working on my own projects, and pass them along to others whenever there’s an opportunity to do so.

Not a developer? Neither am I, but anyone can use Luke’s checklists to identify what’s missing and the problems that impact the user experience, even if you don’t know how to fix them.

What’s particularly valuable about the checklists is the association of each guideline with an action — what to do. This makes it easier to evaluate and measure WCAG compliance.

Create a Spreadsheet to Organize Your Assessment

I decided to focus initially on identifying common issues throughout the site. I used Luke’s WCAG A, AA and AAA checklists to create an Excel spreadsheet to record my observations.

From Luke’s checklists, I populated the WCAG level in column A, the guideline in column B, and the action in column C, then added the following column headings:

  • Problem description: a general overview of the problem and how it impacted the user experience;
  • Examples: a description of one to a few examples on the site with links to the pages;
  • Possible solutions: different approaches to address the problem;
  • Best practices: sample sites and solutions to inspire and inform our efforts.

Following the order of Luke’s checklists, I focused on one guideline at a time — this made the accessibility review far less daunting.

For another project that needed a page-by-page assessment, I added column headings for the URL and Page Title, and columns for observations about the content structure, images, alt text, links, and other problems, such as the abundance of PDF links on some pages (a problem because they were not accessible documents).

The spreadsheet is also a shareable and digestible artifact. It’s documentation you can use to explain, discuss or justify the importance of resolving accessibility errors with other team members

Prioritize Your Accessibility Concerns

I ended up with a long list of issues to address, but using the spreadsheet made it easy to identify the concerns sensible to tackle first.

I looked for issues we could resolve ahead of the redesign through simply raising awareness about accessibility and by educating team members. For instance, authors would often use a bold font instead of a heading in long-form content — easy to fix by explaining why they needed to use true headings. I prepared a short presentation that explained best practices for headings, in addition to other solutions for our content concerns.

More complex or technical issues that required planning and more resources were rolled into the project plan, to be considered well ahead of the design and development work.

If you need to perform a review page-by-page, first prioritize the assessment either by section or landing pages, or focus on critical user flows, such as a checkout or registration. The critical problems that limit or inhibit access to your content will reveal themselves.

Get Started

This article is aimed at people who find themselves in a similar situation, working as a team of one or a few, with limited technical expertise.

The spreadsheet is simply a starting point if you are not quite sure where to begin your first accessibility review of your site. Remember too that the spreadsheet is documentation; evidence that helps support the case for ensuring accessibility is a priority with any project.

Even if you are completely new to accessibility, you’ll learn something from the review and take that first step towards creating an inclusive experience for all users.

Free Developer Resources

Join over 3,700 subscribers on my weekly web accessibility email and get free developer resources like WCAG Checklists and special offers.

Powered by ConvertKit

Over 600 developers like you have learned more about the Web Content Accessibility Guidelines with my guidebook.

Learn more >

About Author

Wendy is a Content Strategist and User Experience Writer based in San Francisco, California. She would like to continue the conversation and connect with others who have or are interested in launching an accessibility program at their organization. You can connect with her via LinkedIn at https://www.linkedin.com/in/wendymoltrup.

Leave Comment