I built the CarlasHub Accessibility Test Case Manager to make manual accessibility testing easier to plan, complete and record.
WCAG is essential, but working directly from a long list of success criteria can be difficult during a real review. I wanted something that connected the standard to recognisable parts of a website, such as navigation, forms, dialogs, images and videos.
The manager now includes:
- 14 component-based testing procedures
- 17 task-based WCAG test groups
- Manual checks covering all 55 active WCAG 2.2 Level A and AA success criteria
- 165 testing steps
- Space to record results, evidence and notes
- CSV, JSON and HTML reports
- A guided testing mode
- A WCAG-EM-inspired evaluation report
What the tests are based on
The main source is WCAG 2.2. This is the standard that defines the accessibility requirements, so every test must connect back to a WCAG success criterion.
I also used several supporting W3C resources:
- Understanding WCAG 2.2 helped explain the purpose of each success criterion and the barriers it is intended to prevent.
- How to Meet WCAG 2.2 helped connect criteria with practical testing approaches.
- Techniques for WCAG 2.2 provided examples of sufficient techniques, advisory techniques and common failures.
- WAI-ARIA Authoring Practices Guide was used when checking the expected roles, states and keyboard behaviour of components such as dialogs, menus and tabs.
- WCAG-EM 2.0 influenced the evaluation workflow, including scope, sample selection, findings, limitations and reporting.
- Selecting Web Accessibility Evaluation Tools supported the decision to combine automated checks with manual testing.
WCAG 2.2 remains the source of the requirements. The supporting documents help explain and test those requirements; they do not add new ones.
How the test steps were written
Each test turns a WCAG requirement into three practical questions:
- What should the tester do?
- What should happen?
- What evidence should be recorded?
The procedures include keyboard testing, screen-reader and accessibility-tree checks, colour contrast, text spacing, zoom and reflow, pointer and touch interaction, form completion, browser autofill, media alternatives and complete user journeys.
This matters because automated tools can find some problems, but they cannot decide whether instructions make sense, focus moves to the right place or a task can be completed successfully.
Why organise tests by component?
People do not usually look at a page and think, “I need to test Success Criterion 1.3.1 now.” They see a form, a menu, a dialog or a video.
The component procedures provide a practical starting point. Testers can select the parts that appear on the page and then use the WCAG coverage view to find any criteria that have not yet been included.
This keeps the experience approachable without losing the connection to the standard.
Testing the test manager
The manager is checked with validation scripts and browser tests. These verify the WCAG inventory, internal links, keyboard behaviour, saved progress, report generation and accessibility of the interface itself.
Automated accessibility checks use axe-core as a safety net. They are useful for catching certain technical problems, but they do not replace keyboard, screen-reader or user-journey testing.
I also tested the workflow against BuggyLand, a practice website containing deliberate accessibility problems. It provided a repeatable way to test selecting procedures, recording evidence, saving progress and producing the final reports.
A working project
This is still a project in progress. It is not a certification tool, and completing its test cases does not automatically prove that a website conforms to WCAG.
The aim is simpler: provide a clear, useful place to plan accessibility testing, carry it out and keep the evidence together.
You can try the Accessibility Test Case Manager or view the project on GitHub.
