Web accessibility has always been important. In recent years, it has become even more talked about within the design and development communities. While previously it was easy to ignore incorporating accessibility into your workflow, now web accessibility has become a requirement, and for good reason. This long history of ignoring web accessibility has unfortunately left us with 97.4% of the Internet failing to meet accessibility standards. This article will cover the first step to cleaning up our accessibility mess: performing an accessibility audit.
Preparing for an Accessibility Audit
Opening a web browser and randomly looking for accessibility issues without a plan can be inefficient, jumping from page to page and bug to bug. This haphazard approach risks overlooking issues on certain pages as you review others. If your website is particularly large, you might find yourself becoming overwhelmed with the prospect of reviewing thousands of pages. Maybe you open the browser and wonder, “What am I even looking for?” Instead, begin by putting a plan in place.
“Failing to plan is planning to fail.”
~ Alan Lakein
Decide What You Are Going to Audit
The first thing you need to perform an accessibility audit is a website to audit. Simple, right? Not so fast. We also need to talk about how much website you need to audit. If your website is small—maybe around 10 pages—then it makes sense to audit all 10 pages. But what if your site is hundreds or thousands of pages? Your full-time job over the next several months would be spent just auditing pages, many of which will be very similar, thus sharing similar bugs. Not very realistic or helpful. Instead, narrow down your focus by focusing on the following types of pages:
Templates: Many pages most likely share different “templates.” A template is a blueprint for a type of page where the content may change but the design and functionality will stay the same. On a blog for instance, all your articles will use the same template and layout while all your category pages will use a separate template. Select a page or two that represents each different template.
High-traffic Pages: Chances are good that your homepage will be a “high-traffic page”–a page that sees a lot of users. You can tap into your Google Analytics to find other pages that your user base most frequently visits. Ensuring these pages are accessible will have a significant impact on a larger number of users.
Critical User Flows: What are people doing on your website? If you have an eCommerce site, you’ll likely want to test the flow of putting an item into the shopping cart and then checking out. Look for the different actions that people need to be able to complete. This might mean testing multiple pages in order. It might also mean that you aren’t testing the entire page in a flow, but focusing instead on the key components needed to complete the flow.
Complexity: Look for any other pages that have complex interactions and features. Components such as carousels, data tables, interactive maps, large forms, multi-level dropdown menus, etc., can pose interesting accessibility issues. If your website has a design system or pattern library, you may want to include complex components that are in these systems as part of your accessibility audit. While testing these components within the context of the page remains important, a pattern library might also encompass various configurations of components.
At this point, you should have a list of pages and user flows that you plan to test that is less overwhelming than the thought of reviewing every single page. If your list is still too large, consider breaking it up into smaller lists and performing multiple audits. Prioritize the pages and user flows that will have the highest impact on user experience.
Know What You’re Looking For
You don’t have to be a pro to perform a basic accessibility audit, but you do need to know the basics in order to know what is considered an accessibility bug. A good place to start is the Web Content Accessibility Guidelines (WCAG). The WCAG specification can be intimidating the first time you try to read it, but once you learn how the content is organized, it’s easier to find the information you need. To help, check out a talk I gave that simplifies WCAG into easily understandable concepts with plenty of examples on how to make different kinds of content accessible. There is also an accompanying resource that presents each guideline and its related criteria in a simple and easy-to-read format that was crucial in aiding my own accessibility certification studies.
Once you have a better understanding of WCAG, having a checklist can be a great way to organize the individual things you need to look for as you test your pages and user flows. The simplest way to get started is to make a list of each WCAG success criteria. As you go through each page and user flow, you will be able to check off the things that page is doing successfully and make note of the things it is not. You don’t have to make your own list however! A number of great resources from folks such as The Accessibility Project and WebAIM are just a Google search away.
Performing the Audit
Start with Automated Tools
There are many automated testing tools available to help you with your accessibility audit. Running these tools is a great way to get started. Many tools, such as Lighthouse and axe, run in the browser on each page that you’re testing. Keep in mind that not all tools are created equal! Sparkbox has done some of the work in evaluating different accessibility testing tools. For an accessibility audit, I would stick with the browser extensions, as they are quicker and easier to get up and running while integrated tools such as Pa11y CI are better for long-term monitoring.
Manual Testing
Automated tests, like those done by browser extensions, will catch obvious or technical accessibility issues but are not enough to catch all issues. They can test to ensure things like alternative text and page titles exist but can’t determine the usefulness of an element’s content. They also cannot interact with a website in the same way that a human can. An out-of-the-box accessibility tool is unable to understand how users will interact with complex components and user flows and then give meaningful feedback. To remedy this, you’ll want to perform a set of manual tests on each page and user flow.
Keyboard Testing
While many people interact with websites by using a mouse or touch screen, there is also a large number of people who can only interact with your website via a keyboard. When you are keyboard testing, you are setting your mouse aside and attempting to interact with your website using only your keyboard. Can you tab through links and buttons on the page? Can you open and close dialog boxes and interactive components? Can you see which elements actively have focus? Is all content on the website accessible without relying on a mouse? If the answer is no to any of these questions, then these are accessibility concerns (video demo of keyboard testing).
Screen-Reader Testing
Screen-reader testing goes hand-in-hand with keyboard testing. The folks who rely on a screen reader to convey information are also likely to rely on a keyboard to navigate the web. The tricky thing with screen-reader testing is that everyone will use the tools available differently. It isn’t reasonable for non-screen reader users to be expected to become experts at all the ways you can use a screen reader for the sake of testing. One of the most important things that a screen-reader tester should know is which screen reader and browser combos to use for testing and how to simply navigate from one piece of content to another.
It’s also good to keep in mind that not every screen-reader user is fully blind. People can use screen readers for a wide variety of reasons ranging from different levels of vision impairment to cognitive disorders such as dyslexia. So it is also important to check that the visual part of the website matches the screen-reader output and make note of any inconsistencies.
Screen reader resources to get you started on your testing journey:
VoiceOver: keyboard shortcuts and video demo
NVDA: keyboard shortcuts and video demo
JAWS: keyboard shortcuts
Recording Your Findings
As you’re performing your accessibility audit, it may be tempting to record accessibility issues directly to a project-tracking system such as Jira. I would recommend waiting until you’re finished with your accessibility audit before creating any cards. My tool of choice for doing this is a simple Google Doc. As you encounter an accessibility issue, create a new heading in the doc that describes the type of issue. Below the heading include the following:
The page(s) where the issue can be found
Details about the issue including how the issue negatively affects people with disabilities
Instructions on how to recreate the issue
Browser or device in which the issue was encountered
Screenshots or screen recordings that show the issue
Any affected Success Criteria (WCAG)
Sample Issues
## Missing focus state in navigation
Keyboard users are unable to see which navigation link is currently active as they tab through the site header.
[VIDEO OF KEYBOARD TEST]
### Steps to Recreate
1. Navigate to any page
2. After the page loads, begin tabbing through the header links
3. As you tab through the navigation links, you cannot see which link actively has focus.
Browser(s): All
Device(s): Desktop
Success Criteria: [2.4.7 Focus Visible](https://www.w3.org/WAI/WCAG21/quickref/#focus-visible)
## Insufficient color contrast for links in dark mode on article pages
All links in the main content area for blog articles do not have sufficient color contrast against the background when viewing the site in dark mode. Links currently have a contrast ratio of 3.5, which is below the minimum of 4.5 for regular sized text.
[SCREENSHOT OF LINK IN DARK MODE]
[SCREENSHOT OF FAILING COLOR CONTRAST IN INSPECTOR]
[SCREENSHOT OF FAILING COLOR CONTRAST at contrast ratio]
### Steps to Recreate
1. Enable dark mode
2. Navigate to an article with links in the main content area
3. Inspect the page to get the background color
4. Inspect the link to get the link text color
5. Compare the colors at contrast-ratio.com
Browser(s): All
Device(s): All
Success Criteria: [1.4.3 Contrast](https://www.w3.org/WAI/WCAG21/quickref/#qr-visual-audio-contrast-contrast)Finding Patterns and Grouping Issues
While performing the audit, record the issues as you come across them. You might find that you have to go back and edit an existing issue with more information if you find it in multiple places, but don’t worry too much about rearranging and combining issues until the audit is complete. When you can see all the issues together, you’ll be able to pick out patterns and better organize issues into tasks.
You might have several issues related to link text that seem like they should all be grouped together, but upon further inspection, some of them are related to the site’s navigation while others are in the footer. It would make sense to create two separate tickets to tackle the two different sections. Or you might find that there are multiple small issues in a sidebar component where it would make sense to tackle them all together as one ticket. When grouping issues, try to keep the scope of the work to be done as small as possible and minimize the number of components or areas of the website that are edited in a single card.
Sharing Your Results
Additional Acceptance Criteria
Depending on your role, you probably won’t be able to make all these fixes on your own. Missing page titles or alternative text for images will need the input of a content creator to determine what that text should be. Color contrast issues will need the help of a designer to determine what the actual colors should be while also following brand guidelines. A form input with a missing label will require a developer to outline how a label should be programmatically linked to the input element. Collaborate with different team members to add any extra details or acceptance criteria to your issues doc.
Prioritizing Issues
Once you have a robust backlog of accessibility tickets, it’s time to start prioritizing. It’s wise to work with a project manager or product owner as you evaluate tickets. I like to start with any issues that popped up because of incorrectly formatted markup. These issues will have a higher chance of affecting all folks, not just those who use assistive technology. Next, I like to prioritize anything that prevents keyboard users from accessing parts of the website. The navigation is often the biggest offender here, and if your navigation is inaccessible, that means people can’t easily navigate to anything except for the page they are currently on. Look for tickets that will improve the website for the largest number of users (high-traffic pages) or will directly impact your company’s business (critical user flows).
Conclusion
Accessibility is an ongoing commitment, and your efforts are helping to make the web a bit more inclusive. Keep in mind that you aren’t going to catch every single issue, especially if you’re just getting started with web accessibility. The ways in which different people with disabilities interact with the Internet and use assistive technology is varied, and we can’t account for every scenario that results in an accessibility issue. As a result, no website can ever be considered 100% accessible, but taking the time to perform an audit and using the results to fill out a Voluntary Product Accessibility Template (VPAT) can demonstrate your commitment to making accessibility improvements.
If you need help improving your website’s accessibility, the folks at Sparkbox are here for you. Our team has a group of certified Web Accessibility Specialists who are ready to help you perform an accessibility audit to build your own backlog of accessibility improvements. With our expertise, we can help identify areas in your workflow that can be adjusted to prevent new accessibility issues from being introduced.
