Introduction
Imagine a website that has everything right, but users can’t open the menu without a mouse, or a form that displays an error message on the screen, but the screen reader doesn’t announce it. Such sites may appear not to be completely accessible for users with various needs. For many, such barriers to accessing information and services may be annoying, but for some people, they may be deal-breakers.
Web Accessibility Testing is an integral part of software testing that allows QA specialists to ensure that a website is accessible for everyone who wants to use it. This may include people who read texts on a screen, interact with websites using a keyboard or other alternative control devices, fill out forms, and perform other actions.
The QA process should not leave accessibility for the end of development when there is little time and no desire to fix the found issues. Specialists must proactively look for problems during development and testing cycles. Various browsers also have built-in tools that help testers identify accessibility issues. So it is necessary to study the interface of the site manually to see if everything is okay from the point of view of different users.
In this article, we get to know the fundamentals of Web Content Accessibility Guidelines 2.2, POUR principles, extensions for testing, automated and manual solutions, common problems, and a QA checklist.
What is web accessibility testing?
Web Accessibility Testing refers to examining a website or web application’s compliance with accessibility standards.
However, there is an easier way to remember the principles by answering these four questions:
-
Can the user perceive the content?
-
Can they understand what is being presented?
-
Can they navigate through the website?
-
Can they interact with the available controls?
Example:
A checkout page with a “Place Order” button. A mouse user may have no problem clicking it. But what happens when someone tries to reach the same button using only a keyboard? Is the focus visible? Can the button be activated? Does a screen reader announce what the button does?
These are the kinds of questions accessibility testing needs to answer.
There are three types of testing:
Manual testing: includes testing things such as keyboard navigation, focus order, forms, dialogs, zoom, and user interaction.
Automation is the tools to find issue by using script.
Assistive-technology testing is using screen readers to understand how the application behaves.
A good accessibility strategy normally uses all three.
Why accessibility testing matters for modern web applications
Accessibility is not only about meeting a standard. It is also about removing unnecessary friction from a product.
Consider a navigation menu,
As a QA, accessibility testing helps teams check another important part of the user experience.
It also supports:
-
More inclusive interfaces
-
Better usability
-
More consistent UI components
-
Easier maintenance
-
Reduced accessibility barriers
-
Alignment with accessibility standards such as WCAG
Accessibility therefore works best when it becomes part of the normal development and QA process rather than a separate activity at the end.
For additional guidance, see our article on web accessibility best practices.
Understanding the POUR principles and WCAG 2.2
Whenever a team works to complete a project relating toWCAG accessibility testing, they are commenly referring to the Web Content Accessibility Guidelines.
Perceivable, Operable, Understandable, and Robust.
Perceivable
Users must be able to perceive the information on the page.
while testing, this can include checking:
-
Alternative text for meaningful images
-
Captions for applicable video content
-
Text and background contrast
-
Content that does not depend only on color
-
Content behavior when text is enlarged
For example, if an application displays a validation error only by changing a field border from gray to red, some users may not understand what happened. A clear error message provides additional information.
Operable
Users should be able to interact with the application.
This is where keyboard testing becomes especially important.
A QA engineer should check:
-
Can all interactive elements receive focus?
-
Is the focus indicator visible?
-
Does the focus move in a logical order?
-
Can menus and dialogs be operated with the keyboard?
-
Can the user escape from a component?
A commen mistake from developer is using a generic element as a button:
<div class="button" onclick="submitForm()">
Submit
</div>
It may looks like a button, but it does not automatically gives the expected keyboard and semantic behaviour.
A native button is usually a better starting point:
<button type="submit">
Submit
</button>
Understandable
A website should not make users guess what to do. Testers should look at:
-
Form labels
-
Instructions
-
Validation messages
-
Navigation
-
Error handling
-
Consistency between pages
For example,
“Invalid input” message is not user friendly. A proper message such as “Enter a valid email address” gives the proper user experience to act on it.
Robust
The application should work reliably across browsers, different devices and sizes, and assistive technologies.
Semantic HTML plays an important role here. ARIA can also be useful when needed, but adding ARIA attributes to every component is not a substitute for proper HTML structure.
The goal is not simply to make an automated tool happy. The interface needs to communicate its structure and purpose correctly to browsers and assistive technologies.
Automated vs manual accessibility testing
There is sometimes a misconception that running an accessibility scanner is enough. It is not.
Automation process is fast and repeatable, which makes it valuable for development and regression testing. Manual testing, on the other hand, helps uncover issues that depend on interaction and human judgment.
| Testing area | Automated testing | Manual testing |
| Execution | Fast | Takes more time |
| Repeated checks | Very useful | Less efficient |
| Missing labels | Can detect many cases | Can verify actual context |
| Color contrast | Can detect measurable issues | Useful for visual review |
| Keyboard navigation | Limited | Essential |
| Focus behavior | Limited | Essential |
| Screen reader experience | Limited | Essential |
| Human judgment | No | Yes |
| Regression testing | Very useful | Important for critical flows |
The practical approach is to use automation for what it does well and manual testing for what requires human observation. For example, an automated scan may identify that an input is missing a label. A tester can then go one step further and check whether the form makes sense when navigating through it with a keyboard and screen reader.
How to test web accessibility using modern browser tools
Modern browsers have made accessibility testing much more accessible to QA engineers. You do not always need a separate application just to start investigating an issue.
Chrome DevTools is a good example.
Start with the elements panel
Open the website in Chrome and launch DevTools.
From the Elements panel, select an element and inspect its accessibility information. Depending on the element, you can investigate its role, accessible name, ARIA information, and position within the accessibility tree.
This becomes particularly useful for custom UI components.
For example:
<button class="menu-button">
<span class="menu-icon">☰</span>
</button>
A sighted user can understand that the icon represents a menu. But the accessible name exposed to assistive technology is what matters as well.
A clearer implementation could be:
<button
class="menu-button"
aria-label="Open navigation menu">
<span aria-hidden="true">☰</span>
</button>
A question from QA should be: What will the user actually hear or understand when this control receives focus? That question is often more useful than simply checking whether an accessibility attribute exists.
Run a Lighthouse accessibility audit
Chrome also provides Lighthouse audits.
A basic test flow is:
Open DevTools → Lighthouse → Select Accessibility → Run Audit → Review Results
The report can identify several common problems, including issues involving labels, accessible names etc.
However, a clean Lighthouse report does not mean the website has passed every accessibility requirement.
There are many things an automated tool cannot understand in the same way a human tester can.
For example,
a tool may confirm that a button has an accessible name. It may not tell you whether that name actually makes sense in the context of the user’s flow.
Test the website without a mouse
This is one of the simplest accessibility tests a QA engineer can perform.
Put the mouse aside and use the keyboard.Try:
-
Tab
-
Shift + Tab
-
Enter
-
Space
-
Arrow keys where applicable
-
Esc for dialogs and menus
Now try completing a real user flow.
For example:
Homepage → Search → Product info → Add to Cart → Checkout
Possible Questions for better accessibility:
-
Can I reach every required control?
-
Can I see where the focus is?
-
Does focus move in a sensible order?
-
Can I open and close menus?
-
Can I use forms?
-
Can I recover from an error?
-
Can I complete the flow without touching the mouse?
This kind of browser accessibility testing can reveal issues very quickly.
Check focus visibility
Imagine pressing Tab and knowing that focus has moved somewhere, but you cannot tell where.
That is a usability problem.
Every important interactive element should provide a clear visual indication when it receives keyboard focus.
A QA engineer should test this across:
-
Links
-
Buttons
-
Form controls
-
Menus
-
Dialogs
-
Custom components
Check contrast
Text that looks readable on one monitor may become difficult to read in different conditions.
Use browser tools to inspect contrast and then review important UI states such as:
-
Normal text
-
Links
-
Buttons
-
Disabled states
-
Error states
-
Focus states
-
Placeholder text
Also check whether the interface communicates information only through color.
For example, saying “the fields in red are mandatory” creates a problem if color is the only indicator. A visible label such as “Required” is much clearer.
Test zoom and responsive behavior
Accessibility testing should not be limited to a standard desktop resolution.
Increase browser zoom and resize the viewport.
Check whether:
-
Text remains readable
-
Content is not unnecessarily cut off
-
Navigation remains usable
-
Forms remain functional
-
Dialogs remain accessible
-
Important controls remain reachable
A component that looks perfect at 1440px can behave very differently at a smaller viewport or increased zoom level.
Use dedicated accessibility testing tools
Browser DevTools are useful for investigation, but dedicated accessibility testing tools can make repeatable testing easier.
Common options include:
-
Lighthouse
-
axe DevTools
-
WAVE
-
Chrome DevTools
-
Screen readers
Each tool has a different purpose. Instead of expecting one tool to find everything, QA teams can combine them as part of their testing strategy.
For more ideas on using browser tools in day-to-day QA, see How QA Engineers Can Leverage Browser DevTools for QA Testing.
Which accessibility testing tool are useful
| Tool | Useful for | Approach |
| Lighthouse | Quick accessibility audits | Automated |
| axe DevTools | Finding common accessibility violations | Automated + investigation |
| WAVE | Visual accessibility feedback | Automated + manual |
| Chrome DevTools | Inspecting DOM and accessibility information | Manual |
| Screen readers | Understanding real assistive-technology interaction | Manual |
For an early development check, Lighthouse can be convenient. For deeper investigation, Chrome DevTools and axe can provide more information.
A practical web accessibility testing workflow
Accessibility testing becomes much easier when QA teams follow a repeatable process.
1. Identify critical user flow
Start with the flows that matter most to users.
Examples :
-
Login
-
Registration
-
Search
-
Checkout
-
Form submission
-
Account management
-
Navigation
2. Run automated checks
Run Lighthouse, axe, WAVE, or another suitable tool for the relevant pages.
Record the issues instead of simply looking at the final score.
3. Investigate the issue
Open the affected element in browser DevTools.
Check the HTML, accessible name, role, ARIA attributes, and surrounding structure.
4. Perform keyboard testing
Repeat important user journeys without a mouse.
This often exposes problems that automated scans miss.
5. Check with assistive technology
For important workflows, use a screen reader and check how headings, buttons, forms, alerts, and navigation are announced.
6. Fixes and retesting
Once developers fix the issue, repeat the original test.
Do not assume that changing one component has not affected another.
7. Add accessibility to regression testing
Important accessibility checks should become part of regular QA regression rather than being forgotten after a release.
How to fix common accessibility issues
| Issue | What a QA engineer may find | Typical fix |
| Missing alternative text | Meaningful image is not described | Add appropriate alt text |
| Missing form label | Input purpose is unclear | Add an associated label |
| Poor contrast | Text is difficult to read | Improve contrast |
| Invisible focus | Keyboard user cannot locate focus | Add a visible focus style |
| Incorrect heading order | Headings do not follow a logical structure | Correct heading hierarchy |
| Unnamed button | Screen reader cannot identify the control | Add an accessible name |
| Keyboard trap | Focus cannot leave a component | Correct keyboard handling |
| Incorrect ARIA | Role or state does not match the component | Correct ARIA or use semantic HTML |
One issue worth highlighting is the use of clickable non-button elements.
A developer may create a <div> and add JavaScript to make it behave like a button because it is quick to style. The page may look correct, but keyboard and assistive-technology behavior can become inconsistent.Whenever possible, starting with the correct HTML element reduces this type of problem.
Common mistakes accessibility testing
Accessibility problems are often caused not by a lack of tools, but by how testing is approached.
Relying only on automation
An automated report is useful, but it cannot represent the entire user experience.
Testing only before release
Finding accessibility issues early in the staging build can make better user experience.
Ignoring keyboard navigation
A page can pass several automated checks and still be difficult to operate using only a keyboard.
Testing only the homepage
Important issues may exist inside forms, menus, dashboards, checkout pages, search results, and modal dialogs.
Adding ARIA everywhere
ARIA should solve a real accessibility need. It should not be added simply because a component is custom.
Accessibility as a QA-only task
Developers, QA engineers, and UI/UX team all influence accessibility.
Best practices for QA engnieers
Here are some practices where teams can adopt:
-
Include accessibility requirements in acceptance criteria.
-
Use semantic HTML whenever possible.
-
Run automated checks during development.
-
Perform keyboard testing on important workflows.
-
Include screen-reader testing for critical journeys.
-
Test responsive and zoomed layouts.
-
Track accessibility defects through the normal defect-management process.
-
Retest fixes and include them in regression coverage.
-
Add automated checks to CI/CD where practical.
-
Train developers and QA engineers on WCAG fundamentals.
For organizations using software quality assurance services, accessibility testing can also be integrated with functional testing, regression testing, automation, cross-browser testing, and release validation.
The benefit is that accessibility becomes part of the team’s existing quality process instead of becoming another isolated testing activity.
Web accessibility testing checklist
Page structure
-
Logical heading hierarchy
-
Semantic HTML
-
Meaningful landmarks
-
Correct page language
Keyboard
-
All interactive elements are keyboard accessible
-
Focus is visible
-
Focus order is logical
-
No keyboard traps
Visual accessibility
-
Text has adequate contrast
-
Color is not the only way information is communicated
-
Content remains usable when zoomed
-
Responsive layouts remain functional
Forms
-
Form fields have appropriate labels
-
Required fields are clearly identified
-
Error messages are understandable
-
Validation feedback is accessible
Content
-
Meaningful images have appropriate alternative text
-
Decorative images are handled appropriately
-
Links have meaningful names
-
Applicable videos have captions
Testing
-
Automated accessibility scan completed
-
Browser accessibility inspection completed
-
Keyboard testing completed
-
Critical flows tested with assistive technology
-
Fixed accessibility defects regression-tested
Conclusion
A website does not become accessible simply because it passes an automated scan. Real accessibility requires a combination of good development practices, automated checks, manual QA, and assistive-technology testing.
Web Accessibility Testing should therefore be part of the development and QA lifecycle from the beginning. WCAG 2.2 provides a useful framework, while browser tools make it easier to identify and investigate common issues during development and testing.
For QA teams, a practical starting point is straightforward: run automated checks, inspect the results in browser DevTools, test important workflows with a keyboard, and validate critical experiences with assistive technologies.
When accessibility becomes part of regular regression and release testing, teams are less likely to discover major barriers at the last minute. Organizations looking for additional support can also use software quality assurance services to incorporate accessibility into their wider testing strategy.
About August Infotech
August Infotech provides software development and quality assurance services for businesses building and maintaining digital products. Accessibility testing can be combined with functional, automation, regression, performance, and cross-browser testing to provide broader coverage throughout the software lifecycle.
Planning to improve the accessibility of your web application? Talk to the August Infotech team about your accessibility and QA testing requirements.
