How do you run a Lighthouse accessibility audit for a translated website without mistaking a green score for an accessible experience? Lighthouse is a useful starting point for finding repeatable technical problems in localized pages, but its report describes a particular page state, browser configuration and set of automated checks. It does not establish that a person can complete an entire task with a keyboard, magnifier or screen reader. This guide explains how to run Lighthouse from the command line, interpret accessibility findings, retain useful JSON evidence and compare language editions without confusing translation quality with a numerical score.
A multilingual website accessibility audit should start with the actual journeys readers take: opening a language-specific landing page, selecting a service, entering a name with the appropriate writing system, correcting a failed form and reading a confirmation. A translated page can inherit a perfect technical template yet still present an inaccessible label, unexplained abbreviation, invisible focus indicator or misleading link name. Conversely, two language versions may have different Lighthouse scores because their content, widgets or rendered states differ; the difference deserves investigation rather than an automatic declaration that one language is better.
This practical Lighthouse CLI tutorial is intended for localization teams, site owners, developers, technical writers and accessibility reviewers working across countries and scripts. You will learn a reproducible test sequence, see examples for right-to-left layouts and non-Latin scripts, understand what to record in issue reports and learn where human review and assistive-technology testing must take over. The goal is a responsible release decision: fix concrete barriers, document remaining uncertainty and give readers equal access to meaning, actions and error recovery across all supported locales.
In brief: what to check first
- Confirm the requested and final locale route before reading a score.
- Use one documented browser and tool version for comparisons.
- Inspect the actual state used for each audit, including consent and authentication.
- Investigate individual failed checks; never treat a score as a translation or WCAG certificate.
- Confirm key journeys with keyboard, assistive technology and language review.
What Lighthouse measures and what it cannot measure
Lighthouse runs a collection of audits against a page in Chromium and groups findings into categories, including accessibility. An accessibility score summarizes applicable weighted checks. It is not a percentage of disabled people who can use the website, a measurement of translated text quality or a certificate of compliance with every WCAG success criterion. Some checks are automated and others require human judgement. In practice, treat a failure as a lead to investigate, a passing check as limited evidence and a perfect score as a reason to continue testing rather than stop. Keep the audit’s version, URL and test conditions with its result.
Start with a route inventory instead of an average
List actual locale routes, for example /en/booking/, /fr/reservation/ and /ar/booking/, and group them by task rather than by visual appearance. Include at least one landing page, search results, transaction form, error screen and confirmation page in every high-risk language. A page that redirects to English or a login screen does not count as a successful check of the requested locale. Assign each route a business owner, a linguistic reviewer and a technical owner. That small ownership record prevents the report from becoming an anonymous scorecard no one can repair.
Prepare a stable command-line environment
Install a supported Node.js runtime and the Lighthouse CLI according to the current official project instructions; use a compatible Chrome or Chromium installation. A representative command is lighthouse https://example.org/fr/ –only-categories=accessibility –output=json –output-path=./fr-home.json. Options and dependencies can evolve, so run lighthouse –help before adopting commands unchanged in automation. Record the exact executable version, browser version, URL, redirect target, viewport and authentication conditions. Never place production passwords, personal data or secret query tokens in screenshots or exported reports.
Why a scored audit differs from a journey test
An audit may inspect a page after loading, but real use consists of several states. The visitor opens a menu, triggers validation, selects a date, adds an item, loses connectivity or changes language halfway through checkout. Automated tooling can detect some missing names and structure problems in a captured state; it cannot reliably decide whether a translated warning changes a person’s choice or whether focus moves sensibly after an asynchronous update. Combine repeatable Lighthouse checks with scripted task journeys, keyboard observation, screen-reader trials and localization review by someone who understands the target language.
Write evidence so another person can reproduce it
A useful defect report identifies the requested URL, resolved URL, language, browser build, audit version, account state, viewport, step to reach the problem, affected control, expected result and actual result. Attach a compact excerpt of the JSON finding and a screenshot only when it reveals something the reader cannot learn from text. Record whether an audit is reproducible, intermittent or state dependent. Explain the user consequence in ordinary language: ‘A blind reader hears three unlabeled buttons and cannot choose the correct delivery option’ is more actionable than ‘ARIA failure, severity high.’
Compare localized results without ranking people by language
Set a consistent benchmark but respect language-specific layout. Arabic may require different alignment and focus observation; Japanese may require different line-breaking inspection; German may increase label lengths. A raw score difference is an investigation trigger, not a proof of poorer workmanship. When a route is unavailable in one language, mark it ‘not tested’ or ‘missing route’ rather than silently substituting English. Record deliberate product differences, but challenge unexplained access differences in forms, consent panels, purchase flows and emergency information.
Responsible release gates
Define release gates around critical tasks, not a single threshold. For example: no confirmed blocking unlabeled controls in checkout; localized error messages must identify the failing field and recovery action; required routes must load in the chosen language; keyboard users must complete core journeys; remaining issues have an owner and documented risk. The Lighthouse result supports this decision, but only as one piece of evidence. Do not use an automated score to override a first-hand failure reported by a disabled user.
Where this guide fits in a translation workflow
Treat Lighthouse as the repeatable page-audit layer of multilingual accessibility quality assurance. For interactive element semantics, use an accessibility-tree inspector; for end-to-end interactions, use browser tests; for mobile native views, use platform testing. Editorial translation, legal meaning, terminology and cultural appropriateness require their own reviewers. Keeping these responsibilities separate makes the workflow faster and helps editors understand which issue needs rewriting, which needs code and which needs both.
A practical laboratory: twenty-five multilingual accessibility situations
The cases below separate what the browser can observe from what a multilingual visitor needs. They are not a claim that Lighthouse detects every example automatically. Some require a script, visual inspection, human reading or a screen-reader session after the automated audit identifies the page or state to examine.
1. The HTML language is inherited from English
Imagine this release test: A French page visibly contains French copy while the root document still identifies itself as English; assistive software may select the wrong pronunciation rules. Inspect the rendered root element and redirects, not only a translation template variable. The important question is not only whether the page contains a machine-detectable warning; it is whether a reader using the intended language can identify the task, operate the relevant control and recover when something goes wrong.
Investigate it in a controlled sequence. Capture the intended locale URL, the final destination, a representative screen, the relevant accessible element and the current Lighthouse finding where one exists. If the finding is absent, write that explicitly. A scanner’s silence must not be transformed into a claim that the experience is sound. Set a correct page-level language tag and apply narrower language attributes when quoted passages genuinely switch language.
Check French, English and a third locale after client-side navigation; verify the updated DOM and actual speech behaviour. Record the expected announcement or action and the observation from the actual run. For a meaningful comparison, repeat the check against the source-language page and one other target locale while preserving the necessary differences in script, direction and wording. Close the issue only when the technical result and the human-language result agree; otherwise retain it for a named specialist to examine.
2. The form has a placeholder but no accessible label
Imagine this release test: A customer sees ‘Numéro de téléphone’ as faint placeholder text, yet a text field may be announced without a stable name once the user types. Inspect the failed input control in the report and confirm whether a visible label is programmatically associated. The important question is not only whether the page contains a machine-detectable warning; it is whether a reader using the intended language can identify the task, operate the relevant control and recover when something goes wrong.
Investigate it in a controlled sequence. Capture the intended locale URL, the final destination, a representative screen, the relevant accessible element and the current Lighthouse finding where one exists. If the finding is absent, write that explicitly. A scanner’s silence must not be transformed into a claim that the experience is sound. Use a persistent, translated label associated with the input; preserve separate explanation of international dialing codes.
Tab and screen-reader test before and after typing; do not accept placeholder translation as a substitute. Record the expected announcement or action and the observation from the actual run. For a meaningful comparison, repeat the check against the source-language page and one other target locale while preserving the necessary differences in script, direction and wording. Close the issue only when the technical result and the human-language result agree; otherwise retain it for a named specialist to examine.
3. Multiple translated links sound identical
Imagine this release test: A card grid contains ten ‘Read more’ links, all with the same accessible name, even though the cards lead to distinct services. Inspect link-name findings and the actual context exposed to a list-of-links view. The important question is not only whether the page contains a machine-detectable warning; it is whether a reader using the intended language can identify the task, operate the relevant control and recover when something goes wrong.
Investigate it in a controlled sequence. Capture the intended locale URL, the final destination, a representative screen, the relevant accessible element and the current Lighthouse finding where one exists. If the finding is absent, write that explicitly. A scanner’s silence must not be transformed into a claim that the experience is sound. Give each link a meaningful accessible name that names the destination without inserting irrelevant keyword stuffing.
Review the resulting names with a native-language editor and a screen-reader user in isolation. Record the expected announcement or action and the observation from the actual run. For a meaningful comparison, repeat the check against the source-language page and one other target locale while preserving the necessary differences in script, direction and wording. Close the issue only when the technical result and the human-language result agree; otherwise retain it for a named specialist to examine.
4. Icon-only language selector
Imagine this release test: The globe icon opens a locale menu but is exposed merely as a generic button with no name or with an English-only technical code. Check the selector before expansion, each option and the announced selected state. The important question is not only whether the page contains a machine-detectable warning; it is whether a reader using the intended language can identify the task, operate the relevant control and recover when something goes wrong.
Investigate it in a controlled sequence. Capture the intended locale URL, the final destination, a representative screen, the relevant accessible element and the current Lighthouse finding where one exists. If the finding is absent, write that explicitly. A scanner’s silence must not be transformed into a claim that the experience is sound. Provide a clear accessible name and meaningful language names; avoid assuming flags identify languages.
Verify the menu works with keyboard, touch and speech across Arabic, English and Spanish. Record the expected announcement or action and the observation from the actual run. For a meaningful comparison, repeat the check against the source-language page and one other target locale while preserving the necessary differences in script, direction and wording. Close the issue only when the technical result and the human-language result agree; otherwise retain it for a named specialist to examine.
5. A decorative image receives misleading alternative text
Imagine this release test: A decorative flourish next to a translated heading is read aloud as a promotional sentence unrelated to the task. Locate the image audit warning and distinguish informative illustrations from purely decorative shapes. The important question is not only whether the page contains a machine-detectable warning; it is whether a reader using the intended language can identify the task, operate the relevant control and recover when something goes wrong.
Investigate it in a controlled sequence. Capture the intended locale URL, the final destination, a representative screen, the relevant accessible element and the current Lighthouse finding where one exists. If the finding is absent, write that explicitly. A scanner’s silence must not be transformed into a claim that the experience is sound. Use an empty alternative for decoration and a concise functional description for information-bearing graphics.
Ask whether the description communicates the same needed information without duplicating nearby text. Record the expected announcement or action and the observation from the actual run. For a meaningful comparison, repeat the check against the source-language page and one other target locale while preserving the necessary differences in script, direction and wording. Close the issue only when the technical result and the human-language result agree; otherwise retain it for a named specialist to examine.
6. Contrast changes when the site switches locale
Imagine this release test: A locale stylesheet adjusts muted text colour, causing help instructions to become difficult to read against the background. Compare the actual rendered foreground and background colours in both language versions. The important question is not only whether the page contains a machine-detectable warning; it is whether a reader using the intended language can identify the task, operate the relevant control and recover when something goes wrong.
Investigate it in a controlled sequence. Capture the intended locale URL, the final destination, a representative screen, the relevant accessible element and the current Lighthouse finding where one exists. If the finding is absent, write that explicitly. A scanner’s silence must not be transformed into a claim that the experience is sound. Replace fragile colour overrides and verify all states including focus, disabled, error and visited.
Inspect real screens at high zoom and with colour-vision variation; a single sample ratio misses complex backgrounds. Record the expected announcement or action and the observation from the actual run. For a meaningful comparison, repeat the check against the source-language page and one other target locale while preserving the necessary differences in script, direction and wording. Close the issue only when the technical result and the human-language result agree; otherwise retain it for a named specialist to examine.
7. Cookie banner hides the tested content
Imagine this release test: The audit reaches a consent overlay rather than the reservation page, leading to scores that cannot be meaningfully compared with a different locale. Record consent state, browser storage, visible overlay and resolved URL before interpreting findings. The important question is not only whether the page contains a machine-detectable warning; it is whether a reader using the intended language can identify the task, operate the relevant control and recover when something goes wrong.
Investigate it in a controlled sequence. Capture the intended locale URL, the final destination, a representative screen, the relevant accessible element and the current Lighthouse finding where one exists. If the finding is absent, write that explicitly. A scanner’s silence must not be transformed into a claim that the experience is sound. Test consent itself as a journey and run a second clearly labeled case after making a legitimate consent choice.
Do not bypass consent silently or conclude the underlying page is accessible because the overlay passed. Record the expected announcement or action and the observation from the actual run. For a meaningful comparison, repeat the check against the source-language page and one other target locale while preserving the necessary differences in script, direction and wording. Close the issue only when the technical result and the human-language result agree; otherwise retain it for a named specialist to examine.
8. A translated route redirects to the English homepage
Imagine this release test: The requested German pricing page returns a generic English landing page without an obvious failure message. Capture initial URL and final resolved URL; compare expected heading, content language and route identity. The important question is not only whether the page contains a machine-detectable warning; it is whether a reader using the intended language can identify the task, operate the relevant control and recover when something goes wrong.
Investigate it in a controlled sequence. Capture the intended locale URL, the final destination, a representative screen, the relevant accessible element and the current Lighthouse finding where one exists. If the finding is absent, write that explicitly. A scanner’s silence must not be transformed into a claim that the experience is sound. Fix routing or publish a truthful language-availability notice rather than treating English fallback as a German audit.
Fail route coverage even if Lighthouse awards the fallback page a high accessibility score. Record the expected announcement or action and the observation from the actual run. For a meaningful comparison, repeat the check against the source-language page and one other target locale while preserving the necessary differences in script, direction and wording. Close the issue only when the technical result and the human-language result agree; otherwise retain it for a named specialist to examine.
9. Validation errors appear only in colour
Imagine this release test: A user submits an incorrect postal code and sees a red border without a useful accessible error explanation. Capture the page after submission and inspect the relationship between the input and error message. The important question is not only whether the page contains a machine-detectable warning; it is whether a reader using the intended language can identify the task, operate the relevant control and recover when something goes wrong.
Investigate it in a controlled sequence. Capture the intended locale URL, the final destination, a representative screen, the relevant accessible element and the current Lighthouse finding where one exists. If the finding is absent, write that explicitly. A scanner’s silence must not be transformed into a claim that the experience is sound. Show translated explanatory text, link it to the field and support a clear recovery path.
Retry with a screen reader and keyboard; confirm the user knows what was wrong and what to do next. Record the expected announcement or action and the observation from the actual run. For a meaningful comparison, repeat the check against the source-language page and one other target locale while preserving the necessary differences in script, direction and wording. Close the issue only when the technical result and the human-language result agree; otherwise retain it for a named specialist to examine.
10. The payment button changes name after load
Imagine this release test: The initial accessible name is clear, but a hydration step replaces it with a bare icon. Compare the page after initial render, after scripts settle and after a localized user action. The important question is not only whether the page contains a machine-detectable warning; it is whether a reader using the intended language can identify the task, operate the relevant control and recover when something goes wrong.
Investigate it in a controlled sequence. Capture the intended locale URL, the final destination, a representative screen, the relevant accessible element and the current Lighthouse finding where one exists. If the finding is absent, write that explicitly. A scanner’s silence must not be transformed into a claim that the experience is sound. Preserve semantic controls across client rendering; avoid translations injected solely into visual pseudo-elements.
Test the state where real users click rather than merely a fast initial page load. Record the expected announcement or action and the observation from the actual run. For a meaningful comparison, repeat the check against the source-language page and one other target locale while preserving the necessary differences in script, direction and wording. Close the issue only when the technical result and the human-language result agree; otherwise retain it for a named specialist to examine.
11. Right-to-left checkout reverses visual emphasis
Imagine this release test: An Arabic delivery option visually moves, but the DOM reading and keyboard sequences remain organized around a different order. Inspect source order, focus movement and associated labels; Lighthouse may not prove the navigation is coherent. The important question is not only whether the page contains a machine-detectable warning; it is whether a reader using the intended language can identify the task, operate the relevant control and recover when something goes wrong.
Investigate it in a controlled sequence. Capture the intended locale URL, the final destination, a representative screen, the relevant accessible element and the current Lighthouse finding where one exists. If the finding is absent, write that explicitly. A scanner’s silence must not be transformed into a claim that the experience is sound. Choose semantic structure and a deliberate reading order; use direction-aware layout without scrambling content meaning.
Walk the journey in Arabic with a knowledgeable reviewer and note where visual and spoken sequences diverge. Record the expected announcement or action and the observation from the actual run. For a meaningful comparison, repeat the check against the source-language page and one other target locale while preserving the necessary differences in script, direction and wording. Close the issue only when the technical result and the human-language result agree; otherwise retain it for a named specialist to examine.
12. A date picker is technically labelled but confusing
Imagine this release test: The date field has a name, yet its month controls are announced in the wrong language and the chosen date is ambiguous. Open the picker and inspect weekday labels, next/previous navigation and selected-date announcement. The important question is not only whether the page contains a machine-detectable warning; it is whether a reader using the intended language can identify the task, operate the relevant control and recover when something goes wrong.
Investigate it in a controlled sequence. Capture the intended locale URL, the final destination, a representative screen, the relevant accessible element and the current Lighthouse finding where one exists. If the finding is absent, write that explicitly. A scanner’s silence must not be transformed into a claim that the experience is sound. Localize names and date formats while preserving unambiguous calendar values in stored data.
Test realistic boundary dates and confirm the exact date understood by a screen-reader user. Record the expected announcement or action and the observation from the actual run. For a meaningful comparison, repeat the check against the source-language page and one other target locale while preserving the necessary differences in script, direction and wording. Close the issue only when the technical result and the human-language result agree; otherwise retain it for a named specialist to examine.
13. A PDF download uses an unhelpful file name
Imagine this release test: A report card is linked as ‘Document 04’ and the download has no description of language, format or purpose. Inspect the link text and resulting file metadata; treat downloadable content as a separate artifact. The important question is not only whether the page contains a machine-detectable warning; it is whether a reader using the intended language can identify the task, operate the relevant control and recover when something goes wrong.
Investigate it in a controlled sequence. Capture the intended locale URL, the final destination, a representative screen, the relevant accessible element and the current Lighthouse finding where one exists. If the finding is absent, write that explicitly. A scanner’s silence must not be transformed into a claim that the experience is sound. Name the file meaningfully and provide the report’s language, accessible format and essential purpose in context.
Open the actual file with appropriate readers; a sound web link cannot establish PDF accessibility. Record the expected announcement or action and the observation from the actual run. For a meaningful comparison, repeat the check against the source-language page and one other target locale while preserving the necessary differences in script, direction and wording. Close the issue only when the technical result and the human-language result agree; otherwise retain it for a named specialist to examine.
14. The localized heading hierarchy is broken
Imagine this release test: A translation editor changes visual heading sizes and inadvertently drops semantic heading levels. Inspect headings as structural nodes rather than judging font sizes alone. The important question is not only whether the page contains a machine-detectable warning; it is whether a reader using the intended language can identify the task, operate the relevant control and recover when something goes wrong.
Investigate it in a controlled sequence. Capture the intended locale URL, the final destination, a representative screen, the relevant accessible element and the current Lighthouse finding where one exists. If the finding is absent, write that explicitly. A scanner’s silence must not be transformed into a claim that the experience is sound. Use heading elements that reflect document structure, with translated words and stable hierarchy.
Navigate by headings and confirm the page outline makes sense without reading every paragraph. Record the expected announcement or action and the observation from the actual run. For a meaningful comparison, repeat the check against the source-language page and one other target locale while preserving the necessary differences in script, direction and wording. Close the issue only when the technical result and the human-language result agree; otherwise retain it for a named specialist to examine.
15. Dynamic search results are not announced
Imagine this release test: A Spanish service search displays matching cards but gives no accessible feedback when results update. Trigger a search and inspect the presence or absence of a useful status message. The important question is not only whether the page contains a machine-detectable warning; it is whether a reader using the intended language can identify the task, operate the relevant control and recover when something goes wrong.
Investigate it in a controlled sequence. Capture the intended locale URL, the final destination, a representative screen, the relevant accessible element and the current Lighthouse finding where one exists. If the finding is absent, write that explicitly. A scanner’s silence must not be transformed into a claim that the experience is sound. Provide concise translated status information without bombarding the user with repeated announcements.
Run queries with zero, one and many matches, observing focus and announcement timing. Record the expected announcement or action and the observation from the actual run. For a meaningful comparison, repeat the check against the source-language page and one other target locale while preserving the necessary differences in script, direction and wording. Close the issue only when the technical result and the human-language result agree; otherwise retain it for a named specialist to examine.
16. Untranslated technical text appears inside help
Imagine this release test: A support panel includes ‘Submit ticket’ in English inside an otherwise Portuguese journey. Investigate whether the phrase is content, an accessible name, or a third-party widget injected after load. The important question is not only whether the page contains a machine-detectable warning; it is whether a reader using the intended language can identify the task, operate the relevant control and recover when something goes wrong.
Investigate it in a controlled sequence. Capture the intended locale URL, the final destination, a representative screen, the relevant accessible element and the current Lighthouse finding where one exists. If the finding is absent, write that explicitly. A scanner’s silence must not be transformed into a claim that the experience is sound. Fix the ownership chain for untranslated strings, ensuring visible and accessible wording remain aligned.
Check that native readers recognize the action and that the spoken label matches what sighted users see. Record the expected announcement or action and the observation from the actual run. For a meaningful comparison, repeat the check against the source-language page and one other target locale while preserving the necessary differences in script, direction and wording. Close the issue only when the technical result and the human-language result agree; otherwise retain it for a named specialist to examine.
17. Complex script glyphs fail after a font update
Imagine this release test: A Hindi information notice displays missing glyph boxes although the text and labels remain in the document. Lighthouse may not identify every shaping or fallback defect; observe the rendered text and font requests. The important question is not only whether the page contains a machine-detectable warning; it is whether a reader using the intended language can identify the task, operate the relevant control and recover when something goes wrong.
Investigate it in a controlled sequence. Capture the intended locale URL, the final destination, a representative screen, the relevant accessible element and the current Lighthouse finding where one exists. If the finding is absent, write that explicitly. A scanner’s silence must not be transformed into a claim that the experience is sound. Restore font coverage and correct webfont loading without turning meaningful text into images.
Compare headings, small body text, keyboard input and printed output in the real script. Record the expected announcement or action and the observation from the actual run. For a meaningful comparison, repeat the check against the source-language page and one other target locale while preserving the necessary differences in script, direction and wording. Close the issue only when the technical result and the human-language result agree; otherwise retain it for a named specialist to examine.
18. A carousel has unusable navigation labels
Imagine this release test: Several carousel arrows are all called ‘Next’ or have no name, giving no clue which content region changes. Inspect the controls in accessibility order and test whether announcements identify the changed item. The important question is not only whether the page contains a machine-detectable warning; it is whether a reader using the intended language can identify the task, operate the relevant control and recover when something goes wrong.
Investigate it in a controlled sequence. Capture the intended locale URL, the final destination, a representative screen, the relevant accessible element and the current Lighthouse finding where one exists. If the finding is absent, write that explicitly. A scanner’s silence must not be transformed into a claim that the experience is sound. Name controls relative to their carousel and supply a useful state or position indicator.
Check that translation does not create overly long speech and that keyboard focus stays predictable. Record the expected announcement or action and the observation from the actual run. For a meaningful comparison, repeat the check against the source-language page and one other target locale while preserving the necessary differences in script, direction and wording. Close the issue only when the technical result and the human-language result agree; otherwise retain it for a named specialist to examine.
19. Score differences come from an ad widget
Imagine this release test: A third-party advertisement is injected on one geographic route and introduces unlabeled controls. Compare the DOM, embedded frames, network conditions and location-sensitive third-party components. The important question is not only whether the page contains a machine-detectable warning; it is whether a reader using the intended language can identify the task, operate the relevant control and recover when something goes wrong.
Investigate it in a controlled sequence. Capture the intended locale URL, the final destination, a representative screen, the relevant accessible element and the current Lighthouse finding where one exists. If the finding is absent, write that explicitly. A scanner’s silence must not be transformed into a claim that the experience is sound. Treat the widget as a product responsibility and seek an accessible integration or clearly documented mitigation.
Repeat under consistent consent and region conditions while preserving evidence of the third party’s behaviour. Record the expected announcement or action and the observation from the actual run. For a meaningful comparison, repeat the check against the source-language page and one other target locale while preserving the necessary differences in script, direction and wording. Close the issue only when the technical result and the human-language result agree; otherwise retain it for a named specialist to examine.
20. An emergency notice is removed for one locale
Imagine this release test: A critical service warning is omitted from the localized page; everything that remains passes the automated checks. Compare meaning and content inventory across editions rather than relying on technical audit results. The important question is not only whether the page contains a machine-detectable warning; it is whether a reader using the intended language can identify the task, operate the relevant control and recover when something goes wrong.
Investigate it in a controlled sequence. Capture the intended locale URL, the final destination, a representative screen, the relevant accessible element and the current Lighthouse finding where one exists. If the finding is absent, write that explicitly. A scanner’s silence must not be transformed into a claim that the experience is sound. Publish equivalent critical information with clear priority and appropriate translation review.
Have a speaker of the target language verify the warning, timing and required action before release. Record the expected announcement or action and the observation from the actual run. For a meaningful comparison, repeat the check against the source-language page and one other target locale while preserving the necessary differences in script, direction and wording. Close the issue only when the technical result and the human-language result agree; otherwise retain it for a named specialist to examine.
21. A translated accordion loses expanded state
Imagine this release test: The accordion title is localized, but its expanded/collapsed state is not updated for assistive technology. Open and close each item, inspecting role, state and focus rather than the initial report only. The important question is not only whether the page contains a machine-detectable warning; it is whether a reader using the intended language can identify the task, operate the relevant control and recover when something goes wrong.
Investigate it in a controlled sequence. Capture the intended locale URL, the final destination, a representative screen, the relevant accessible element and the current Lighthouse finding where one exists. If the finding is absent, write that explicitly. A scanner’s silence must not be transformed into a claim that the experience is sound. Keep the control semantic and synchronize expanded state with the actual panel visibility.
Run keyboard and screen-reader checks on both long and short translated answers. Record the expected announcement or action and the observation from the actual run. For a meaningful comparison, repeat the check against the source-language page and one other target locale while preserving the necessary differences in script, direction and wording. Close the issue only when the technical result and the human-language result agree; otherwise retain it for a named specialist to examine.
22. Mobile zoom clips the translated submit action
Imagine this release test: At high zoom, a long German call to action disappears behind a fixed footer. Audit the mobile page but separately inspect zoom and responsive layout since a score cannot prove usable reflow. The important question is not only whether the page contains a machine-detectable warning; it is whether a reader using the intended language can identify the task, operate the relevant control and recover when something goes wrong.
Investigate it in a controlled sequence. Capture the intended locale URL, the final destination, a representative screen, the relevant accessible element and the current Lighthouse finding where one exists. If the finding is absent, write that explicitly. A scanner’s silence must not be transformed into a claim that the experience is sound. Allow text to wrap, avoid fixed obstructions and keep primary actions reachable without horizontal scrolling.
Verify the complete submission flow at increased zoom and with text resizing. Record the expected announcement or action and the observation from the actual run. For a meaningful comparison, repeat the check against the source-language page and one other target locale while preserving the necessary differences in script, direction and wording. Close the issue only when the technical result and the human-language result agree; otherwise retain it for a named specialist to examine.
23. The sign-in flow changes language unexpectedly
Imagine this release test: The marketing page is Italian, but authentication sends the reader to an English identity provider with unexplained fields. Trace redirects and distinguish first-party localization from external authentication ownership. The important question is not only whether the page contains a machine-detectable warning; it is whether a reader using the intended language can identify the task, operate the relevant control and recover when something goes wrong.
Investigate it in a controlled sequence. Capture the intended locale URL, the final destination, a representative screen, the relevant accessible element and the current Lighthouse finding where one exists. If the finding is absent, write that explicitly. A scanner’s silence must not be transformed into a claim that the experience is sound. Supply translated entry guidance and coordinate accessible identity-provider labels and error recovery.
Complete the journey end to end, including incorrect password and account recovery scenarios. Record the expected announcement or action and the observation from the actual run. For a meaningful comparison, repeat the check against the source-language page and one other target locale while preserving the necessary differences in script, direction and wording. Close the issue only when the technical result and the human-language result agree; otherwise retain it for a named specialist to examine.
24. An audio tutorial has no usable transcript
Imagine this release test: A video explains localised instructions but captions or an equivalent transcript are missing. Check media controls separately; a page-level accessibility score does not establish that speech content is accessible. The important question is not only whether the page contains a machine-detectable warning; it is whether a reader using the intended language can identify the task, operate the relevant control and recover when something goes wrong.
Investigate it in a controlled sequence. Capture the intended locale URL, the final destination, a representative screen, the relevant accessible element and the current Lighthouse finding where one exists. If the finding is absent, write that explicitly. A scanner’s silence must not be transformed into a claim that the experience is sound. Provide accurate captions, relevant non-speech sounds and a readable transcript where appropriate.
Use reviewers for the spoken language and inspect whether controls themselves are keyboard operable. Record the expected announcement or action and the observation from the actual run. For a meaningful comparison, repeat the check against the source-language page and one other target locale while preserving the necessary differences in script, direction and wording. Close the issue only when the technical result and the human-language result agree; otherwise retain it for a named specialist to examine.
25. A release gate is based only on a number
Imagine this release test: A manager requires a score above a threshold while ignoring a blocked payment form. Review the release policy and identify essential user tasks that the score cannot evaluate. The important question is not only whether the page contains a machine-detectable warning; it is whether a reader using the intended language can identify the task, operate the relevant control and recover when something goes wrong.
Investigate it in a controlled sequence. Capture the intended locale URL, the final destination, a representative screen, the relevant accessible element and the current Lighthouse finding where one exists. If the finding is absent, write that explicitly. A scanner’s silence must not be transformed into a claim that the experience is sound. Promote task-blocking accessibility defects to release gates; use Lighthouse as diagnostic evidence, not permission to ignore users.
Keep a signed record of critical paths tested by keyboard, assistive technology and language reviewers. Record the expected announcement or action and the observation from the actual run. For a meaningful comparison, repeat the check against the source-language page and one other target locale while preserving the necessary differences in script, direction and wording. Close the issue only when the technical result and the human-language result agree; otherwise retain it for a named specialist to examine.
How to assemble a release worksheet
Create a short table or issue tracker with one row per locale, route and tested state. Record the business task, expected language, build identifier, URL, browser and Lighthouse version, consent condition, viewport, automated findings, manual findings, owner, risk, repair and retest. Add a column for missing or intentionally unavailable language coverage. A useful worksheet makes uncertainty visible rather than smoothing it into a misleading percentage.
Separate blocking defects from stylistic improvements. An unlabeled payment option, inaccessible consent selection or incorrect high-stakes warning may prevent release. A minor phrasing improvement might be scheduled with editorial review. Decide severity by reader consequence, not merely by the wording of a tool report. Include a person who knows the language and someone who can reproduce the accessibility problem. Neither role can substitute for the other.
Worked release decision
Suppose the English and Japanese appointment pages produce high automated scores, while the Arabic page produces a lower one. The first response is not to declare Arabic translation inferior. Verify that all three pages show the same appointment task, that the Arabic route has not redirected, and that the tested state is comparable. Next inspect the specific checks that differ. A missing name on one date-navigation button is an actionable issue; an absent appointment type is a separate content parity issue; a confusing calendar order requires keyboard and speech testing even after the names are repaired.
After the developer repairs the control, rerun the audit under the original conditions and have an Arabic-speaking reviewer complete the booking task by keyboard and with assistive technology where possible. Note the actual date selected, the error and recovery path, and the final confirmation language. Only then can the team make a reasoned release decision. The combined result communicates more than four different scorecards because it answers what the reader can do.
Frequently asked questions
Does a Lighthouse accessibility score of 100 mean WCAG compliance?
No. The score summarizes applicable automated checks and does not cover every WCAG criterion, every user journey, all assistive technologies or the accuracy of translated content. A high score is useful but cannot replace expert manual evaluation.
Should all localized pages have identical scores?
Not necessarily. Their structures, data, widgets and audit conditions may differ. Compare equivalent routes and document differences before deciding whether a discrepancy is a defect. A missing route must not be counted as an accessible translation.
Is it safe to run a Lighthouse audit on a logged-in portal?
It can be useful in an authorized test environment with synthetic records. Avoid exposing personal data, authentication tokens or confidential screenshots in stored HTML and JSON reports. Follow your organization’s data-handling policy.
Can Lighthouse judge whether an Arabic translation is correct?
No. It may detect some technical structures and labels but cannot evaluate legal nuances, culturally appropriate wording, exact instructions or the meaning of the translation. A competent language reviewer remains essential.
How often should the team rerun the audit?
Run it for material changes to templates, navigation, localization bundles, fonts and dynamic widgets, and include key routes in an agreed release cycle. The proper cadence depends on risk, change frequency and operational capacity.
Why do results sometimes change with no code change?
Browser versions, network behaviour, personalization, third-party widgets, consent state and server-rendering timing may affect the page being analyzed. Capture conditions and rerun before inferring a regression.
What is the fastest responsible starting workflow?
Select the top three critical tasks, inventory routes across supported languages, run consistent automated audits, triage blockers, confirm fixes in the actual language, then finish with keyboard and assistive-technology journey tests. Expand coverage gradually.
What belongs in the final QA record?
Include date, build, locale, URL, tool versions, affected user journey, reproducible problem, evidence, owner, resolution and human verification outcome. Keep accessibility and editorial translation approvals separate but linked.
Official reading and related guides
Read the Lighthouse project documentation, Chrome Lighthouse guide, and W3C WAI guidance on evaluation. For complementary workflows see axe-core CLI, Pa11y CLI and WAVE Browser Extension. These links point to distinct review tasks rather than claiming the tools are interchangeable.