UX & Software Ergonomics
Automated accessibility tools can reveal important barriers, but they cannot independently evaluate every accessibility requirement. A defensible examination defines scope, product version, reference standard, manual procedures, sampling and the boundary of the resulting statement.
Short answer
Treat an automated scan as one technical finding, not as complete proof of accessibility. A structured evaluation combines an identified product state, an explicit WCAG reference, appropriate tools, manual interaction checks and a transparent report of what was and was not examined.
Technical evaluation and legal compliance are separate questions. The examination can report conformance-related technical findings for the stated scope without deciding which statutory obligations apply to a particular provider or product.
1. Define scope and reference standard
Record the exact product version, relevant functions, technologies and states before evaluation. Changes in content, navigation, components or framework can create a materially different examination state.
State the WCAG version and any conformance target explicitly. A generic accessibility check is not enough to support a specific conformance statement because the criteria and scope must be identifiable.
The examination records the concrete task, user group, system version, device or input method and the selected assessment criterion before interpreting the result. An observation on one path is not silently generalised to all users, components or product states. Technical and ergonomic findings are kept separate from a legal conformity assessment, and untested contexts remain outside the conclusion.
2. Use automated tools as partial examinations
Automated tools can efficiently identify certain technical patterns such as missing names, structural errors or detectable contrast issues. Each finding should be mapped to the concrete criterion and DOM or content state it concerns.
A tool pass is not a complete accessibility pass. Some criteria require human judgement, tools can produce false positives, and automated rules may not understand task context or interaction meaning.
The examination records the concrete task, user group, system version, device or input method and the selected assessment criterion before interpreting the result. An observation on one path is not silently generalised to all users, components or product states. Technical and ergonomic findings are kept separate from a legal conformity assessment, and untested contexts remain outside the conclusion.
3. Evaluate non-automatable aspects manually
Manually test keyboard and focus behaviour, meaning, sequence, instructions and other aspects that require contextual judgement. The existence of a focusable element does not prove that an entire workflow remains understandable and operable.
Review accessible semantics together with actual function. Attributes or visible text must make sense in the concrete interface and task rather than being counted as isolated markup features.
The examination records the concrete task, user group, system version, device or input method and the selected assessment criterion before interpreting the result. An observation on one path is not silently generalised to all users, components or product states. Technical and ergonomic findings are kept separate from a legal conformity assessment, and untested contexts remain outside the conclusion.
4. Select product exploration and samples transparently
Large digital products may require sampling. WCAG-EM separates scope definition, exploration and representative sample selection so that the evaluated views, functions and states are transparent.
Areas outside the selected sample remain outside the statement. A partial evaluation should not be silently presented as a complete examination of every product state or page.
The examination records the concrete task, user group, system version, device or input method and the selected assessment criterion before interpreting the result. An observation on one path is not silently generalised to all users, components or product states. Technical and ergonomic findings are kept separate from a legal conformity assessment, and untested contexts remain outside the conclusion.
5. Use user involvement as complementary evidence
People with disabilities can expose barriers and practical effects not captured by conformance checks alone. User observation can therefore complement standards-based technical evaluation.
A small number of individual user sessions does not prove complete conformance or represent every disability and context. Treat user observations as valuable contextual evidence with their own scope.
The examination records the concrete task, user group, system version, device or input method and the selected assessment criterion before interpreting the result. An observation on one path is not silently generalised to all users, components or product states. Technical and ergonomic findings are kept separate from a legal conformity assessment, and untested contexts remain outside the conclusion.
6. Separate technical conformance from legal assessment
The report should state scope, criteria, technologies, tools, manual procedures and sampling so that the technical conclusion can be reviewed.
Whether a legal accessibility duty applies, what level is legally required or which legal consequence follows is a separate legal question. Technical standards inform the evidence but do not automatically decide that question.
The examination records the concrete task, user group, system version, device or input method and the selected assessment criterion before interpreting the result. An observation on one path is not silently generalised to all users, components or product states. Technical and ergonomic findings are kept separate from a legal conformity assessment, and untested contexts remain outside the conclusion.
Examination checklist
- Is the exact product version identified?
- Is the evaluation scope explicit?
- Is the WCAG version or other technical reference named?
- Are automated findings mapped to concrete criteria?
- Are manual keyboard, focus and semantic checks documented?
- Is sampling justified and bounded?
- Is user involvement correctly limited in scope?
- Is technical conformance separated from legal assessment?
Constructed example
An automated scan reports no errors on a form page. Manual keyboard testing shows that after an input error the focus moves to an unrelated control and the error context is difficult to recover. The automated pass is therefore recorded as one partial result rather than treated as proof of overall accessibility.
The example is entirely constructed and does not describe a real engagement, client matter or historical case.
Sources and technical basis
- Web accessibility standardW3C — Web Content Accessibility Guidelines (WCAG) 2.2. Testable accessibility success criteria for web content. Open source.
- Evaluation methodologyW3C — Website Accessibility Conformance Evaluation Methodology (WCAG-EM). Method for defining scope, exploring a product, selecting samples, evaluating and reporting results. Open source.
- Technical guidanceW3C WAI — Involving Users in Evaluating Web Accessibility. Guidance on user involvement, context and limitations of generalisation. Open source.
- Technical guidanceW3C WAI — Selecting Web Accessibility Evaluation Tools. Guidance on the capabilities and limits of automated accessibility tools. Open source.
- Methodological basisSources & Methodology documents source hierarchy, counter-hypothesis control and statement boundaries for the English knowledge base.
Further reading
- Keyboard Operation, Focus Management and Semantic States
- Systematic Usability Examination
- Sources & Methodology
Critical review and methodological limitation
Accessibility evaluation is sensitive to scope. Different pages, component states, authentication levels and assistive-technology paths can expose barriers that are absent from a limited sample.
Automated, manual and user-based evidence should remain distinguishable. Combining them strengthens the examination, but none should be overstated into a universal legal or product-wide conclusion beyond the documented scope.
Translation and methodological scope
This English article is based on the reviewed German V1 source article. The translation preserves the technical meaning, methodological distinctions, source status and stated limitations. It does not strengthen technical findings into legal conclusions and does not treat technical references as proof of compliance or suitability for a specific system.
Author's technical literature and publications
The following works provide additional technical and methodological context. They do not replace required primary sources, standards, manufacturer documentation or other independent specialist sources. Unpublished manuscripts, drafts and teaching materials are deliberately not presented here as public sources.
UX, Software Ergonomics & Accessibility
Technical and methodological examination of usability, context of use, interaction quality and accessible operation.
Explore this assessment service