The W3C WCAG-EM 2.0 Report Tool helps accessibility evaluators turn a defined scope, a representative sample and actual test findings into an understandable evaluation report. If you need a WCAG-EM Report Tool tutorial for a multilingual website, app or digital product, this guide explains the five-stage evaluation process, how to preserve language and region coverage, and how to avoid claims that exceed the evidence collected.
WCAG Evaluation Methodology 2.0 was published by W3C as a Group Note on 23 July 2026 and extends the evaluation approach beyond websites to apps and other digital products. The accompanying report generator does not run automated checks. It provides a structured place to record the product, methods, sampled views, outcomes and limitations, then export a report that people responsible for accessibility can assess and act upon.
This guide covers evaluating translated products across language routes, right-to-left layouts, mobile interfaces and changing states. It explains scope boundaries, representative versus random samples, accessible reporting, issue evidence, retesting, and the proper distinction between an observed test outcome and a general claim about every page, locale or user. The result should be a useful decision document, not a decorative pass certificate.
- What to do first: define a meaningful user task, choose the correct language and reproduce the relevant page state.
- What this guide covers: defensible evaluation scope, representative sampling, clear outcomes and auditable multilingual evidence.
- What the tool can prove: results from its actual tested conditions, not complete translation quality or conformance.
- What to preserve: route, locale, build, viewport, interaction state, affected element and a reproducible test.
- What a useful finish looks like: confirmed repair, targeted retest, human review and a clear release decision.
What WCAG-EM 2.0 Report Tool actually does
The W3C’s WCAG-EM 2.0 describes five main activities: define the evaluation scope; explore the digital product; select a representative sample; evaluate that sample; and report the findings. Because a large multilingual service may have thousands of routes, the sample must reflect important templates, user journeys, technologies, states and language-specific risks. A sample supports a bounded evaluation; it does not magically prove that untested variations are identical.
The current W3C report tool uses terminology aligned with WCAG-EM 2 and can be used for apps as well as websites. It runs in the browser, allows structured input, and exports HTML or JSON. It does not automatically save your work to a server or persistent browser storage; download partial reports as you go and keep them in a controlled project repository. A lost form session is not a valid audit record.
An evaluation requires knowledge of WCAG success criteria, accessible design and assistive technologies, alongside the ability to check the product’s real user experience. For translation-related work, add language expertise and awareness of script differences. Automated scanners, keyboard tests, screen-reader sessions and native-speaker reviews are evidence sources. The report tool helps organize the resulting observations; it is not the source of those observations.
Unlike a scanner or developer-tools extension, the W3C report generator organizes a human-led conformance evaluation. Its unique job is disciplined scoping, sampling, evidence and communication of what was actually tested.
The practical distinction between detected evidence and accessible user experience matters in every language. A rule result is tied to an element, configuration, view or sampled product state. A user experiences a complete action: understanding an instruction, choosing a control, recovering from an error and knowing what happened. For that reason, keep three questions separate: what the tool observed, what a person can successfully do, and whether the target-language content communicates the intended meaning. This guide repeatedly brings those questions together without pretending one can stand in for the others.
A reliable ten-stage workflow
1. Define the product boundary
Name the evaluated website, app, release, environment, language routes, included features, and explicit exclusions. Resolve disagreements before sampling. Before drawing a conclusion, name the language, region and concrete page state under investigation. This makes an observation reproducible for someone who does not share the original tester’s browser session or assumptions. A successful process should distinguish a tool setup failure from a genuine product issue and should identify which evidence still needs human confirmation.
An evaluation boundary should specify product version, market, device platform, included flows and excluded dependencies. Define whether mandatory downloaded documents and embedded payment journeys are part of the product experience. Without scope, even carefully recorded outcomes can support misleading public claims.
2. Choose the conformance target
State the WCAG version and target level being evaluated, and avoid confusing legal requirements with an individual automated scanner’s default rule set. Before drawing a conclusion, name the language, region and concrete page state under investigation. This makes an observation reproducible for someone who does not share the original tester’s browser session or assumptions. A successful process should distinguish a tool setup failure from a genuine product issue and should identify which evidence still needs human confirmation.
Choose the relevant WCAG version and target level before testing, and note additional applicable regional requirements separately. A conformance report cannot quietly switch standards between sections. State whether the purpose is internal remediation, procurement evidence or an externally shared evaluation.
3. Explore important experiences
Inventory page templates, critical journeys, media, documents, third-party components, authentication and platform variation. Before drawing a conclusion, name the language, region and concrete page state under investigation. This makes an observation reproducible for someone who does not share the original tester’s browser session or assumptions. A successful process should distinguish a tool setup failure from a genuine product issue and should identify which evidence still needs human confirmation.
Explore more than the most visited pages. Inventory templates, interactive patterns, essential transactions, support, media and account recovery. For a translation project, also note components that use different resources or layouts in different markets so a sample reflects meaningful variation.
4. Identify locale-specific behavior
Include script direction, translated form validation, regional formats, speech language switching, font coverage and text expansion as risk factors. Before drawing a conclusion, name the language, region and concrete page state under investigation. This makes an observation reproducible for someone who does not share the original tester’s browser session or assumptions. A successful process should distinguish a tool setup failure from a genuine product issue and should identify which evidence still needs human confirmation.
Document script-direction, pluralization, font coverage, input formats, long translations and speech-language changes as potential sources of risk. Sampling an English interface alone may hide an Arabic navigation problem or a Japanese font failure. Choose representative localizations for their actual differences.
5. Select representative views
Choose pages and states that cover distinct structures and functions, then add random samples where the methodology calls for them. Before drawing a conclusion, name the language, region and concrete page state under investigation. This makes an observation reproducible for someone who does not share the original tester’s browser session or assumptions. A successful process should distinguish a tool setup failure from a genuine product issue and should identify which evidence still needs human confirmation.
Structured sampling selects critical or distinct views; random sampling adds a different form of coverage. Explain why a page was chosen and what it represents. Multiple nearly identical product cards are not a substitute for a form, dialog, error state or alternative-language flow.
6. Document test procedures
Record operating systems, browsers, assistive technologies, testers, test data and relevant limitations so another evaluator can understand the basis. Before drawing a conclusion, name the language, region and concrete page state under investigation. This makes an observation reproducible for someone who does not share the original tester’s browser session or assumptions. A successful process should distinguish a tool setup failure from a genuine product issue and should identify which evidence still needs human confirmation.
Record the evaluator’s device, browser, assistive technology, test method and date where they affect interpretation. For translated products, include language proficiency and relevant market context. When expertise is missing, narrow the claim or add qualified reviewers rather than substituting confidence for evidence.
7. Evaluate actual sampled content
Apply applicable WCAG criteria through methods suited to the features, combining manual judgment with automated support where useful. Before drawing a conclusion, name the language, region and concrete page state under investigation. This makes an observation reproducible for someone who does not share the original tester’s browser session or assumptions. A successful process should distinguish a tool setup failure from a genuine product issue and should identify which evidence still needs human confirmation.
Evaluate actual content against applicable success criteria using methods appropriate to the feature. Automated findings may help, but keyboard use, screen-reader behavior, visual reflow and human understanding can require direct evaluation. Describe who checked a result and under what conditions.
8. Capture reproducible findings
For every relevant outcome, record the exact view, locale, component, behavior, evidence, effect on users and retest instructions. Before drawing a conclusion, name the language, region and concrete page state under investigation. This makes an observation reproducible for someone who does not share the original tester’s browser session or assumptions. A successful process should distinguish a tool setup failure from a genuine product issue and should identify which evidence still needs human confirmation.
A report finding should identify the sampled view, specific state, locale, criterion, observed defect, user impact and repair expectation. Record enough detail for retesting and avoid including private production data. Disputed or uncertain observations should not be turned silently into either failures or passes.
9. Build the report in the W3C tool
Enter the scope, product information, samples, outcomes and summary carefully, then review the generated statement for unsupported generalizations. Before drawing a conclusion, name the language, region and concrete page state under investigation. This makes an observation reproducible for someone who does not share the original tester’s browser session or assumptions. A successful process should distinguish a tool setup failure from a genuine product issue and should identify which evidence still needs human confirmation.
The report generator organizes the information entered by the evaluator; it does not verify it for them. Review summaries for unsupported words such as all, fully or certified when only a bounded sample was examined. Save partial JSON exports because closing the browser may discard unsaved work.
10. Export, store and review
Download HTML or JSON, protect confidential details, conduct peer review and treat changes or new product releases as reasons to revisit coverage. Before drawing a conclusion, name the language, region and concrete page state under investigation. This makes an observation reproducible for someone who does not share the original tester’s browser session or assumptions. A successful process should distinguish a tool setup failure from a genuine product issue and should identify which evidence still needs human confirmation.
Before distribution, export the HTML or JSON report, check redaction, confirm dates and scope, and ask another evaluator to review material conclusions. A later localization launch or major redesign can invalidate assumptions in the original sample; update the evaluation rather than extending its claim automatically.
24 field cases: multilingual problems, investigation and repair
The following exercises are separate test situations rather than a declaration that the tool will automatically catch every condition described. Each one joins an observable localization problem to a check that can be reproduced and a repair that can be independently confirmed. Some require visual, keyboard, semantic, linguistic or assistive-technology work in addition to WCAG-EM 2.0 Report Tool. That boundary is essential: an auditor should not label an issue automatically checked if a human found it by another method.
Case 01: Entire site claim from one homepage
Situation and user risk. A realistic test begins with the user, not the dashboard. A team evaluates its English landing page and prepares to claim WCAG conformance across forty translated markets. The central question is whether someone working in the target language can recognize the necessary information and complete the intended action without guessing. A component can look polished in a design review while its spoken name, relationship or behavior fails under a different script, viewport or state.
Investigation. Compare the proposed statement against the actual scope and the selected sample diversity. Apply the W3C WCAG Evaluation Methodology and its browser-based report generator to the relevant state when the mechanism supports the check, and use an independent manual test when it does not. Preserve the route, language tag, browser or platform, build, viewport and exact triggering action. If a reported element is hidden or the route redirected, establish that fact before attributing the result to the target interface.
Repair and acceptance. Limit the statement or expand evaluation to representative localized structures and tasks before publication. For sign-off, repeat the original action with the changed component and compare at least one neighboring language or layout where a shared implementation could regress. Record whether the fix addresses programmatic semantics, wording, layout or a combination; no one-line status such as passed can replace that distinction.
Case 02: Translated checkout excluded without notice
Situation and user risk. This situation is especially easy to miss when product teams copy a source-language screenshot into a translation ticket. A high-impact localized checkout is operated by another vendor and silently omitted from the report. The important evidence is the actual localized interaction, including the words a person encounters, the order in which controls appear and the consequence of making a selection. A faithful translation cannot rescue a component whose behavior is inaccessible.
Investigation. Inventory third-party interactions and record who owns each required step of the purchase task. Apply the W3C WCAG Evaluation Methodology and its browser-based report generator to the relevant state when the mechanism supports the check, and use an independent manual test when it does not. Preserve the route, language tag, browser or platform, build, viewport and exact triggering action. If a reported element is hidden or the route redirected, establish that fact before attributing the result to the target interface.
Repair and acceptance. Declare boundaries transparently and evaluate essential dependencies rather than hiding the purchase barrier. For sign-off, repeat the original action with the changed component and compare at least one neighboring language or layout where a shared implementation could regress. Record whether the fix addresses programmatic semantics, wording, layout or a combination; no one-line status such as passed can replace that distinction.
Case 03: Mobile app omitted from scope
Situation and user risk. Here is a useful quality-assurance exercise for a world-facing interface: An organization calls its evaluation a digital-service audit while testing only the desktop website. Rather than assigning the entire problem to a translator or engineer immediately, separate what is visibly wrong from what can be established through inspection. That prevents a wording change from hiding a structural defect or a markup fix from leaving an incorrect instruction in place.
Investigation. Name each digital product and platform in the scope and identify which variants share code and which do not. Apply the W3C WCAG Evaluation Methodology and its browser-based report generator to the relevant state when the mechanism supports the check, and use an independent manual test when it does not. Preserve the route, language tag, browser or platform, build, viewport and exact triggering action. If a reported element is hidden or the route redirected, establish that fact before attributing the result to the target interface.
Repair and acceptance. Create a defensible evaluation boundary and separate findings for untested native-app components. For sign-off, repeat the original action with the changed component and compare at least one neighboring language or layout where a shared implementation could regress. Record whether the fix addresses programmatic semantics, wording, layout or a combination; no one-line status such as passed can replace that distinction.
Case 04: Arabic version has unique layout
Situation and user risk. A realistic test begins with the user, not the dashboard. A right-to-left interface has rearranged navigation and control placement compared with the tested English page. The central question is whether someone working in the target language can recognize the necessary information and complete the intended action without guessing. A component can look polished in a design review while its spoken name, relationship or behavior fails under a different script, viewport or state.
Investigation. Include RTL-specific views and navigation states in the representative sample and describe their distinctive technology. Apply the W3C WCAG Evaluation Methodology and its browser-based report generator to the relevant state when the mechanism supports the check, and use an independent manual test when it does not. Preserve the route, language tag, browser or platform, build, viewport and exact triggering action. If a reported element is hidden or the route redirected, establish that fact before attributing the result to the target interface.
Repair and acceptance. Test actual visual, keyboard and spoken order before generalizing from left-to-right templates. For sign-off, repeat the original action with the changed component and compare at least one neighboring language or layout where a shared implementation could regress. Record whether the fix addresses programmatic semantics, wording, layout or a combination; no one-line status such as passed can replace that distinction.
Case 05: Regional form rules differ
Situation and user risk. This situation is especially easy to miss when product teams copy a source-language screenshot into a translation ticket. French-Canadian customer registration has different consent language and address validation than French-France registration. The important evidence is the actual localized interaction, including the words a person encounters, the order in which controls appear and the consequence of making a selection. A faithful translation cannot rescue a component whose behavior is inaccessible.
Investigation. Explore data-entry rules, legal notices and error states in both region-specific versions. Apply the W3C WCAG Evaluation Methodology and its browser-based report generator to the relevant state when the mechanism supports the check, and use an independent manual test when it does not. Preserve the route, language tag, browser or platform, build, viewport and exact triggering action. If a reported element is hidden or the route redirected, establish that fact before attributing the result to the target interface.
Repair and acceptance. Sample materially different variants and document the jurisdiction and accepted data format for each. For sign-off, repeat the original action with the changed component and compare at least one neighboring language or layout where a shared implementation could regress. Record whether the fix addresses programmatic semantics, wording, layout or a combination; no one-line status such as passed can replace that distinction.
Case 06: Long-tail pages overwhelm sampling
Situation and user risk. Here is a useful quality-assurance exercise for a world-facing interface: The site has thousands of articles using a few templates, and reviewers consider reading every article equally. Rather than assigning the entire problem to a translator or engineer immediately, separate what is visibly wrong from what can be established through inspection. That prevents a wording change from hiding a structural defect or a markup fix from leaving an incorrect instruction in place.
Investigation. Group views by structural and functional properties, then select meaningful and random examples as appropriate. Apply the W3C WCAG Evaluation Methodology and its browser-based report generator to the relevant state when the mechanism supports the check, and use an independent manual test when it does not. Preserve the route, language tag, browser or platform, build, viewport and exact triggering action. If a reported element is hidden or the route redirected, establish that fact before attributing the result to the target interface.
Repair and acceptance. Use representative coverage while acknowledging content-specific issues that a sample cannot eliminate. For sign-off, repeat the original action with the changed component and compare at least one neighboring language or layout where a shared implementation could regress. Record whether the fix addresses programmatic semantics, wording, layout or a combination; no one-line status such as passed can replace that distinction.
Case 07: Single page contains multiple states
Situation and user risk. A realistic test begins with the user, not the dashboard. The report lists a route but never records that its modal, menu or error state was evaluated. The central question is whether someone working in the target language can recognize the necessary information and complete the intended action without guessing. A component can look polished in a design review while its spoken name, relationship or behavior fails under a different script, viewport or state.
Investigation. Document interactive states separately and tie findings to the actual state in which they occur. Apply the W3C WCAG Evaluation Methodology and its browser-based report generator to the relevant state when the mechanism supports the check, and use an independent manual test when it does not. Preserve the route, language tag, browser or platform, build, viewport and exact triggering action. If a reported element is hidden or the route redirected, establish that fact before attributing the result to the target interface.
Repair and acceptance. Include at least one relevant state per critical pattern and verify changes after user actions. For sign-off, repeat the original action with the changed component and compare at least one neighboring language or layout where a shared implementation could regress. Record whether the fix addresses programmatic semantics, wording, layout or a combination; no one-line status such as passed can replace that distinction.
Case 08: Language switching breaks focus
Situation and user risk. This situation is especially easy to miss when product teams copy a source-language screenshot into a translation ticket. A language picker replaces the page but moves keyboard focus unpredictably, though the final translated page scans clean. The important evidence is the actual localized interaction, including the words a person encounters, the order in which controls appear and the consequence of making a selection. A faithful translation cannot rescue a component whose behavior is inaccessible.
Investigation. Test the switching interaction itself rather than evaluating only the two static endpoint pages. Apply the W3C WCAG Evaluation Methodology and its browser-based report generator to the relevant state when the mechanism supports the check, and use an independent manual test when it does not. Preserve the route, language tag, browser or platform, build, viewport and exact triggering action. If a reported element is hidden or the route redirected, establish that fact before attributing the result to the target interface.
Repair and acceptance. Describe the lost-focus barrier and retest the full transition between language versions. For sign-off, repeat the original action with the changed component and compare at least one neighboring language or layout where a shared implementation could regress. Record whether the fix addresses programmatic semantics, wording, layout or a combination; no one-line status such as passed can replace that distinction.
Case 09: Video captions vary by locale
Situation and user risk. Here is a useful quality-assurance exercise for a world-facing interface: The English video has captions but its German variant contains untranslated captions and missing speaker information. Rather than assigning the entire problem to a translator or engineer immediately, separate what is visibly wrong from what can be established through inspection. That prevents a wording change from hiding a structural defect or a markup fix from leaving an incorrect instruction in place.
Investigation. Inventory media versions in the sample, including language-specific caption and transcript assets. Apply the W3C WCAG Evaluation Methodology and its browser-based report generator to the relevant state when the mechanism supports the check, and use an independent manual test when it does not. Preserve the route, language tag, browser or platform, build, viewport and exact triggering action. If a reported element is hidden or the route redirected, establish that fact before attributing the result to the target interface.
Repair and acceptance. Record distinct outcomes for actual media alternatives rather than assuming inheritance from the source version. For sign-off, repeat the original action with the changed component and compare at least one neighboring language or layout where a shared implementation could regress. Record whether the fix addresses programmatic semantics, wording, layout or a combination; no one-line status such as passed can replace that distinction.
Case 10: A PDF is treated as outside the journey
Situation and user risk. A realistic test begins with the user, not the dashboard. A multilingual application asks customers to download a required contract that was omitted from the web-page review. The central question is whether someone working in the target language can recognize the necessary information and complete the intended action without guessing. A component can look polished in a design review while its spoken name, relationship or behavior fails under a different script, viewport or state.
Investigation. Map tasks that depend on downloadable documents and define whether those assets are in scope. Apply the W3C WCAG Evaluation Methodology and its browser-based report generator to the relevant state when the mechanism supports the check, and use an independent manual test when it does not. Preserve the route, language tag, browser or platform, build, viewport and exact triggering action. If a reported element is hidden or the route redirected, establish that fact before attributing the result to the target interface.
Repair and acceptance. Include required documents in the evaluation or explicitly report the limitation and related user risk. For sign-off, repeat the original action with the changed component and compare at least one neighboring language or layout where a shared implementation could regress. Record whether the fix addresses programmatic semantics, wording, layout or a combination; no one-line status such as passed can replace that distinction.
Case 11: A screen-reader sample is too narrow
Situation and user risk. This situation is especially easy to miss when product teams copy a source-language screenshot into a translation ticket. The team uses a single configuration and assumes identical speech behavior across every script and platform. The important evidence is the actual localized interaction, including the words a person encounters, the order in which controls appear and the consequence of making a selection. A faithful translation cannot rescue a component whose behavior is inaccessible.
Investigation. Record tested assistive technologies and identify where additional script or platform testing matters. Apply the W3C WCAG Evaluation Methodology and its browser-based report generator to the relevant state when the mechanism supports the check, and use an independent manual test when it does not. Preserve the route, language tag, browser or platform, build, viewport and exact triggering action. If a reported element is hidden or the route redirected, establish that fact before attributing the result to the target interface.
Repair and acceptance. Make a bounded observation and involve reviewers familiar with the target language and technology. For sign-off, repeat the original action with the changed component and compare at least one neighboring language or layout where a shared implementation could regress. Record whether the fix addresses programmatic semantics, wording, layout or a combination; no one-line status such as passed can replace that distinction.
Case 12: Random sample repeats one template
Situation and user risk. Here is a useful quality-assurance exercise for a world-facing interface: A nominal random sample selects five product cards while missing account recovery and support forms. Rather than assigning the entire problem to a translator or engineer immediately, separate what is visibly wrong from what can be established through inspection. That prevents a wording change from hiding a structural defect or a markup fix from leaving an incorrect instruction in place.
Investigation. Separate structured representative selection from random selection and document why each is included. Apply the W3C WCAG Evaluation Methodology and its browser-based report generator to the relevant state when the mechanism supports the check, and use an independent manual test when it does not. Preserve the route, language tag, browser or platform, build, viewport and exact triggering action. If a reported element is hidden or the route redirected, establish that fact before attributing the result to the target interface.
Repair and acceptance. Adjust the sample to cover distinct tasks and structures while retaining the appropriate random component. For sign-off, repeat the original action with the changed component and compare at least one neighboring language or layout where a shared implementation could regress. Record whether the fix addresses programmatic semantics, wording, layout or a combination; no one-line status such as passed can replace that distinction.
Case 13: A confirmation label is mistranslated
Situation and user risk. A realistic test begins with the user, not the dashboard. The payment flow is programmatically accessible but the localized message says the transaction failed when it succeeded. The central question is whether someone working in the target language can recognize the necessary information and complete the intended action without guessing. A component can look polished in a design review while its spoken name, relationship or behavior fails under a different script, viewport or state.
Investigation. Separate WCAG-related evidence from the related translation defect, while documenting the serious real-world consequence. Apply the W3C WCAG Evaluation Methodology and its browser-based report generator to the relevant state when the mechanism supports the check, and use an independent manual test when it does not. Preserve the route, language tag, browser or platform, build, viewport and exact triggering action. If a reported element is hidden or the route redirected, establish that fact before attributing the result to the target interface.
Repair and acceptance. Correct meaning and include a product-language QA outcome without pretending the report tool itself diagnosed the mistake. For sign-off, repeat the original action with the changed component and compare at least one neighboring language or layout where a shared implementation could regress. Record whether the fix addresses programmatic semantics, wording, layout or a combination; no one-line status such as passed can replace that distinction.
Case 14: Different WCAG targets are mixed
Situation and user risk. This situation is especially easy to miss when product teams copy a source-language screenshot into a translation ticket. One section cites WCAG 2.1 AA and another uses a WCAG 2.2 criterion without explanation. The important evidence is the actual localized interaction, including the words a person encounters, the order in which controls appear and the consequence of making a selection. A faithful translation cannot rescue a component whose behavior is inaccessible.
Investigation. Define the selected standard and level consistently before the evaluation and review all assertions. Apply the W3C WCAG Evaluation Methodology and its browser-based report generator to the relevant state when the mechanism supports the check, and use an independent manual test when it does not. Preserve the route, language tag, browser or platform, build, viewport and exact triggering action. If a reported element is hidden or the route redirected, establish that fact before attributing the result to the target interface.
Repair and acceptance. Explain supplementary checks separately so readers know which conformance basis supports the evaluation statement. For sign-off, repeat the original action with the changed component and compare at least one neighboring language or layout where a shared implementation could regress. Record whether the fix addresses programmatic semantics, wording, layout or a combination; no one-line status such as passed can replace that distinction.
Case 15: A count becomes a misleading score
Situation and user risk. Here is a useful quality-assurance exercise for a world-facing interface: Management wants one percentage derived from diverse audit findings, with no accounting for user impact or scope. Rather than assigning the entire problem to a translator or engineer immediately, separate what is visibly wrong from what can be established through inspection. That prevents a wording change from hiding a structural defect or a markup fix from leaving an incorrect instruction in place.
Investigation. Review the report’s evaluation findings and aggregation method before generating an executive summary. Apply the W3C WCAG Evaluation Methodology and its browser-based report generator to the relevant state when the mechanism supports the check, and use an independent manual test when it does not. Preserve the route, language tag, browser or platform, build, viewport and exact triggering action. If a reported element is hidden or the route redirected, establish that fact before attributing the result to the target interface.
Repair and acceptance. Present limitations, critical blockers and task impact alongside any supported summary rather than manufacturing certainty. For sign-off, repeat the original action with the changed component and compare at least one neighboring language or layout where a shared implementation could regress. Record whether the fix addresses programmatic semantics, wording, layout or a combination; no one-line status such as passed can replace that distinction.
Case 16: Finding cannot be reproduced
Situation and user risk. A realistic test begins with the user, not the dashboard. An auditor reports a missing name without noting which language, dialog or field version caused it. The central question is whether someone working in the target language can recognize the necessary information and complete the intended action without guessing. A component can look polished in a design review while its spoken name, relationship or behavior fails under a different script, viewport or state.
Investigation. Record an affected view, test data, locale, interaction sequence and expected programmatic relationship. Apply the W3C WCAG Evaluation Methodology and its browser-based report generator to the relevant state when the mechanism supports the check, and use an independent manual test when it does not. Preserve the route, language tag, browser or platform, build, viewport and exact triggering action. If a reported element is hidden or the route redirected, establish that fact before attributing the result to the target interface.
Repair and acceptance. Require a retest using the same conditions and add evidence of whether the repair succeeded. For sign-off, repeat the original action with the changed component and compare at least one neighboring language or layout where a shared implementation could regress. Record whether the fix addresses programmatic semantics, wording, layout or a combination; no one-line status such as passed can replace that distinction.
Case 17: Tool data is lost on closing tab
Situation and user risk. This situation is especially easy to miss when product teams copy a source-language screenshot into a translation ticket. A long report is completed in the browser and the operator closes it without exporting an intermediate file. The important evidence is the actual localized interaction, including the words a person encounters, the order in which controls appear and the consequence of making a selection. A faithful translation cannot rescue a component whose behavior is inaccessible.
Investigation. Verify how the W3C report tool stores data and plan explicit save checkpoints during the session. Apply the W3C WCAG Evaluation Methodology and its browser-based report generator to the relevant state when the mechanism supports the check, and use an independent manual test when it does not. Preserve the route, language tag, browser or platform, build, viewport and exact triggering action. If a reported element is hidden or the route redirected, establish that fact before attributing the result to the target interface.
Repair and acceptance. Download a partial JSON report at milestones and keep copies in controlled project storage. For sign-off, repeat the original action with the changed component and compare at least one neighboring language or layout where a shared implementation could regress. Record whether the fix addresses programmatic semantics, wording, layout or a combination; no one-line status such as passed can replace that distinction.
Case 18: HTML report exposes customer data
Situation and user risk. Here is a useful quality-assurance exercise for a world-facing interface: A screenshot and sampled URL contain identifiable medical or financial details within an otherwise public audit. Rather than assigning the entire problem to a translator or engineer immediately, separate what is visibly wrong from what can be established through inspection. That prevents a wording change from hiding a structural defect or a markup fix from leaving an incorrect instruction in place.
Investigation. Review evidence, attachments and exported fields for sensitive records before sharing with stakeholders. Apply the W3C WCAG Evaluation Methodology and its browser-based report generator to the relevant state when the mechanism supports the check, and use an independent manual test when it does not. Preserve the route, language tag, browser or platform, build, viewport and exact triggering action. If a reported element is hidden or the route redirected, establish that fact before attributing the result to the target interface.
Repair and acceptance. Replace production examples with consented or synthetic data while retaining enough detail to reproduce defects. For sign-off, repeat the original action with the changed component and compare at least one neighboring language or layout where a shared implementation could regress. Record whether the fix addresses programmatic semantics, wording, layout or a combination; no one-line status such as passed can replace that distinction.
Case 19: Evidence comes only from scanners
Situation and user risk. A realistic test begins with the user, not the dashboard. The evaluation file consists of automated rule outputs but claims to cover keyboard journeys and speech use. The central question is whether someone working in the target language can recognize the necessary information and complete the intended action without guessing. A component can look polished in a design review while its spoken name, relationship or behavior fails under a different script, viewport or state.
Investigation. Cross-check each claimed method against notes, evaluator expertise and completed test records. Apply the W3C WCAG Evaluation Methodology and its browser-based report generator to the relevant state when the mechanism supports the check, and use an independent manual test when it does not. Preserve the route, language tag, browser or platform, build, viewport and exact triggering action. If a reported element is hidden or the route redirected, establish that fact before attributing the result to the target interface.
Repair and acceptance. Add the missing hands-on testing or narrow the claim to automated checks actually performed. For sign-off, repeat the original action with the changed component and compare at least one neighboring language or layout where a shared implementation could regress. Record whether the fix addresses programmatic semantics, wording, layout or a combination; no one-line status such as passed can replace that distinction.
Case 20: Retest changes the evaluated build
Situation and user risk. This situation is especially easy to miss when product teams copy a source-language screenshot into a translation ticket. An issue is marked fixed using a later website release with major unrelated changes, making the original findings difficult to compare. The important evidence is the actual localized interaction, including the words a person encounters, the order in which controls appear and the consequence of making a selection. A faithful translation cannot rescue a component whose behavior is inaccessible.
Investigation. Record release identifier, environment and exact test conditions for both baseline and retest. Apply the W3C WCAG Evaluation Methodology and its browser-based report generator to the relevant state when the mechanism supports the check, and use an independent manual test when it does not. Preserve the route, language tag, browser or platform, build, viewport and exact triggering action. If a reported element is hidden or the route redirected, establish that fact before attributing the result to the target interface.
Repair and acceptance. Separate the old evaluation from a new release assessment and state which findings were independently verified. For sign-off, repeat the original action with the changed component and compare at least one neighboring language or layout where a shared implementation could regress. Record whether the fix addresses programmatic semantics, wording, layout or a combination; no one-line status such as passed can replace that distinction.
Case 21: Public statement ignores exclusions
Situation and user risk. Here is a useful quality-assurance exercise for a world-facing interface: The report title implies every language meets AA despite explicit exclusions in the detailed annex. Rather than assigning the entire problem to a translator or engineer immediately, separate what is visibly wrong from what can be established through inspection. That prevents a wording change from hiding a structural defect or a markup fix from leaving an incorrect instruction in place.
Investigation. Compare the executive wording and proposed conformance statement with scope and unresolved issues. Apply the W3C WCAG Evaluation Methodology and its browser-based report generator to the relevant state when the mechanism supports the check, and use an independent manual test when it does not. Preserve the route, language tag, browser or platform, build, viewport and exact triggering action. If a reported element is hidden or the route redirected, establish that fact before attributing the result to the target interface.
Repair and acceptance. Publish a qualified, understandable statement that communicates material limits without hiding them. For sign-off, repeat the original action with the changed component and compare at least one neighboring language or layout where a shared implementation could regress. Record whether the fix addresses programmatic semantics, wording, layout or a combination; no one-line status such as passed can replace that distinction.
Case 22: Severity misses essential task impact
Situation and user risk. A realistic test begins with the user, not the dashboard. A small number of failures blocks a government benefits application, while dozens of minor issues fill the summary. The central question is whether someone working in the target language can recognize the necessary information and complete the intended action without guessing. A component can look polished in a design review while its spoken name, relationship or behavior fails under a different script, viewport or state.
Investigation. Analyze effect on core tasks and impacted users rather than relying solely on counts. Apply the W3C WCAG Evaluation Methodology and its browser-based report generator to the relevant state when the mechanism supports the check, and use an independent manual test when it does not. Preserve the route, language tag, browser or platform, build, viewport and exact triggering action. If a reported element is hidden or the route redirected, establish that fact before attributing the result to the target interface.
Repair and acceptance. Highlight blockers and remediation priorities clearly while preserving technically precise criterion-level findings. For sign-off, repeat the original action with the changed component and compare at least one neighboring language or layout where a shared implementation could regress. Record whether the fix addresses programmatic semantics, wording, layout or a combination; no one-line status such as passed can replace that distinction.
Case 23: Stakeholders misunderstand not applicable
Situation and user risk. This situation is especially easy to miss when product teams copy a source-language screenshot into a translation ticket. An item recorded as not applicable is celebrated as a tested pass even though the feature was absent. The important evidence is the actual localized interaction, including the words a person encounters, the order in which controls appear and the consequence of making a selection. A faithful translation cannot rescue a component whose behavior is inaccessible.
Investigation. Explain the outcome category and whether the sample actually contained the relevant feature. Apply the W3C WCAG Evaluation Methodology and its browser-based report generator to the relevant state when the mechanism supports the check, and use an independent manual test when it does not. Preserve the route, language tag, browser or platform, build, viewport and exact triggering action. If a reported element is hidden or the route redirected, establish that fact before attributing the result to the target interface.
Repair and acceptance. Do not report absent features as evidence that a complex implementation meets the criterion. For sign-off, repeat the original action with the changed component and compare at least one neighboring language or layout where a shared implementation could regress. Record whether the fix addresses programmatic semantics, wording, layout or a combination; no one-line status such as passed can replace that distinction.
Case 24: New translation launch has no baseline
Situation and user risk. Here is a useful quality-assurance exercise for a world-facing interface: A new locale is added after an earlier conformance report and inherits the old public statement without testing. Rather than assigning the entire problem to a translator or engineer immediately, separate what is visibly wrong from what can be established through inspection. That prevents a wording change from hiding a structural defect or a markup fix from leaving an incorrect instruction in place.
Investigation. Check evaluation dates and scope against release history and locale inventory changes. Apply the W3C WCAG Evaluation Methodology and its browser-based report generator to the relevant state when the mechanism supports the check, and use an independent manual test when it does not. Preserve the route, language tag, browser or platform, build, viewport and exact triggering action. If a reported element is hidden or the route redirected, establish that fact before attributing the result to the target interface.
Repair and acceptance. Schedule a targeted new evaluation and update the scope and findings before expanding the claim. For sign-off, repeat the original action with the changed component and compare at least one neighboring language or layout where a shared implementation could regress. Record whether the fix addresses programmatic semantics, wording, layout or a combination; no one-line status such as passed can replace that distinction.
How to interpret results without overstating them
A raw finding total is a count of observations under a given evaluation configuration. It is not necessarily a count of unique user barriers: one broken component may produce several alerts, and the same shared template may recur across many routes. Conversely, a small count does not mean low risk if a single unlabelled payment control prevents a user from completing a necessary transaction. Inspect the underlying elements, explain the task consequence, and group duplicates by genuine root cause without discarding evidence from affected languages.
Use at least three levels of certainty in the issue register. A confirmed defect has a reproducible observation and an applicable accessibility or language requirement. A needs-review item is a signal whose relevance or impact requires human judgment. An environment or coverage gap means the intended product state was not evaluated; for example, a login redirect or a missing translation bundle. Treating the third category as a pass makes release statistics unreliable.
For each high-impact finding, write a short user-centered statement: what action the person intended, what the interface communicated or failed to communicate, what was observed, and what must change. Add a minimal reproduction path, a stable reference to the affected component, the source of the observation and the retest. A native speaker should confirm meaning; a keyboard or assistive-technology tester should confirm operation where relevant; and an engineer should explain the technical correction in terms a non-engineer can verify.
A multilingual coverage matrix worth maintaining
Do not multiply language count by page count and assume the result represents complete coverage. Choose locales according to script, direction, market configuration, route variation, fonts, plural rules and business risk. A representative sampling plan can include an English baseline, a long-word language, a right-to-left language, a CJK layout, a language requiring combining marks, and a region where data formats or legal wording differ. These are examples of risk dimensions, not a claim that one language automatically represents every other language in its family.
- Routes: home, sign-in, recovery, checkout or application, account settings and help, with localized errors and confirmation states.
- Scripts: Latin, non-Latin and mixed-direction content where the product actually supports them, including realistic personal names and addresses.
- Layouts: phone, tablet, desktop, zoomed text and reduced available height where controls can be clipped.
- Actions: keyboard navigation, focus, field validation, dialogs, disclosures, menus, tables and links.
- Meaning: money, deadlines, destructive actions, consent, status, next steps and user-generated strings.
- Evidence: tested build, route, locale, state, tool version, issue, owner, remediation and retest.
A good release report can be compact even when the underlying testing is substantial. It should say which product and build were examined, which locales and critical tasks were represented, which checks were automated, which were performed manually, and which issues remain open. Include clear exclusions and owners. If an important locale could not be tested, describe that limitation directly instead of turning missing evidence into an optimistic conclusion.
Frequently asked questions
Does the WCAG-EM Report Tool scan pages automatically?
No. It is a report generator, not an accessibility checker. Evaluators supply findings and supporting context. The most useful next step is to connect that answer to a specific user journey and a recorded test condition. Check the actual target-language content, note the criterion or product expectation at issue, and make the result repeatable rather than relying on an isolated score. A human review remains important wherever the decision depends on language, meaning, usability or lived assistive-technology experience.
What changed in WCAG-EM 2.0?
The W3C methodology published on 23 July 2026 applies to digital products including apps, not just websites and web pages. The most useful next step is to connect that answer to a specific user journey and a recorded test condition. Check the actual target-language content, note the criterion or product expectation at issue, and make the result repeatable rather than relying on an isolated score. A human review remains important wherever the decision depends on language, meaning, usability or lived assistive-technology experience.
What are the five major steps?
Define scope, explore the product, select a representative sample, evaluate that sample, and report the findings. The most useful next step is to connect that answer to a specific user journey and a recorded test condition. Check the actual target-language content, note the criterion or product expectation at issue, and make the result repeatable rather than relying on an isolated score. A human review remains important wherever the decision depends on language, meaning, usability or lived assistive-technology experience.
Must every translated page be tested?
A defensible representative sample can be appropriate, but it must reflect important structures, language risks and required user journeys. Its limitations must be stated. The most useful next step is to connect that answer to a specific user journey and a recorded test condition. Check the actual target-language content, note the criterion or product expectation at issue, and make the result repeatable rather than relying on an isolated score. A human review remains important wherever the decision depends on language, meaning, usability or lived assistive-technology experience.
Can I use automated scanners as evidence?
Yes, for the checks they actually perform. Complement them with manual and assistive-technology evaluation where needed. The most useful next step is to connect that answer to a specific user journey and a recorded test condition. Check the actual target-language content, note the criterion or product expectation at issue, and make the result repeatable rather than relying on an isolated score. A human review remains important wherever the decision depends on language, meaning, usability or lived assistive-technology experience.
How is the report saved?
The W3C tool runs in the browser and provides HTML and JSON exports. Download partial reports to prevent loss when the session closes. The most useful next step is to connect that answer to a specific user journey and a recorded test condition. Check the actual target-language content, note the criterion or product expectation at issue, and make the result repeatable rather than relying on an isolated score. A human review remains important wherever the decision depends on language, meaning, usability or lived assistive-technology experience.
Does the tool issue a certificate?
No. It helps produce a structured evaluation report; the quality and scope of evidence remain the evaluator’s responsibility. The most useful next step is to connect that answer to a specific user journey and a recorded test condition. Check the actual target-language content, note the criterion or product expectation at issue, and make the result repeatable rather than relying on an isolated score. A human review remains important wherever the decision depends on language, meaning, usability or lived assistive-technology experience.
Can I evaluate a mobile app?
WCAG-EM 2.0 is framed for digital products including apps. Define the platform and applicable methods precisely. The most useful next step is to connect that answer to a specific user journey and a recorded test condition. Check the actual target-language content, note the criterion or product expectation at issue, and make the result repeatable rather than relying on an isolated score. A human review remains important wherever the decision depends on language, meaning, usability or lived assistive-technology experience.
How should locales appear in the report?
Identify covered languages, regional variants and sample views, with any excluded or untested variations clearly described. The most useful next step is to connect that answer to a specific user journey and a recorded test condition. Check the actual target-language content, note the criterion or product expectation at issue, and make the result repeatable rather than relying on an isolated score. A human review remains important wherever the decision depends on language, meaning, usability or lived assistive-technology experience.
How should a reader interpret conformance claims?
Read the scope, standard, target level, test methods, sample and exclusions together; avoid stronger claims than the report demonstrates. The most useful next step is to connect that answer to a specific user journey and a recorded test condition. Check the actual target-language content, note the criterion or product expectation at issue, and make the result repeatable rather than relying on an isolated score. A human review remains important wherever the decision depends on language, meaning, usability or lived assistive-technology experience.
Sources, standards and further reading
For technical behavior and current installation details, prefer the maintained project documentation and published standards. Tool releases change, and the scope of a rule is not always obvious from its short result label. The following are source references for the workflow; they are not endorsements or a substitute for reproducing a finding on your own product.
For complementary workflows, compare the following established eduKate guides rather than repeating their scope in this one:
The standard for a practical, reader-serving guide is simple: state what the reader can do, explain what the evidence means, show an example that could fail in the real world, and leave a clear route to a reliable next action. For multilingual accessibility, a translated product is finished only when its information and functions remain understandable and usable for the people it serves. Keep the automated report, the human judgment and the actual user outcome visible as separate but connected parts of that work.