What Accessibility Audits Actually Look Like

It can be easy to fixate on accessibility as something you must do. After all, most governments around the world have requirements that you are legally required to meet. But fundamentally, that compliance isn’t the reason accessibility matters. 

When your website isn’t accessible, users who would like to interact with it simply won’t be able to. Lack of accessibility causes those users pain.

Like other efforts that span multiple teams, accessibility can be a struggle for enterprises. The scope feels massive and impacts every team involved with your website, from the developers to the content creators, to the designers, to the legal and compliance teams. 

Who owns accessibility when it touches every team in your organization? How are the right expectations set so that each team addresses their part of the problem on a timeline that also considers all the other deadlines already committed?

When you treat an accessibility audit as a one-off event, you don’t bake accessibility into the DNA of your content operation. Everyone will rally around a big push, and the next time you do an audit, you will find many of the same issues all over again. 

A better approach is to start with an audit and use it to evolve your organization into one that embeds accessibility at every stage of your content operation, ensuring every new page, article/post, and update is audited before publication.

What an accessibility audit includes

Web Content Accessibility Guidelines (WCAG) are the internationally recognized standard for making your website accessible. The standards were developed by the W3C’s Web Accessibility Initiative and have gradually evolved over time.

Most accessibility audits start by using automated testing tools to identify gaps between your website and page structures and the WCAG-defined expectations. The best automation tools catch 30-40% of WCAG issues, which means you also need to look at manual testing.

If you want to truly understand a user’s lived experience of engaging with your site, manual testing is essential. Manual testing is best performed by considering personas who use assistive technologies to engage with your content.  

Some examples include:

• Keyboard navigation testing will help you understand the experience of navigating your website without the use of a mouse or touch screen.
• Screen reader testing highlights instances where your website may not perform well when read aloud by assistive technology. Some commonly used screen readers include TalkBack for Android, VoiceOver for both macOS and iOS, and JAWS for Windows.
• Zoom level testing uncovers gaps when some content isn’t correctly magnified for low-vision users. This can be tested by using the zoom function built into the browser and increasing the size to 200% or greater.
• Focus order testing will highlight instances where a user isn’t correctly moved through a sequence of steps, like filling out a check out form while using keyboard navigation. This can be tested by attempting to fill out a form by using only your keyboard.

This WordPress VIP webinar discusses assistive technologies in depth. If you want external users to test your website with assistive technology, companies like Fable provide user experience testing by people who use assistive technology every day.

The content on your pages isn’t the only place you need to check these tools. If you have a chatbot on your pages, you need to understand how it performs for each persona. It’s also vital that compliance-mandated elements, like a cookie banner for EU and California users, be accessible in addition to the underlying content.

To get a clear picture of how assistive technologies perform, expand personas to include popular browsers combined with a technology. For example, maybe you test keyboard navigation in Safari and Chrome.

It’s also important to consider content-level checks for aspects that improve accessibility. Headings, links, the use of alt text on images, table construction, and the availability of captions on video all play a role in how accessible your content is to users.

Design and interaction patterns can also improve or impede accessibility. WCAG offers guidelines on design specific components including: 

• Color contrast between the text on the page and the page background.
• Responsive layouts that adapt depending on the screen size being used.

The output of both the automated and manual checks should be a checklist of issues identified. If you use WordPress VIP, there are accessibility plugins like Equalize Digital Accessibility Checker that can provide a list of issues for you to review.

Who’s involved in an enterprise accessibility audit

Auditing your website for accessibility is everyone’s job within your organization.

• Internal accessibility champions are often at the frontline of accessibility efforts, helping align the organization around why accessibility matters beyond compliance. 
• Engineering and front-end teams will be on the lookout for code-level issues and ways to resolve them. 
• Content and editorial stakeholders will need to evaluate best practices for creating accessible content.
• Design and UX teams will be on the lookout for factors such as color contrast and how individual users navigate a site.
• Legal, compliance, and risk teams will need to be involved to understand the current state of your accessibility efforts and identify where the company may be most at risk for non-compliance, while also balancing other legal and compliance risks mandated by law.
• External auditors can be useful in organizing a thorough accessibility audit. They are also useful in gathering and sharing findings with the broader org. 

Audit outputs: findings, severity, and remediation plans

A completed audit typically breaks issues down into categories and severity levels. WCAG defines three levels of compliance:

• A: Addresses critical barriers like keyboard navigation, image ALT text. Without these bare minimums, users with disabilities have the equivalent of no access to your site.
• AA: Covers common issues like WCAG-compliant contrast ratios and consistent navigation. AA is the level required for most legal regulations throughout the world.
• AAA: Goes beyond the recommended support included in AA to introduce things like sign language support in videos, consistently compliant color contrast, and full support for keyboard-only navigation.

When issues are discovered, they are typically categorized in three buckets:

• Critical: These issues block a user from completing a task.
• Serious: These issues make it difficult for users to complete tasks, but completion is still possible.
• Minor: These issues may be annoying to a user, but don’t impede task completion.

Once your initial audit is complete, you need to look at how to fix those issues. Depending on the type of issue, you may need to engage one of the previously mentioned stakeholders. It’s also important to identify which person or team owns driving the issues to completion. For instance, you might tell the engineering team they have an issue, but how do you make sure it gets into their backlog as a priority with a deadline for implementation?

When it comes time to prioritize issue resolution, in addition to understanding the issue severity, it’s helpful to understand the underlying risks involved. Are some issues business-impacting, like preventing users from completing a paid subscription or checking out of your store? Are there issues on your most visited pages? Do the issues create other types of compliance risks?

How accessibility audits fit into CMS operations

Timing your audits with key events in your CMS operations can help ensure you don’t create extra work for the team while also baking accessibility into your regular approach to maintaining your publishing operation. This means auditing as part of your migration planning, when you scope a redesign, or during major releases of new website features.

One way to scale your accessibility efforts is to leverage component-level audits where possible. Instead of looking at individual pages, look at the components that make up those pages. For the components that are used on more than one page, you can fix the accessibility once and cascade it out to all the places that component is used.

WordPress simplifies component-level auditing with the native Gutenberg Block Editor. You can modify a component of your WordPress theme and cascade the change everywhere it’s used.

You still need to perform page-level auditing in combination with component-level checks. The page context matters just as much as whether the component is accessible. One common example might be the nesting of headings on a page, where an H3 tag is incorrectly placed above an H2 in the presentation.

Like other aspects of your content program, governance is important in accessibility too. Defining roles and workflows around who is accountable for aspects of accessibility makes it easier to keep track of which aspects are being met or not.

Providing clear documentation and reporting out on your accessibility program, including sharing audit trails when relevant, can further promote accountability within the organization.

Adding process steps, like pre-publishing checks for things like ALT tags on images can help prevent regression. It is also possible to put in tooling that will provide error messaging for a user if they missed a step in their part of the workflow.

Making accessibility an ongoing practice

Maintaining an accessible website is best done by baking accessibility into your workflows and processes. Periodic audits are important for understanding a snapshot in time, but continuous monitoring will go further to making sure you are always compliant. It also reduces the overall workload by making accessibility part of daily activities.

Teaching your content creators and editors best practices for publishing, including adding ALT text, is part of your publishing DNA and saves time in the long run while creating a trusted experience. On the developer side, having your engineering team test for accessibility as part of the release process also helps streamline accessibility.

Choosing a platform that integrates accessibility into every layer further simplifies maintaining accessibility. WordPress VIP makes it easy to build accessibility into your page templates, individual blocks, and the underlying design system used for your website.

With ongoing audits, you can report to leadership on where you started in your accessibility journey, the progress you’ve made, and where you plan to continue improving accessibility over time.

Accessibility as an operational capability, not a checkbox

Shifting your team’s mindset around accessibility is critical to maintaining an accessible website over time. Audits are a function of maintaining quality and gaining user trust; they aren’t just an item on a to-do list. Being proactive in your inclusion of accessibility throughout the content lifecycle makes it easier to achieve consistently high accessibility over time.