Web Content Accessibility Guidelines (WCAG) Testing
Make WCAG testing a priority to remove accessibility barriers and ensure people with disabilities can access your products and services.
What is WCAG testing? Is it different from other forms of accessibility testing?
Testing your content against WCAG is the process of running accessibility tests to check for core WCAG success criteria—up to 50 different criteria depending on the conformance level! Instead of checking every single requirement manually, there are ways to combine automated and manual testing for full WCAG compliance coverage.
WCAG, a.k.a. the Web Content Accessibility Guidelines, are the technical guidelines created by the World Wide Web Consortium (W3C) for accessible web-based content.
Where should my organization start with WCAG compliance testing?
No matter the platform, a digital experience should meet the Web Content Accessibility Guidelines, also known as WCAG, to ensure it is equally accessible to all users. First, let’s start by discussing how processes and people are key to a successful accessibility testing program.
The best way to provide accessibility support is starting at the beginning of a project at the ideation phase, and including expert accessibility reviews at each major stage:
Understand the project goals, success metrics, and deadlines.
Train designers to design, prototype, and deliver mocks with accessibility in mind.
Train developers to catch glaring accessibility bugs in code before it goes into production.
Test the product using automated and manual scans against core WCAG criteria.
Ship your product with scheduled accessibility checkpoints built into the project plan.
Conduct ongoing testing and updates to produce the best UX possible.
WCAG accessibility compliance isn’t just the responsibility of your developers. Everyone has a part to play!
Your accessibility metrics should help break WCAG compliance into achievable, measurable milestones. Quick and easy wins stack up over time and can provide the justification needed for continued accessibility investment.
Remember: If you work outside the development team, it’s also important to keep in mind that the devs will ultimately be responsible for fixing your accessibility bugs. Don’t overburden them with unstructured actions. That’s where your success metrics come in.
Accessibility lead
Example success metrics:
- Issues by severity
- Issues by category
- Issue trends over time
Product owner
Example success metrics:
- Outstanding accessibility fixes
- Remediation response time
- Net daily accessibility defects
Senior management
Example success metrics:
- Trends in compliance
- Level of Effort (LOE) and cost estimates for critical barriers
Executives
Example success metrics:
- Risk assessment
- Cost of digital accessibility
The scope of WCAG testing
Once you’ve got the people and process in place, you’re ready to get to work! Testing will look different for every team and organization, but this is a general process to follow:
Step 1: Define the scope. Determine how many pages will be evaluated and select representative pages to evaluate against WCAG level 2.0 AA at a minimum.
Step 2: Run an automated scan of the page. Manual testing is always required to reach full compliance, but automation is a great way to get started.
The easiest way to start this journey is to use the axe browser extension for Chrome, Firefox, or Edge. axe is a free and easy-to-use developer tool that analyzes a web page for accessibility bugs with just a click of a button. Download and run axe as a foundation for the work to come in the manual testing phase.
Using a tool like axe Auditor can take the pressure off of your accessibility team to understand each success criterion since axe Auditor fully guides a user on how to test for specific criteria.
Step 3: Conduct a manual testing audit. Work with your team’s accessibility lead, or connect with a trained accessibility expert, to focus on the most damaging violations caught in the automated scan—and identify other blockers not yet detected.
Step 4: Test your product using a screen reader. Listen to the website or application using a specific screen reader/browser combination to detect otherwise invisible issues. This phase could also include usability testing with real users with disabilities to test their unique assistive technologies (AT).
Step 5: Document all findings in an accessibility report format. Bring all the findings together into a comprehensive and usable format that allows stakeholders to remediate the issues found based on recommendations.
What kind of WCAG accessibility tests exist?
There may be a day soon when automated tools can reliably catch closer to 100% of all issues and even fix them for you. Until then, your team can add the following tests to your workflow to cover the gaps that automated testing leaves behind.
In order to fully understand the accessibility of your site, you’ll need to experience your product with no sight, no sound, and no mouse.
Keyboard-only navigation tests
People with motor disabilities or those who use screen readers don’t use a mouse. This keyboard test will confirm they are able to navigate your product with their screen reader.
First, try navigating through your website using the tab key. As you hit tab, is it clear where you are on the page? Does a focus indicator appear to show that you’re on the “Resource” section in the top navigation or on a featured blog post? Can you select all of the page elements someone might want to navigate to? Can you navigate by tabbing? If not, your site is not fully accessible.
Screen reader testing
Form labels are one of the most common accessibility issues causing barriers. Making sure your form fields have the appropriate labels is key for people using screen readers to navigate and access the information on your page.
If a form isn’t properly labeled, a screen reader won’t know what field to enter on the form. And if the field isn’t labeled correctly, the screen reader user won’t know why an error message is popping up. For example, if a dentist office asks for patient information before the appointment via an inaccessible form, that prevents the user from getting the care they deserve.
Forms seem very simple, but the dependencies and rules must communicate properly to screen reader users, or they won’t be able to complete them.
No sound testing
Information included in audio, podcasts, or video isn’t available to people who are deaf or hard of hearing. This means that alternative methods, like transcripts and alt text, must be provided.
Free Site Audit
Identify and fix your accessibility in an instant No commitment Instant Results
How Deque Can Help
Audit
Most accessibility projects begin and end with an audit – they assess the current state of your site or application’s accessibility resulting in a clear accessibility report.
Learn More about accessibility auditsTraining
Accessibility Fundamentals: Disabilities, Guidelines, and Laws. This course provides an overview of important web accessibility concepts, suitable for both technical and non-technical audiences.
Learn More accessibility trainingContact Us
If you’re looking for help with the latest WCAG 2.1 update, or preparing for the upcoming WCAG 2.2, we’re available to help now.
Contact usAxe Testing Tools
The axe DevTools, axe Auditor and axe Monitor products enable accessibility experts and development to test and maintain accessibility end-to-end.
Learn More about the axe Suite