Accessibility Guides for cognitive
Learn how to identify and fix common accessibility issues flagged by Axe Core — so your pages are inclusive and usable for everyone. Also check our HTML Validation Guides.
The list of 53 Input Purposes for User Interface Components are used as the basis for the programmatic definition of the purpose for each common input field that collects user data.
For screen readers to work properly, the autocomplete attribute values must be true and applied correctly.
Inaccessible content stems from missing autocomplete values in form fields. In the absence of the necessary autocomplete attribute values, screen readers will not read the identified autocomplete form fields.
When screen readers are unable to adequately notify users about the requirements for form field interaction, users cannot successfully navigate forms.
What this Accessibility Rule Checks
The purpose of each user-information-collecting input field can be established programmatically when:
- The input field fulfills a purpose specified in the Input Purposes for User Interface Components section, and
- The content is implemented using technologies that provide support for determining the desired meaning of form input data.
Ensure that the text spacing specified by style attributes is modifiable using custom stylesheets.
When lines of text are single-spaced, many people with cognitive difficulties have difficulty following them. Providing spacing between 1.5 and 2 makes it easier for them to begin a new line after finishing the previous one.
What this Accessibility Rule Checks
Text line spacing must be modifiable by custom stylesheets.
This rule demands the absence of any blink elements. Blinking items might be challenging to activate, and flashing writing can be challenging to read.
The blink tag causes information to blink, as the name implies. Although you might enjoy the appearance, blinking text and objects (such as links and buttons) might be challenging to read and operate, especially for people with poor hand-eye coordination or limited dexterity.
For those who have visual or cognitive impairments, reading blinking letters can be quite challenging. Text that blinks can be annoying, especially for people who have cognitive difficulties. Some people may find it challenging to understand. The blink element should never be used due to these reasons.
What this Accessibility Rule Checks
Verifies that the blink element is never utilized.
The screen orientation (such as portrait or landscape) of mobile applications should not be restricted to a single mode. Users should be able to shift the orientation of their device between portrait and landscape without losing readability. Additionally, upon opening a page, it should appear in the current orientation of the user.
Users of assistive technologies may not have access to orientation features on their devices or assistive technologies.
What this Accessibility Rule Checks
Unless a specific display orientation is important, content does not confine its view and functionality to a single display orientation, such as portrait or landscape.
Screen readers rely on distinct sound libraries for each language, with pronunciation rules, intonation patterns, and phonetics tailored to that specific language. When a user navigates to a page, the screen reader checks the lang attribute on the <html> element to determine which sound library to load. If no lang attribute is present, the screen reader falls back to whatever default language the user configured during setup. For someone who speaks multiple languages and browses websites in different languages, this creates a serious problem — the screen reader will attempt to read foreign-language content using the wrong pronunciation rules, producing garbled or incomprehensible speech.
This issue primarily affects blind and deafblind users who rely on screen readers, but it also impacts users with cognitive disabilities who may use text-to-speech tools. When text is read aloud with the wrong language rules, even simple words become unrecognizable, effectively making the content inaccessible.
Related WCAG Success Criteria
This rule maps to WCAG 2.0, 2.1, and 2.2 Success Criterion 3.1.1: Language of Page at Level A — the most fundamental level of conformance. This criterion requires that the default human language of each web page can be programmatically determined. It is also referenced by the Trusted Tester guidelines (11.A), EN 301 549, and RGAA.
How to Fix It
Add a lang attribute with a valid language code to the opening <html> element. The value should represent the primary language of the page content.
You can use a simple two-letter language code (like en for English, fr for French, or de for German), or you can be more specific with a regional dialect code like en-US for American English or fr-CA for Canadian French. A full list of valid language subtags is available in the IANA Language Subtag Registry.
If sections of your page contain content in a different language than the primary one, use the lang attribute on those specific elements so screen readers can switch sound libraries mid-page.
For languages written right to left (such as Arabic or Hebrew), also include the dir attribute with a value of rtl to indicate the text direction.
Examples
Incorrect: Missing lang attribute
This will trigger the rule because the <html> element has no lang attribute:
<html>
<head>
<title>My Website</title>
</head>
<body>
<h1>Welcome</h1>
</body>
</html>
Correct: lang attribute with a valid language code
<html lang="en">
<head>
<title>My Website</title>
</head>
<body>
<h1>Welcome</h1>
</body>
</html>Correct: Using a regional dialect code
<html lang="en-US">
<head>
<title>My Website</title>
</head>
<body>
<h1>Welcome</h1>
</body>
</html>Correct: Handling inline language changes
When a portion of the page is in a different language, use the lang attribute on the containing element:
<html lang="en">
<head>
<title>My Website</title>
</head>
<body>
<p>The French word for hello is <span lang="fr">bonjour</span>.</p>
</body>
</html>
Correct: Right-to-left language with dir attribute
<html lang="ar" dir="rtl">
<head>
<title>موقعي</title>
</head>
<body>
<h1>مرحبا</h1>
</body>
</html>
Screen readers rely on language-specific sound libraries to pronounce text accurately. Each language has its own pronunciation rules, intonation patterns, and phonetic characteristics, so screen readers load the appropriate library based on the declared language of the document. When the <html> element has no lang attribute or contains an invalid value — such as a misspelling or a fabricated code — the screen reader cannot determine which library to use. It defaults to whatever language the user configured during setup, which means content written in French might be read aloud using English pronunciation rules. The result is speech that sounds like a confusing, unintelligible accent.
This issue primarily affects blind users and deafblind users who rely on screen readers, but it also impacts users with cognitive disabilities who may use text-to-speech tools to aid comprehension. When pronunciation is wrong, understanding drops dramatically.
Related WCAG Success Criteria
This rule maps to WCAG Success Criterion 3.1.1: Language of Page (Level A), which requires that the default human language of each web page can be programmatically determined. This is a Level A requirement — the most fundamental level of accessibility — meaning it must be satisfied for basic compliance under WCAG 2.0, 2.1, and 2.2. It is also required by the Trusted Tester methodology, EN 301 549, and RGAA.
How to Fix It
-
Add a
langattribute to the opening<html>element. - Set its value to a valid BCP 47 language tag that represents the primary language of the page.
-
Double-check the spelling of the language code. Common valid codes include
"en"(English),"fr"(French),"es"(Spanish),"de"(German),"ja"(Japanese), and"ar"(Arabic). -
You can optionally include a regional subtag, such as
"en-US"for American English or"fr-CA"for Canadian French. -
For XHTML documents served as XML, use
xml:langinstead of or in addition tolang.
If the language changes within the document for specific passages, use the lang attribute on the appropriate element to indicate the switch. For right-to-left languages, also include the dir="rtl" attribute.
Examples
Incorrect: Missing lang attribute
<html>
<head>
<title>My Page</title>
</head>
<body>
<p>Welcome to my website.</p>
</body>
</html>
Without a lang attribute, screen readers cannot determine the page language and will default to the user’s configured language, which may not match the content.
Incorrect: Invalid lang value
<html lang="english">
<head>
<title>My Page</title>
</head>
<body>
<p>Welcome to my website.</p>
</body>
</html>
The value "english" is not a valid BCP 47 language tag. The correct code for English is "en".
Correct: Valid lang attribute
<html lang="en">
<head>
<title>My Page</title>
</head>
<body>
<p>Welcome to my website.</p>
</body>
</html>Correct: Regional subtag
<html lang="fr-CA">
<head>
<title>Ma page</title>
</head>
<body>
<p>Bienvenue sur mon site web.</p>
</body>
</html>Correct: Language change within the page
<html lang="en">
<head>
<title>Multilingual Page</title>
</head>
<body>
<p>This paragraph is in English.</p>
<p lang="es">Este párrafo está en español.</p>
</body>
</html>Correct: Right-to-left language
<html lang="ar" dir="rtl">
<head>
<title>صفحتي</title>
</head>
<body>
<p>مرحبا بكم في موقعي.</p>
</body>
</html>
The dir="rtl" attribute ensures the text direction is correctly rendered for right-to-left languages like Arabic and Hebrew.
For multilingual screen reader users who may prefer a language different than the default, the HTML content must contain a valid lang attribute or correlate to a valid lang code. If included on the html element, the xml:lang property value must exactly duplicate the value of the lang.
Users choose a default language when configuring a screen reader. If the language of a webpage is not provided, the screen reader uses the user’s default language. Users who speak and access websites in various languages have difficulties. For screen readers to function properly, a default language must be specified and ensured to be valid.
Screen readers employ various sound libraries for each language based on its pronunciation and characteristics. Screen readers can simply switch between language libraries if documents specify which language(s) should be read. Screen readers view texts in the user’s default language if the language is not specified, resulting in distorted language. When screen readers use the incorrect language library, it can be difficult to understand anything.
What this Accessibility Rule Checks
Ensures that every HTML document includes a valid lang attribute, and that the xml:lang value, if present, replicates the lang value.
Elements of type <marquee> are prohibited because they are deprecated, add difficulty for users with limited dexterity, and distract users with cognitive or attention problems.
The marquee element produces difficult-to-read and-click-on scrolling text. Furthermore, it can be disturbing to viewers, particularly those with low eyesight, cognitive impairments, or concentration difficulties.
People with attention difficulties or cognitive impairments may be distracted by scrolling content. People with inadequate fine motor skills may not be able to precisely click on links inside scrolling content. Users with visual impairments may not be able to read the content of the scrolling text with sufficient clarity.
What this Accessibility Rule Checks
Prevents the use of the deprecated marquee element.
Ensures that video or audio elements don’t have autoplay audio that lasts more than three seconds without a way to silence it.
When using screen reading software, people who are blind or have low vision may have trouble hearing the screen reader’s spoken output if other audio is playing at the same time.
If automatically playing audio continues for more than three seconds, it must be possible to pause, stop, or adjust the level using a well placed, easily accessible mechanism.
Users of screen readers can hear the screen reader without any other sounds playing thanks to an audio control.
A screen reader user’s ability to find the stop button may be hampered if audio starts playing immediately when they land on a page. This is because they navigate by listening, and automatically starting sounds may obstruct that navigation.
Therefore, we oppose the practice of automatically starting sounds (especially if they run longer than three seconds) and encourage users to start the sound themselves once they arrive at the page rather than expecting them to stop the sound themselves once they have reached the page.
What this Accessibility Rule Checks
The algorithm for this rule returns:
-
Undefined when
<audio>has no source (duration cannot be interpreted). -
Undefined when
<video>has no source (duration cannot be interpreted). -
False when
<audio>can autoplay and has no controls mechanism. -
False when
<video>can autoplay and has no controls mechanism -
False when
<audio>plays less than three seconds but loops. -
True when
<video>can autoplay and duration is less than three seconds (by passing options). -
True when
<video>can autoplay and duration is below allowed duration (by setting playback range). -
True when
<audio>can autoplay but has controls mechanism. -
True when
<video>can autoplay and has controls mechanism.
To guarantee that text is pronounced correctly for screen reader users, the language given in the HTML content must be one of the valid languages.
The default language is chosen by users when setting up a screen reader. The screen reader assumes that a webpage is in the user’s default language when the language is not selected. When visitors access the website in more than one language and speak various languages, choosing a language becomes problematic. To ensure that website text is pronounced accurately, a language must be specified and validated.
Based on the pronunciation and traits of each language, screen readers employ distinct sound libraries for each one. If the papers specify which language(s) to read, screen readers can quickly switch between these language libraries. The screen reader will read the content in the user’s default language if the language is not set, which can be confusing.
What this Accessibility Rule Checks
The value of the lang attribute must be correct.
Ready to validate your sites?
Start your free trial today.