Can Tricentis TOSCA Be Used for Accessibility Testing?
Yes. Our automation team built a proof of concept (POC) to evaluate whether Tricentis TOSCA could automate web accessibility testing aligned with WCAG 2.2 Level A and AA guidelines.
The framework used TOSCA’s built-in integration with the accessibility engine to identify compliance issues across HTML-based web applications.
Business Context
Our client wanted to strengthen accessibility in their digital applications. Our automation team identified the opportunity during regular testing discussions. Accessibility checks were not yet part of their standard process, and we saw that TOSCA could help automate key validations.
This gave us a chance to explore and demonstrate a practical solution.
What Challenge Were We Solving?
Accessibility testing had not been included in the regular testing strategy. The team needed to determine whether TOSCA could effectively handle accessibility validations. We had to move quickly to explore feasibility, run a demonstration, and show real value.
The main goal was to identify compliance issues aligned with WCAG Level A and AA. Manual testing was slow and inconsistent, so automation offered a promising path if it could be made to work well in their setup.
How We Built the Accessibility Testing Framework in TOSCA
Our TOSCA automation team followed a structured approach to build and validate the framework.
Step 1: Understanding WCAG Accessibility Requirements
We began by reviewing WCAG guidelines, focusing on the most relevant success criteria for A and AA levels. This included checks for:
- Color contrast
- Keyboard navigation
- Screen reader compatibility
- Alternative text for images
Step 2: Exploring Tricentis TOSCA Accessibility Capabilities
We reviewed the official Tricentis TOSCA documentation for web accessibility testing.
TOSCA integrates the Deque axe-core library directly into the XBrowser Engine 3.0, enabling automated accessibility checks based on WCAG 2.2 Level A and AA rulesets for HTML-based web applications.
For our POC, we primarily used the Specified Webpage mode with the Check Webpage Accessibility standard module. This allowed us to run targeted tests on specific pages.
TOSCA also provides Test Configuration Parameters (TCPs) to control how accessibility testing is executed.
TOSCA Test Configuration Parameters Used
| TCP Parameter | Purpose | Main Options / Values |
| RunAccessibilityAnalysis | Controls when and how accessibility checks are performed | Specified Webpage (used in our POC), Before Inputs, After Inputs, Disabled |
| AccessibilityFastMode | Improves scan performance on large pages | Optimize Analysis, Ignore Passed Checks, Disable Redundant Checks, Off |
These parameters, combined with detailed reports showing severity levels (Critical, Serious, Moderate, Minor) and suggested fixes, made the testing practical and scalable.
Step 3: Selecting Sample Application Pages
The application had a total of 9 payroll pages.
We selected the first 4 payroll pages for the POC. These pages contained typical elements such as forms, tables, buttons, and text that are ideal for accessibility validation.
Step 4: Executing Accessibility Tests
We created the test cases in TOSCA and ran them against the selected payroll pages.
The automation scanned for accessibility issues and generated clear results.
Step 5: Categorizing Accessibility Findings
We grouped the findings by:
- Severity
- WCAG compliance level (A and AA)
This made it easier to understand what needed attention and in what priority.
Accessibility Testing Demonstration
As part of the demonstration, the team executed an accessibility test on the first 4 payroll pages (out of 9 total payroll pages) using TOSCA.
The results highlighted key observations and categorized them under WCAG Level A and AA compliance, making it easier for stakeholders to understand the accessibility gaps and prioritize improvements.
Results and Value Delivered
This POC delivered several concrete benefits:
- Demonstrated that accessibility testing can be implemented effectively using TOSCA.
- Helped the client identify accessibility gaps early.
- Showed how automation can support consistent compliance validation.
- Created a foundation for integrating accessibility testing into the broader QA strategy.
- Enabled faster identification of WCAG Level A and AA compliance issues.
The exercise helped turn accessibility into something that could be handled systematically rather than as an afterthought.
Why Accessibility Testing Should Be Part of Every QA Strategy
Accessibility testing ensures digital applications are usable by a broader range of people, including those who rely on assistive technologies such as screen readers or keyboard navigation.
When included early in the QA lifecycle, accessibility testing:
- Reduces expensive rework
- Improves compliance readiness
- Delivers better user experiences
- Strengthens brand trust
- Helps organizations avoid risks associated with inaccessible products
Inclusive design has become an essential part of building quality software.
Frequently Asked Questions
Can Tricentis TOSCA perform accessibility testing?
Yes. Tricentis TOSCA integrates the Deque axe-core accessibility engine, enabling automated accessibility testing for HTML-based web applications against WCAG 2.2 Level A and AA guidelines.
Which WCAG compliance levels does TOSCA support?
TOSCA accessibility testing supports WCAG 2.2 Level A and Level AA through its integration with the axe-core rules engine.
What accessibility issues can TOSCA identify?
TOSCA can detect issues related to color contrast, keyboard accessibility, screen reader compatibility, missing alternative text, and other WCAG compliance violations.
Does TOSCA generate accessibility reports?
Yes. TOSCA generates reports that categorize findings by severity (Critical, Serious, Moderate, Minor) and include suggested remediation guidance.
Why automate accessibility testing?
Automated accessibility testing helps identify compliance issues earlier, improves consistency, reduces manual effort, and makes it easier to incorporate accessibility into continuous QA processes.
