Skip to content

Test your website now

Free, no card. We read only public pages.

Run free audit →

Accessibility · WCAG 3.1.2 level AA

Lang Attribute Must Have a Valid Value: Identify the Actual Language

Fix language declarations in page content. Use appropriate BCP 47 tags, verify the real language, and distinguish checker vocabulary from full validation.

Published · Updated

What the check tests

Check
a11y.axe.valid-lang - lang attribute must have a valid value
Passes when
Ensure lang attributes have valid values
Scope
graded on every page crawled
Conformance
WCAG level AA
Fix effort
small - under an hour

In one paragraph

Lang attribute must have a valid value means a tested passage declaration did not meet this rule's language-code validation. Use an appropriate registered language tag that describes the actual text, not a country code or language name. The supplied checker examines only part of the tag and cannot determine linguistic accuracy. Review root language and language changes separately, including valid tags outside a narrow implementation vocabulary.

Why it matters

WCAG 3.1.2 concerns identifying the human language of passages or phrases, with exceptions such as proper names, technical terms, and adopted vernacular. It does not require a separate tag on every word that originated in another language.

Language is different from country. Czech commonly uses cs, Ukrainian uk, and Japanese ja. A region can be added when justified, but it does not replace the primary language. BCP 47 also supports script and other subtags; do not declare every unfamiliar or longer form invalid based only on its shape.

Speech and braille behaviour depends on available voices, settings, and accessibility processing. Correct markup can still produce imperfect pronunciation, especially when a computed accessible name flattens language information. Evaluate the declaration itself as well as real output rather than promising universal automatic voice switching.

How WebAuditOS evaluates this finding

The supplied valid-lang rule inspects applicable non-root elements with lang or xml:lang and compares the primary subtag with its version-specific known-code list. It has documented text and empty-value applicability cases; root html declarations use separate checks.

Serious impact maps to high severity. It does not validate every region or script subtag or decide whether a recognised code matches the text. A passing en prefix with an inappropriate remainder is not a full BCP 47 validation or a proof the passage is English.

How to fix it

  1. Read the actual passage and identify an intended language change. Distinguish a genuine quoted phrase from a proper name or ordinary adopted word covered by an applicable exception.
  2. Choose the appropriate language tag from a standards-aware reference, not a country picker copied directly into markup. Use canonical forms where practical without treating case alone as a different language.
  3. Mark the relevant scope. For example, within an English page:
<p>The notice says <span lang="fr">Livraison gratuite</span>.</p>

This is an illustrative language change. Use the real language and meaningful surrounding content rather than tagging every foreign-looking word.

  1. Keep root and local declarations coherent. A descendant normally inherits the surrounding language unless appropriately overridden; incorrect global metadata cannot be repaired by guessing isolated tags.
  2. Review CMS and localisation outputs, including hidden alternatives and rendered attribute changes. A language name such as english is not the same as the en code, and a valid code for another language is still wrong for this text.
  3. Validate full tags separately from the engine's primary-subtag list. A narrow or outdated checker can reject legitimate vocabulary, while its permissive suffix handling can miss an invalid full tag.
  4. Test appropriate reading modes and supported assistive technology where feasible. A flattened link-name list can lose language boundaries despite correct underlying markup; document platform limitations without mislabelling every such result as author failure.
  5. Rescan the applicable language checks and review content accuracy manually. Do not use empty lang merely to suppress a warning when the language is known and should be identified.

What the fix can break

Over-tagging borrowed words can produce distracting switching, while under-tagging a substantial passage can leave its meaning hard to follow. Apply the actual criterion and its exceptions.

Changing language can affect typography as well as speech. Test hyphenation, script rendering, and appropriate directionality independently.

Do not replace every three-letter or script-qualified tag with a guessed two-letter code. Preserve accuracy and evaluate supported vocabulary with an appropriate reference.

Questions

Does this rule validate the complete tag?

No. The supplied description validates the primary code and leaves other details outside its test.

Does every foreign proper name require a tag?

Not automatically. The criterion has specific exceptions; apply them thoughtfully.

Does correct markup guarantee perfect pronunciation?

No. User-agent capabilities and accessible-name processing can limit output. Evaluate markup and supported behaviour separately.

Review root language, lang/xml:lang consistency, and the automation limits guide.

What severity does this get in the report?

High. An axe finding takes its severity from the impact axe reports for the element that failed, and the report maps critical and serious to high, moderate to medium, minor to low. This rule is declared serious in axe-core 4.13.0, so a failure arrives as high - which is why the panel above states a conformance level rather than a severity.

Standards and sources

In the report

Test this on your own site

Every scan runs a11y.axe.valid-lang on every page it crawls, on every plan. The finding carries this id, so a line in a report can be matched to the explanation above - and the free scan needs no account.