Check that HTML declares the correct page language and marks sections written in other languages. Find missing, empty, or invalid language tags and suggest corrections that support screen reader pronunciation, browser translation, and spell checking.
Use when applies to all HTML documents. Check the `<html>` opening tag for a `lang` attribute with a non-empty, valid BCP 47 language code. Also check for `lang` attribute changes on individual elements when the document contains content in multiple languages (inline quotes, foreign terms, multilingual sections). The `lang` attribute is inherited — child elements inherit the language from their nearest ancestor with `lang`.
Review the instructions the agent will receive before you install.
Screen readers select the correct text-to-speech voice and pronunciation engine based on the lang attribute. Without it, VoiceOver defaults to the user's system language, and NVDA uses its default voice — both may mispronounce words in other languages, making content unintelligible. French text read with an English voice profile is incomprehensible. The lang attribute also enables browser translation features (Chrome's Translate), hyphenation algorithms (CSS hyphens: auto), and correct spell checking. This is a WCAG Level A requirement — the most fundamental accessibility baseline.
<html> element must have a lang attribute — WCAG 2.1 SC 3.1.1 (Language of Page, Level A)en, en-US, fr, zh-Hant, ar, etc.lang on individual elements to indicate language changes within the page — WCAG 2.1 SC 3.1.2 (Level AA)lang attribute affects screen reader pronunciation, spell checking, hyphenation, and browser translationlang='' is treated as unknown language — equivalent to having no lang attributeInspect the <html> element in the page source. Verify: (1) a lang attribute is present; (2) its value is non-empty; (3) its value is a valid BCP 47 language code matching the primary language of the page content (e.g., en for English, fr for French, zh-Hant for Traditional Chinese). Flag: missing lang, empty lang='', language codes using full names instead of codes (e.g., lang='english' is invalid), and mismatches where the declared language does not match the actual content language. For multilingual pages, also check for lang changes on block-level elements containing content in a different language.
Add or correct the lang attribute on the <html> element: <html lang='en'> for English, <html lang='fr'> for French, <html lang='es'> for Spanish, <html lang='de'> for German, <html lang='ja'> for Japanese, <html lang='zh-Hans'> for Simplified Chinese, <html lang='zh-Hant'> for Traditional Chinese, <html lang='ar'> for Arabic. For content sections in different languages, add lang to the containing block element. Validate language codes against the IANA Language Subtag Registry.
WCAG 2.1 SC 3.1.1 (Language of Page, Level A) requires that the default human language of each web page can be programmatically determined. The lang attribute on <html> fulfills this requirement. The value must be a BCP 47 language tag — a standardized system of subtags that identifies language, script, and region. The primary language subtag (e.g., en, fr) is required; region subtags (e.g., en-US, fr-CA) are optional but useful for dialect-specific pronunciation and spell checking. SC 3.1.2 (Language of Parts, Level AA) extends this to inline language changes within a page.
Review templates, server-rendered HTML, and shared components that output markup related to Set the page lang attribute. Flag exact elements, attributes, and routes where the rendered HTML violates the rule.
For full implementation details, code examples, and framework-specific guidance,
see references/rule.md.
Rule page: https://frontendchecklist.io/rules/html/lang-attribute
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Create and review custom 404 pages that help visitors recover from broken or moved links through search and navigation. Check the rendered page and HTTP response so missing content returns a proper 404 status.
Audit or create a dedicated About page that explains a website’s purpose and identifies its people or organization. Review the rendered output and supporting information, including expertise and contact details, to find gaps.
Review and add automated accessibility checks for components, pages, and continuous integration workflows. Use axe-based tools to detect structural and attribute issues, while identifying checks that still need keyboard or screen reader testing.
Review sign-in, registration, multi-factor authentication, and account recovery for accessibility barriers. Find blocked paste, difficult code entry, and inaccessible backup methods, then suggest authentication paths that support password managers, autofill, or device approval.
Review form errors, success messages, and live updates so screen reader users receive important notifications. Check the HTML delivered to the browser, announcement settings, display duration, and dismissal controls, then identify specific elements that need changes.
Review HTML tables so screen reader users can understand how headers and data relate. Check header markup, table descriptions, and merged cells, then identify specific fixes and ways to verify them.