Every language version needs testing for the parts that change with the language, and the standard says so in a place people rarely look. Buried in the definition of accessibility support is the condition that a technology's use has been tested for interoperability with users' assistive technology in the human languages of the content. Not in some language. In the content's own.
That clause is not advisory. Relying only on accessibility-supported ways of using technologies is one of WCAG's five conformance requirements. So a page whose support was never established in its own language has a gap in a requirement, not a gap in good practice. It is also the reason this question has a real answer instead of a budget-shaped one.
The short version
The code travels between locales. The content, the announcements and the reading order do not. Accessibility support is defined per language, so a component proved in English is not proved in Japanese. An untested locale stays untested, and no amount of testing on the original produces a pass for a translation. What does shrink the work is that shared templates only have to be proved once per behaviour, not once per page.
The Clause That Decides This
Read the support definition in full and it has two conditions, both of which have to hold. The first is that the way the technology is used has been tested for interoperability with users' assistive technology in the human languages of the content. The second is that accessibility-supported user agents are available to users, by one of four named routes.
The first condition is the one doing the work here, and it is easy to skim past because the phrase sits at the end of a long sentence. What it means in practice is that support is a property of a combination and a language together. A custom autocomplete proved to announce correctly with one screen reader on your English pages has not thereby been proved on your Arabic ones, because the pairing being tested is different the moment the content language changes.
The standard reinforces this from the other side too. It declines to pre-define which combinations must be supported, and one of the reasons it gives is that the answer depends on the product's context, including its language. The evaluation methodology repeats it, saying the support baseline should ideally cover the user agents actually used by people with disabilities in the applicable geographic region and language community.
So a locale is not only a different voice. It can be a different product doing the reading, on a different platform, with different defaults. Our guide to which browsers and screen readers to test is where that list gets built. Shipping in five languages is one of the strongest reasons for it to have more than three rows.
What Travels Between Locales, and What Never Does
The budget question is really about which findings are shared and which are per-locale, so it helps to sort them. Anything that lives in the template and does not change when the strings change is proved once. Anything that lives in the strings, or in the direction they run, is proved per locale.
| What is being checked | Proved once, or per locale | Why |
|---|---|---|
| Component markup, roles and states | Once per component | The same code renders in every locale, so the structure it produces is the same |
| Contrast, target size, focus indicators | Once per theme, rechecked where text length forces layout changes | These are style decisions, until a longer translation wraps a button and changes the geometry |
| Accessible names and labels | Per locale | A name is content. Translation drift leaves buttons announcing in the wrong language |
| Alt text | Per locale | Alt text is a string like any other, and it is the one a translation pipeline is most likely to skip |
| Error and status messages | Per locale | Often assembled in code from fragments, which is where a translation breaks the sentence |
| Reading and focus order | Per direction, so once for left-to-right and again for right-to-left | A mirrored layout can reverse the visual order without moving the underlying sequence |
| Language declarations | Per locale, and cheap | This is one of the few things automated tools settle outright rather than flagging |
| Screen reader behaviour | Per locale | Support is defined as tested in the content's language, and the product may differ by region |
The last row is why a five-locale product is not five times the audit and is not one audit either. The structural half is shared and the heard half is not, so a sensible scope tests every locale for the things that change with language and tests the shared components once. That is a much smaller number than five full audits and a much larger one than the single audit most quotes assume.
The Two Language Criteria, and Why They Are the Easy Part
WCAG has two criteria aimed directly at this, and both are worth knowing precisely because they are not where the difficulty lies. The first, language of page, requires the page's default human language to be programmatically determinable. The second, language of parts, extends that to passages within the page that switch language.
Whether a page declares a language, and whether the tag is well formed, are among the small number of things an automated tool settles outright. Our free scan checks it. So if the entire worry is a missing or wrong language attribute, run a scan and keep the money, because a human is not needed to find that one.
What a machine cannot check is whether the declaration is correct. A German page marked as English is well formed, passes every automated rule, and is read aloud with English pronunciation rules applied to German words. To a sighted reviewer the page looks perfect, which is exactly why that failure survives for years. Catching it requires somebody who can hear that the output is wrong.
Right to Left Is a Sequence Problem Wearing a Layout Costume
Adding Arabic, Hebrew, Farsi or Urdu introduces a category of failure the other locales never surface, and it is worth scoping deliberately rather than hoping the CSS handled it. Mirroring a layout is a visual operation. Reading order and focus order are sequence properties, and the two can come apart.
When they do, a sighted reader sees a correctly mirrored page while a screen reader user hears the columns in the original order. A keyboard user tabs through controls in a sequence that no longer matches what is on screen. Those are failures of meaningful sequence and focus order, two criteria that have nothing to do with translation and everything to do with what the mirroring actually moved.
Bidirectional text inside a single line adds its own problems, where a Latin product name or a phone number sits inside a right-to-left sentence and the punctuation lands in the wrong place. That one is usually visible if somebody who reads the language looks at it, which is the point. Testing a right-to-left locale without a reader of that language is checking that the markup is plausible rather than that the page works.
The One Statement WCAG Provides for Missing Support
There is a case where the support your locale needs does not exist, and the standard has a named response to it rather than leaving you to improvise. It is a statement of partial conformance due to language, and its shape is fixed. The page does not conform, but would conform at level X if accessibility support existed for the named languages.
Notice what that sentence is. It is a declaration of non-conformance with a reason attached, published deliberately. It is not a pass, not a waiver, and not a way to describe a locale you simply did not test. The condition is that support does not exist, which is a claim about the state of assistive technology in that language rather than about your schedule.
Used honestly it is a good thing to know about, because it lets you publish an accurate picture of a genuinely difficult locale instead of either overclaiming or saying nothing. Used as cover for untested languages it is worse than silence, because it asserts something about the world that a reader may go and check.
Scoping It, and What We Can Actually Hear
The methodology asks for locale coverage to be settled at the start rather than discovered later. Its scope step names mobile and language versions of the product among the things to document when identifying the evaluation target, alongside third-party content and parts of the product that are not easily identifiable as such. So the locale list is part of the scope statement, written down before testing.
Its guidance on sample size points the same way. Products available in different versions, or served according to users and their preferences, need larger samples to cover those situations, and a locale switcher is exactly that kind of variation. A quote that treated your seven locales as one site has underestimated the work rather than found you a saving.
One limit on our side belongs here rather than in small print. The binding constraint on this work is which screen reader languages our testers can genuinely run, and that is a shorter list than the set of languages a site might ship in. So the first thing to do is send the locale list, and the answer comes back saying which ones we can hear properly, before anything is paid for. Our language and localization review covers the work itself.
And a boundary that saves a recurring confusion. We audit accessibility rather than translation quality. Whether each locale announces in the right language with the right structure is our question. Whether the French reads like good French is your translator's.
Where This Page Stops
Language versions are where accessibility scope runs into questions of which country's law reaches you, and this page does not answer those. Shipping a Spanish site does not by itself put you inside Spanish law, and shipping only in English does not keep you out of anywhere. What decides it is where you offer the service, to whom, and under which regime, and those are questions about your business rather than about your markup.
A lawyer in each relevant jurisdiction answers that, and the answer sometimes changes which locales you would prioritise testing. A page on which laws apply is the starting point. Have that conversation before the locale list is finalised rather than after.