Accessibility checks within QA

Accessibility defects are defects. A form field without a label, a menu that cannot be opened with a keyboard, or text too faint to read are failures in the same sense as a broken link: someone tries to use the site and cannot. We treat them that way, logging them in the same defect list, at the same level of detail, and retesting them after fixes as quoted.

Where accessibility fits in our QA work

Our accessibility checks sit inside the wider QA process. They are scoped to what a pre-launch or post-update review can cover well: a representative sample of templates and key flows, tested against the WCAG 2.2 success criteria that apply to them. That gives a release team a clear list of barriers to fix before launch.

What it does not give is a formal statement that a website conforms to WCAG 2.2 or to EN 301 549. That kind of audit needs a larger page sample, a documented methodology, and testing with assistive technologies and, ideally, disabled users. If you need one, for example to support a public sector accessibility statement or a procurement requirement, we will say so and suggest you commission a dedicated audit.

What we check

• Automated scan. An automated checker run over the sample, with every result reviewed by a person. The W3C notes that evaluation tools can only assist, not determine, accessibility.
• Keyboard use. Every interactive element reachable and usable with the keyboard alone, in a sensible order, with a visible focus indicator that is not hidden behind sticky headers.
• Forms. Visible labels tied to their fields, instructions that come before the field, and error messages that say what went wrong in text, not just with colour.
• Contrast. Text and interface components measured against the WCAG minimums.
• Zoom and reflow. Content usable at 200 percent text size and at a width of 320 CSS pixels without sideways scrolling.
• Structure. Page titles, headings, landmarks and link text that make sense out of context.
• Images and media. Alternative text that serves the purpose of the image, and captions or transcripts where media carries information.
• Target size and dragging. Two of the criteria added in WCAG 2.2: targets large enough to press, and alternatives to drag-only interactions.

The legal background, briefly

The European Accessibility Act has applied since 28 June 2025. In Ireland it was transposed by S.I. No. 636 of 2023, and the Competition and Consumer Protection Commission is the market surveillance authority for e-commerce services, among others. The CCPC states that the rules do not apply to microenterprises providing services, which it defines as businesses with fewer than 10 employees and an annual turnover or balance sheet of no more than EUR 2 million. Public sector websites fall under separate regulations, S.I. No. 358 of 2020, with the National Disability Authority as the monitoring body.

We mention this because it explains why accessibility checks belong in QA, not because a QA review answers legal questions. Whether a specific obligation applies to your organisation is a question for your legal adviser. Our report describes barriers and fixes; it does not offer a legal view.

How the sample is chosen

A sample only means something if it represents the site. We choose pages so that every template and every distinct component appears at least once: the home page, a standard content page, a listing page, a form, any page with a table or media, and each step of the main flow. Where the same template is used for many pages, one or two instances stand in for the rest, and the report lists which pages were sampled and which templates they represent. If a component appears only on a page outside the sample, we add the page rather than skip the component.

What you receive

• Accessibility findings in the main defect list, each mapped to the WCAG 2.2 success criterion it relates to, with the page, the steps and a screenshot.
• A short note on what the sample covered and what it did not, so nobody mistakes it for a full audit.
• Retest results after fixes, as quoted.

What this service does not cover

We do not issue conformance certificates or accessibility statements. We do not claim screen reader testing unless it is specifically scoped and done, and when it is, the report names the screen reader and browser combinations used. Overlay widgets that promise to fix accessibility automatically are outside what we would recommend; the W3C guidance on tools explains why automated approaches miss so much.

Questions about accessibility checks