Accessibility (WCAG) Manual QA Testing Process

1. Purpose

This document describes the process for checking the accessibility of XWiki manually and also with the help of an AI assistant.

The QA engineer tests one feature (page, template, etc) at a time and reviews the page against WCAG 2.2 Level AA to identify potential accessibility issues. The aim is to make pages more usable for people with different disabilities, including people who use keyboards or screen readers.

AI supports the analysis and reporting, but it does not replace manual testing or prove WCAG conformance. The QA engineer is responsible for checking the actual page and validating all findings.

2. Scope and Tools

Test the pages and features included in the agreed QA scope. Focus on:

• Page structure, headings, links, buttons, images, tables;
• Forms, labels, instructions (for example when creating an AWM, etc), and error messages (for ex. when a not accepted input is made on a field that accepts a certain type of data);
• Keyboard navigation, visible focus, interactive components;
• Text and non-text contrast, zoom and responsive layout;
• Screen reader output and compatibility, where applicable.

Use the actual XWiki test instance, a browser, keyboard-only navigation, and screen reader when available.
Browser developer tools or automated accessibility tools may support the investigation, but their results must be reviewed.

3. Testing Workflow

Step 1: Navigate to the feature

• Go to a specific feature (page, template, etc)
• Open the page or resource included in the QA scope.

If using an AI assistant , give it the page URL or screenshots if it cannot access the test instance, the XWiki version, the page's purpose, and the WCAG target. Do not assume the AI assistant can interact with a local or restricted page.

Step 2: Review the feature

Identify relevant accessibility checks and map potential issues to applicable WCAG success criteria. Define clear test steps and verify the outcome against expected results. The review should consider:

• Perceivable: meaningful text alternatives, content structure, contrast, and resizing;
• Operable: keyboard access, visible focus, and usable menus or dialogs;
• Understandable: clear labels, instructions, navigation, and error messages;
• Robust: accessible names, roles, and states, including screen reader support.

Step 3: Verify manually

Perform the proposed checks on the actual feature. Navigate using only the keyboard and check focus, expected order and operation.
Inspect readability, contrast, and zoom where relevant. Use a screen reader to verify that headings, links, controls, form fields, errors, and important updates are announced appropriately.

Step 4: Validate potential issues

For each suspected issue, compare the observed behavior with the expected behavior and the relevant WCAG criterion.
If using an AI assistant, not every suggestion or unexpected screen reader announcement is, by itself, proof of a WCAG failure. If evidence is insufficient, investigate and validate the issue manually.

4. Final review and reporting

After testing, report the confirmed issues. Issues must reflect only the features and functionality actually tested.

Testing a part of a feature does not mean that the entire feature conforms to WCAG.

AI assistant can help plan checks, explain WCAG criteria, and organize reports, but it can make mistakes. The QA engineer must validate findings against the actual implementation and the applicable WCAG requirements.