ARC Toolkit is a developer-tools accessibility extension that helps teams investigate WCAG-related issues in the page they are actually viewing. This ARC Toolkit tutorial explains how to open its DevTools panel, run checks, select a finding, inspect the affected HTML element and connect the result to a real multilingual user journey rather than treating a browser scan as a complete accessibility audit.
Multilingual accessibility testing matters because changes to language, line length, script direction and localized components can create new failures in otherwise stable interfaces. ARC Toolkit uses TPGi’s ARC rules and presents results alongside the browser’s Elements view, making it particularly useful for an engineer diagnosing a reported issue and a language reviewer explaining what the user was meant to understand.
The guide walks through installation, error and alert triage, inspection of nested interfaces and frames, language switching, translated forms, visual reflow and release evidence. It also makes clear what remains outside any automated test: intended meaning, culturally appropriate wording, keyboard task completion and the experience of people using assistive technology.
- What to do first: define a meaningful user task, choose the correct language and reproduce the relevant page state.
- What this guide covers: mapping automated findings back to source elements, frames, visual states and repair priorities.
- 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 ARC Toolkit actually does
Install ARC Toolkit from a supported browser’s official extension listing. The extension can be accessed through browser developer tools; open the page, open DevTools and locate the ARC Toolkit panel, sometimes under additional tabs. Start the tests on the specific UI state you care about. The available options and issue categories may change with releases, so rely on the panel labels in the installation you have.
The published ARC Toolkit listing describes tests in its panel and page, individually toggled issue categories and inspection links into the Elements panel. That relationship between a finding and the source element is the heart of a good debugging workflow. The tool can also work with frames, but a complex embedded flow still needs direct task testing and attention to restrictions imposed by third-party content.
Treat errors, alerts and best-practice suggestions with different degrees of certainty and urgency. An apparent best practice item is not automatically a standards failure; an alert may need manual investigation; and a detectable error still needs a small, clear fix and a retest. The most severe issue may be a translated confirmation button that hides at large text size, even if a different error appears first in the scan report.
ARC Toolkit is most valuable here as an interactive investigation panel: select a detected issue, find its element, reproduce the relevant translated state and verify the repair. A scanner overview or a standalone automation runner would solve a different problem.
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. Start with a supported browser
Install the extension and open the DevTools panel on a test page you are permitted to inspect. Record the browser and extension release used. 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.
Start by opening ARC Toolkit through the browser’s developer-tools interface, including the overflow menu when the panel is not visible. Ensure the extension is permitted on that site. Test a harmless known page first so an empty result is not confused with a failure to initialize.
2. Choose a particular locale
Navigate through the application’s own locale control or localized URL and confirm the right content and direction load. 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 useful audit target might be an Arabic address form after rejection or a Spanish returns dialog after selecting a reason. Identify the particular visible control and expected action; otherwise an auditor may spend time on incidental warnings while the important workflow remains unusable.
3. Open the state that causes the defect
Select a tab, expand a section, display an error, or open an embedded widget before starting the scan. 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.
Changing the browser’s user-interface language is not equivalent to using the application’s localized route. Confirm actual translation content, direction attributes, font rendering and data formats. Preserve a screenshot and URL showing the market variant, especially where regional rules affect a form.
4. Run ARC checks
Use the panel’s testing control, then review the issue categories and affected elements rather than interpreting one summary count. 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.
Open the exact interface before scanning: a select menu, expanded accordion, submitted error or third-party checkout frame. For a dynamic page, wait until relevant content appears. If a component vanishes after a few seconds, complement ARC’s snapshot with interaction evidence.
5. Filter for a coherent issue class
Isolate the category under investigation so an engineer is not distracted by unrelated components on a long page. 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.
Run tests and inspect the reported categories deliberately. Some outputs are clear-cut errors; others suggest investigation or best-practice improvements. Select individual results instead of assuming that counts correlate with impact, and record whether the panel ran on the host page or the expected frame.
6. Select the HTML target
Follow the available inspection action into DevTools Elements and compare the rendered markup with the visible translated interface. 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 connection from a finding to an Elements-panel node is a practical diagnostic advantage. Inspect headings, attributes, hidden duplicate labels, actual CSS and surrounding text. If the target belongs to a generated component, fix its source template rather than applying a one-off DOM change in DevTools.
7. Review frames deliberately
Record whether the issue belongs to the host document, an internal iframe or a third-party interface with a separate owner. 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.
On pages with embedded services, distinguish host-document defects from a widget maintained by another provider. Capture the frame’s identity and version, and test the full customer journey. The owner of a code change may differ from the team responsible for providing the overall accessible service.
8. Test responsive and zoomed states
Make the same interaction possible at smaller viewport sizes and greater text sizes, with no clipped primary actions. 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 small-width or enlarged-text run can reveal problems that an ordinary desktop view hides. Examine overlays, tab order and clipping after translation expansion. If the chosen color is uncertain because of imagery or opacity, do a manual contrast evaluation in the actual rendered context.
9. Prioritize and fix at the source
Determine whether the repair belongs to a shared component, locale string, style token, dependency or editor-authored content. 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.
After a repair, return to the same route, state, size and browser version, then select the original element again. Check whether other controls share the faulty component. A changed alert count is useful but weaker evidence than confirming the corrected state and successful user action.
10. Rescan and perform a manual pass
Verify the specific fixed element, then keyboard-test the journey and ask a language reviewer to confirm the translated result. 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.
Finish with keyboard access, screen reading where relevant and actual language review. ARC results inform the technical investigation; they do not decide whether a French instruction communicates the right deadline or whether a Japanese user can comfortably finish the form.
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 ARC Toolkit. That boundary is essential: an auditor should not label an issue automatically checked if a human found it by another method.
Case 01: ARC panel is missing
Situation and user risk. A realistic test begins with the user, not the dashboard. The extension is installed but the developer tools panel is hidden among additional tool tabs. 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. Verify the extension is enabled for the browser and origin, reopen DevTools and check the overflow for its panel. Apply the TPGi ARC rules and developer-tools inspection workflow 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. Document the supported installation route rather than assuming a missing panel means the website passed an audit. 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: A finding points to a hidden template
Situation and user risk. This situation is especially easy to miss when product teams copy a source-language screenshot into a translation ticket. The selected element belongs to a nonactive dialog clone and never appears to users in the current journey. 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. Inspect its actual DOM state and determine whether that template will later become active. Apply the TPGi ARC rules and developer-tools inspection workflow 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. Repair reusable markup when needed, and retest once the associated dialog becomes visible and interactive. 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: Translated checkout has clipped buttons
Situation and user risk. Here is a useful quality-assurance exercise for a world-facing interface: The primary and secondary actions no longer fit horizontally after changing to a longer language. 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. Open the exact checkout state at mobile width and enlarged text, then inspect the selected button nodes. Apply the TPGi ARC rules and developer-tools inspection workflow 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. Allow flexible layouts and full action labels instead of truncating a destructive or financial decision. 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: Multi-step form nests the wrong headings
Situation and user risk. A realistic test begins with the user, not the dashboard. A localized wizard repeats first-level headings inside every step and disrupts reading structure. 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. Use the panel findings alongside the HTML heading sequence and visual hierarchy. Apply the TPGi ARC rules and developer-tools inspection workflow 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. Choose a meaningful document hierarchy that remains coherent as steps appear and disappear. 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: Third-party payment iframe is flagged
Situation and user risk. This situation is especially easy to miss when product teams copy a source-language screenshot into a translation ticket. A payment field lives in an embedded cross-origin component and the host developer cannot edit its markup. 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. Identify frame ownership and reproduce the error with safe test data, preserving the provider version. Apply the TPGi ARC rules and developer-tools inspection workflow 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. Escalate to the provider with evidence and offer a supported accessible alternative if the payment journey is blocked. 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: Frame title stays in English
Situation and user risk. Here is a useful quality-assurance exercise for a world-facing interface: The embedded scheduling widget has a useful visual heading but its frame title is untranslated. 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. Locate the iframe element and compare its title with the accessible purpose of the embedded content. Apply the TPGi ARC rules and developer-tools inspection workflow 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. Translate the frame label or supply an intelligible title through the integration configuration. 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: Two warnings describe one missing name
Situation and user risk. A realistic test begins with the user, not the dashboard. A small icon button appears in separate report categories, inflating the apparent number of distinct blockers. 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. Select both references in DevTools and verify whether they target the same underlying element. Apply the TPGi ARC rules and developer-tools inspection workflow 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 one well-scoped repair and retest all related findings rather than logging redundant unrelated tickets. 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: Focus outline disappears under banner
Situation and user risk. This situation is especially easy to miss when product teams copy a source-language screenshot into a translation ticket. A sticky promotional banner covers the visible keyboard focus after the locale changes its height. 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. Use DevTools to inspect geometry and stacking, then tab through the interaction at multiple viewport heights. Apply the TPGi ARC rules and developer-tools inspection workflow 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. Change positioning and spacing so focus never disappears under fixed content. 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: Korean menu wraps onto two lines
Situation and user risk. Here is a useful quality-assurance exercise for a world-facing interface: A horizontal navigation component assumes all labels occupy one text line in its source language. 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. Inspect text containers, available width and selected issue locations under realistic zoom. Apply the TPGi ARC rules and developer-tools inspection workflow 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. Adopt responsive navigation and preserve readable labels rather than forcing smaller type. 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: German dialog exceeds screen height
Situation and user risk. A realistic test begins with the user, not the dashboard. A translated legal disclosure becomes taller than a compact laptop viewport with no accessible scrolling region. 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. Open the modal, inspect its scroll containment and test keyboard access to both action buttons. Apply the TPGi ARC rules and developer-tools inspection workflow 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. Provide a usable scrolling model and preserve an understandable reading order. 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: French form buttons have duplicate labels
Situation and user risk. This situation is especially easy to miss when product teams copy a source-language screenshot into a translation ticket. Two controls both say Continue after localization, although they initiate materially different next steps. 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. Inspect each target and its surrounding context in the Elements panel, then test an isolated control list. Apply the TPGi ARC rules and developer-tools inspection workflow 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 distinct action labels that communicate destination and consequence. 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: Thai help page has line-height collision
Situation and user risk. Here is a useful quality-assurance exercise for a world-facing interface: A font substitution clips combining marks in translated explanatory text and makes error guidance unreadable. 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. Inspect computed font and line-height rules and visually review representative words with diacritics. Apply the TPGi ARC rules and developer-tools inspection workflow 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 font support and vertical spacing without manually adding arbitrary line breaks to translations. 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: Arabic breadcrumb looks reversed
Situation and user risk. A realistic test begins with the user, not the dashboard. Breadcrumb segments are displayed in visual order that contradicts the intended parent-child navigation. 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. Inspect direction and semantic DOM order, then tab and listen to each link’s position. Apply the TPGi ARC rules and developer-tools inspection workflow 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. Set directional behavior deliberately while retaining logical hierarchy and meaningful separators. 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: Spanish validation references wrong field
Situation and user risk. This situation is especially easy to miss when product teams copy a source-language screenshot into a translation ticket. The error next to a postcode input actually describes telephone number requirements after strings were remapped. 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. Inspect the input, label, description and associated error node in the live failure state. Apply the TPGi ARC rules and developer-tools inspection workflow 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 the string-to-field mapping and the describedBy relationship together. 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: Tooltip appears only on mouse hover
Situation and user risk. Here is a useful quality-assurance exercise for a world-facing interface: A localized help icon reveals critical instructions on pointer hover but not keyboard focus. 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. Select the icon and tooltip nodes, then test focus, dismissal and touch access outside the automated scan. Apply the TPGi ARC rules and developer-tools inspection workflow 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 essential information available through an operable interaction, not hover alone. 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: Contrast warning needs context
Situation and user risk. A realistic test begins with the user, not the dashboard. A result calls attention to text color over a variable background and the actual contrast changes across a banner image. 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. Inspect computed colors and image areas while confirming which text is meaningful and visible. Apply the TPGi ARC rules and developer-tools inspection workflow 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. Choose a stable readable presentation and verify manually across representative responsive crops. 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: Decorative photo is announced twice
Situation and user risk. This situation is especially easy to miss when product teams copy a source-language screenshot into a translation ticket. The image alternative repeats an adjacent translated caption and adds clutter to a screen-reader journey. 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. Inspect the image and caption elements and compare their communicative roles. Apply the TPGi ARC rules and developer-tools inspection workflow 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 an empty alternative for a truly decorative image or write concise information not already present. 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: Translated table uses visual bold headers
Situation and user risk. Here is a useful quality-assurance exercise for a world-facing interface: A supplier table bolds the top row but lacks structural header cells, making comparisons hard nonvisually. 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. Use ARC findings and Elements to inspect table semantics and header relationships. Apply the TPGi ARC rules and developer-tools inspection workflow 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 genuine header cells and clear scopes or associations for the actual data structure. 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: Nested accordion loses expanded state
Situation and user risk. A realistic test begins with the user, not the dashboard. A localized FAQ reveals a second disclosure but only the outer control updates state information. 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. Inspect inner and outer buttons separately in open and closed configurations. Apply the TPGi ARC rules and developer-tools inspection workflow 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. Keep each control’s semantics synchronized with its own panel while preserving translated headings. 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: Language picker has no selected indication
Situation and user risk. This situation is especially easy to miss when product teams copy a source-language screenshot into a translation ticket. The active language is highlighted in color but is not communicated in text or state. 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. Inspect the selected option markup and then use keyboard-only selection. Apply the TPGi ARC rules and developer-tools inspection workflow 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. Represent current selection programmatically and ensure the label says which language is active. 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: Chart legend relies on color alone
Situation and user risk. Here is a useful quality-assurance exercise for a world-facing interface: Localized sales figures use red and green keys without identifying the represented categories elsewhere. 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. Inspect the chart legend, alternative summary and available tabular values. Apply the TPGi ARC rules and developer-tools inspection workflow 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 text or pattern distinctions and a clear data summary so meaning does not depend on color. 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: Dynamic toast is missed by scan
Situation and user risk. A realistic test begins with the user, not the dashboard. A payment confirmation disappears before the auditor starts ARC, leaving a clean result for the wrong state. 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. Trigger the toast again and capture its timing and accessible announcement with a separate functional check. Apply the TPGi ARC rules and developer-tools inspection workflow 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. Preserve essential confirmation in the persistent transaction history and verify spoken feedback. 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: Right-to-left icon changes meaning
Situation and user risk. This situation is especially easy to miss when product teams copy a source-language screenshot into a translation ticket. An arrow indicating progress was mirrored automatically even though it represents a fixed physical direction. 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. Inspect the icon source and direction-specific CSS in the affected element. Apply the TPGi ARC rules and developer-tools inspection workflow 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. Mirror navigation cues only when direction genuinely changes the action’s meaning. 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: Autofill inserts mismatched language
Situation and user risk. Here is a useful quality-assurance exercise for a world-facing interface: Browser autofill supplies a country name in one language to a dropdown expecting different localized labels. 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. Inspect the selected value, underlying identifier and displayed label after autofill. Apply the TPGi ARC rules and developer-tools inspection workflow 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. Store stable country codes and render localized display names without corrupting selected values. 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 ARC Toolkit work inside DevTools?
Yes. The published tooling describes a developer-tools panel with access to findings and affected source elements. 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 makes it different from a screenshot review?
It connects suspected barriers to markup and rules. Screenshots remain useful for reflow and visual evidence but cannot expose all programmatic semantics. 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 cross-origin iframe?
The toolkit describes support for frames, but integration ownership and browser permissions still matter; separately validate the embedded journey. 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.
Are best-practice warnings WCAG failures?
Not necessarily. Treat them as investigation prompts, and map any confirmed failure to the applicable requirement and user impact. 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 if an issue disappears after translation is switched?
Capture the precise language, route, viewport and state before the switch. The defect may be conditional or related to a component lifecycle. 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 it replace a keyboard test?
No. Complete the user journey with keyboard alone even if reported rules have no 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.
Should every result become a separate ticket?
No. Group issues by root cause and shared component while retaining all affected locales and states. 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.
Do I need to test long translations?
Yes. Reflow, overlays, dialogs and focus visibility can change materially when text expands. 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 developers prioritize?
Use blocked user tasks, severity of consequence, prevalence and reach, not only report order. 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 makes a repair verifiable?
An exact reproducible state, an expected semantic or visual outcome, a rerun of the relevant check and a human confirmation. 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.