Objective: Provide text alternatives for all non-text content so that it can be transformed into other forms people can read, including large print, braille, speech, symbols, or simpler language.

Why It's Important (User Benefit):

• Allows blind or visually impaired people to understand the content of images and graphic elements via screen readers.
• Enables users with cognitive disabilities to process information in a simpler, adaptable text format.
• Improves SEO (Search Engine Optimization) and image indexing by search engines.

What to Check / How to Implement:

• Informative Images: For every image that conveys meaning, the `alt` attribute must contain a concise and meaningful description of its content or function.

  <img src="grafico.png" alt="Quarterly sales chart with a 15% increase in Q4">

• Decorative Images: If an image is purely aesthetic and adds no information (e.g., borders, backgrounds), the `alt` attribute must be left empty (`alt=""`).

  <img src="sfondo.jpg" alt="">

• Icons/Image Buttons: If an icon is clickable, the `alt` attribute (or `aria-label`) must describe the button's action, not just the image (e.g., `alt="Search"` for a magnifying glass).
• Complex Charts/Diagrams: In addition to alt text, provide a "long description" (e.g., via `aria-describedby` or a link to a separate page) that explains the informative content in detail.
• Audio/Video Content: Offer full transcripts (for audio) and/or detailed descriptions (for silent or visual-only videos).

Common Mistakes to Avoid:

• Completely omitting the `alt` attribute.
• Using generic or redundant `alt` text (e.g., `alt="image"`, `alt="photo.jpg"`, `alt="click here"`).
• `alt` text that is too long or includes details unnecessary for the context.
• Not providing transcripts or descriptions for important multimedia content.

Useful Tools for Testing:

• Browser Extensions: Axe DevTools, Lighthouse, WAVE, Web Developer (to view alt text).
• Screen Reader: Navigate the page with a screen reader (e.g., NVDA, JAWS, VoiceOver) to hear how text alternatives are read.
• Disable Images: In browser settings, disable image loading to see the alternative text in their place.

Objective: Provide an alternative for prerecorded audio-only or video-only content so that all information conveyed is accessible to those who cannot perceive it.

Why It's Important (User Benefit):

• Deaf or severely hearing-impaired users can access audio content via a text transcript.
• Blind or visually impaired users can access visual content via a text description.
• Allows consultation in environments where audio/video is not usable (e.g., public places, slow connections).

What to Check / How to Implement:

• Audio-Only Content: Offer a complete text transcript of the dialogue and all significant sounds (e.g., music, important sound effects) present in the audio. The transcript should be easily accessible and associated with the audio (e.g., below the player or via a link).
• Video-Only Content: Provide a detailed text description of all significant visual events and information presented in the video (e.g., actions, objects, on-screen text).

Common Mistakes to Avoid:

• Not providing any text alternative for audio or video.
• Incomplete transcripts or those that omit important sounds.
• Generic video descriptions that do not capture the visual meaning.

Useful Tools for Testing:

• Manual Review: Carefully compare the audio/video with the transcript/description to verify completeness and accuracy.
• User Involvement: Have people with visual or hearing disabilities test it.

Objective: Provide synchronized captions for all prerecorded audio content in videos, including dialogue and significant non-verbal sounds.

Why It's Important (User Benefit):

• Allows deaf or hard-of-hearing people to access the audio content of videos.
• Useful in noisy environments or where audio cannot be heard.
• Facilitates comprehension for non-native speakers or those with cognitive difficulties.

What to Check / How to Implement:

• Synchronized Captions: Ensure that captions are available and perfectly synchronized with the audio and video.
• Complete Content: Captions must include all spoken dialogue and, where significant, non-verbal sounds (e.g., `[dramatic music]`, `[applause]`).
• Appropriate Format: Use supported caption formats (e.g., WebVTT, SRT) and ensure the video player allows activation/deactivation and customization (if possible).

Common Mistakes to Avoid:

• Complete lack of captions.
• Inaccurate, incomplete, or transcription error-filled captions.
• Incorrect synchronization (captions appearing too early or too late).
• Omission of important non-verbal sounds.

Useful Tools for Testing:

• Manual Test: Watch the video with audio off and check comprehension through captions.
• Screen Reader: Verify that the player is accessible and captions do not interfere.

Objective: For prerecorded videos with an audio track, provide an audio description that narrates essential visual content for blind users, or a complete text alternative.

Why It's Important (User Benefit):

• Allows blind or visually impaired people to understand visual information not explained in the audio dialogue.
• Offers a complete multimedia content experience to all users.

What to Check / How to Implement:

• Audio Description: Integrate an additional audio track that describes visual scenes, actions, on-screen text, and other relevant visual details not already present in the main dialogue.
• Text Media Alternative: Alternatively, provide a complete text transcript that includes both dialogue and a detailed description of the visual content.

Common Mistakes to Avoid:

• Lack of audio description for videos that require one.
• Incomplete or too short audio description.

Useful Tools for Testing:

• Manual Test: Watch the video with your eyes closed and check if the audio description allows you to understand all important visual information.

Objective: Provide synchronized captions for all live audio content in videos.

Why It's Important (User Benefit):

• Essential for deaf or severely hearing-impaired people to access live events.
• Allows real-time participation in webinars, live broadcasts, conferences.

What to Check / How to Implement:

• Real-time Captions: Implement a solution for real-time caption generation (e.g., via human transcribers, speech recognition technologies with review).
• Accuracy and Synchronization: Ensure that captions are as accurate and synchronized as possible, taking into account the challenges of live content.

Common Mistakes to Avoid:

• Lack of captions for live content.
• Automatically generated captions with a high percentage of errors.

Useful Tools for Testing:

• Manual Test: Monitor the quality and timeliness of captions during a live event.

Objective: Provide an audio description for all prerecorded video content. This criterion is a more stringent requirement than 1.2.3, requesting an audio description for all videos, even if there is already a main audio track.

Why It's Important (User Benefit):

• Ensures that blind people receive all important visual information.

What to Check / How to Implement:

• Audio Description Inclusion: Ensure that all prerecorded videos have an audio description track, even if brief, that narrates significant visual content.

Common Mistakes to Avoid:

• Lack of audio description.

Useful Tools for Testing:

• Manual Test: Listen to the video with the audio description activated to evaluate its completeness.

Objective: Ensure that the structure, relationships, and meaning of content are understandable not only visually, but also programmatically (via code). This allows assistive technologies to correctly interpret the hierarchy and role of page elements.

Why It's Important (User Benefit):

• Improved Navigation: Allows screen reader users to navigate the page efficiently (e.g., by jumping from heading to heading or exploring lists).
• Contextual Understanding: Helps all users understand the relationship between different page elements (e.g., labels vs. form fields, cells vs. table headers).
• Consistency and Personalization: Ensures that content is presented consistently and meaningfully, also facilitating user customization.

What to Check / How to Implement:

• Heading Hierarchy (<h1> - <h6>):
  • Use heading tags for logical structure (only one <h1> per page).
  • Do not skip heading levels (e.g., from <h1> to <h3>).
• Lists (<ul>, <ol>, <dl>):
  • Use semantic elements for all lists.
  • Avoid simulating lists with simple divs or paragraphs.
• Forms:
  • Always associate <label> with each input control using `for` and `id`.
  • Group related controls (e.g., radio buttons) with <fieldset> and <legend>.
• Data Tables (<table>, <th>, <caption>):
  • Use tables only for tabular data, never for layout.
  • Identify headers (<th> with `scope`) and provide a <caption>.
• ARIA Roles (Accessible Rich Internet Applications):
  • Use ARIA attributes to define roles, properties, and states of complex or custom UI components.

Common Mistakes to Avoid:

• Misleading Visual Hierarchy: Using only visual styles (bolding, font size) for headings without using <h1>-<h6> tags.
• Missing or Unassociated Labels: Form fields without <label> or with `label` not correctly linked.
• Tables Used for Layout: Misuse of the <table> element for visual positioning.
• Non-Semantic Structure: Creating lists or other structural elements using only <div> or <p> without the correct semantic elements.

Useful Tools for Testing:

• Accessibility Browser Extensions: Axe DevTools, Lighthouse, WAVE Evaluation Tool.
• Screen Reader: NVDA, JAWS (Windows), VoiceOver (macOS).
• HTML Validator: W3C Markup Validation Service.

Objective: Ensure that when the sequence of content (visual presentation) affects its meaning, the programmatic reading and interaction order is also meaningful and logical. This is crucial for users who access content in a different order than the visual one (e.g., with screen readers).

Why It's Important (User Benefit):

• Logical Consistency: Ensures that content makes sense regardless of how it is perceived (visually, via screen reader, keyboard navigation).
• Efficient Navigation: Helps assistive technology users follow the logical flow of the document without confusion or unexpected jumps.
• Improved User Experience: Prevents frustration and disorientation for all users, especially in complex layouts.

What to Check / How to Implement:

• Logical Reading Order: The DOM (Document Object Model) sequence must reflect the logical content order intended by the author. What appears first visually should generally come first in the code.
• Related Content: If content is related (e.g., a question and its answer options), ensure they are close in the HTML code to maintain their relationship.
• CSS Layout: Avoid using CSS to reorder elements in such a way that the visual order is drastically different from the DOM order, especially for interactive or informative elements. If you do, carefully check accessibility.
• Linearized Content Test: Imagine reading the page without CSS; does the content still make sense? Does keyboard scrolling (tabbing) follow a logical path?

Common Mistakes to Avoid:

• Visual/DOM Order Discrepancy: The order of elements in the HTML code does not match the logical or visual order, causing confusion for screen readers.
• Scattered Content: Related information (e.g., a warning and the button to close it) is positioned far apart in the HTML code.
• Extreme Reordering via CSS/JavaScript: Misuse of CSS properties like `order` in flexbox/grid or JavaScript manipulations that heavily alter the visual order relative to the DOM, without considering tab order or reading order.

Useful Tools for Testing:

• Keyboard Navigation: Navigate the entire page using only the Tab key (and Shift+Tab to go back) to verify that the focus moves in a logical and meaningful order.
• Screen Reader: Listen to the content with a screen reader (e.g., NVDA, JAWS, VoiceOver) to ensure that the reading sequence is as expected and understandable.
• Code Inspection: Examine the order of elements in the DOM (using browser developer tools) and compare it with the visual order.

Objective: Instructions provided for understanding and operating content must not rely solely on the sensory characteristics of components (shape, size, color, location, orientation, or sound).

Why It's Important (User Benefit):

• Allows people with blindness, color blindness, or cognitive disabilities to understand instructions even if they do not perceive certain sensory characteristics.
• Ensures that directions are clear and unambiguous for everyone.

What to Check / How to Implement:

• Redundant Instructions: If you use color to indicate status (e.g., red for error), always add a text indicator or an icon (e.g., "Required field missing" or a warning icon).
• Shapes/Sizes: If instructions refer to shapes or sizes ("Click the round button"), add a text alternative ("Click the 'Submit Order' button").
• Position/Orientation: Avoid instructions like "Click the icon on the right" or "Look at the menu at the top" without providing a specific text alternative for the element.

Common Mistakes to Avoid:

• Saying "click the red button" without providing the button's text.
• Indicating required fields only with a red asterisk, without a phrase like "(required)".

Useful Tools for Testing:

• Manual Test: Try to understand the instructions without looking at colors or shapes.
• Color Blindness Simulation: Use browser extensions to simulate different forms of color blindness to verify the clarity of information.

Objective: Color must not be the only visual means of conveying information, indicating an action, soliciting a response, or distinguishing a visual element.

Why It's Important (User Benefit):

• Colorblind people or those with color perception issues can understand all information.
• Improves clarity and usability for all users, even in poor lighting conditions or on low-quality screens.

What to Check / How to Implement:

• Redundancy: If information is conveyed via color, there must be another indicator (e.g., text, icon, underline for links). * *Example:* Instead of "Red fields are required," use "Red fields with an asterisk (*) are required."
• Links: Links should have an additional indicator besides color when not in the body text (e.g., underline or an icon on hover/focus).
• Charts: In charts, in addition to colors, use patterns, text labels, or icons to distinguish different data series.

Common Mistakes to Avoid:

• Indicating an error only by coloring the message text or field red.
• Using color to show status (e.g., selected item) without another visual indicator.

Useful Tools for Testing:

• Color Blindness Simulation Extensions: Colorblinding, NoCoffee.
• Manual Test: Convert the page to grayscale to see if all information is still clear.

Objective: If any audio on a web page plays automatically for more than 3 seconds, a mechanism must be available to pause, stop, or control the volume independently of the overall system volume.

Why It's Important (User Benefit):

• Users who use screen readers or other auditory aids may find unexpected audio distracting or covering their aid's audio.
• Improves general usability, preventing sudden sounds that can startle or annoy users.

What to Check / How to Implement:

• Visible Controls: Ensure there are clear and visible buttons (Pause, Stop, Mute) for automatically playing audio.
• No Autoplay: The best practice is to avoid autoplaying audio altogether. Let the user decide when to start the audio.

Common Mistakes to Avoid:

• Audio that starts automatically and cannot be stopped or muted.

Useful Tools for Testing:

• Manual Test: Visit the page and immediately check if the audio starts and if you can easily control it.

Objective: Ensure a sufficient contrast ratio between text (and text in images) and their background, to guarantee readability for people with visual impairments or color blindness.

Why It's Important (User Benefit):

• Increases readability for people with low vision or color blindness.
• Improves readability for all users in adverse lighting conditions (e.g., intense sunlight) or on low-quality screens.

What to Check / How to Implement:

• Normal Text: The contrast ratio must be at least 4.5:1 for normal-sized text.
• Large Text: For large text (at least 18pt / 24px, or 14pt / 18.66px and bold), the contrast ratio must be at least 3:1.
• Logos and Decorative Elements: Does not apply to logos or text that is part of a purely decorative image.

Common Mistakes to Avoid:

• Light text on a light background or dark text on a dark background with insufficient contrast.
• Backgrounds with patterns or images that reduce text contrast.

Useful Tools for Testing:

• Contrast Analyzers: Contrast Checker (online), Colour Contrast Analyser (desktop application), browser extensions like Axe DevTools or Lighthouse.

Objective: Ensure that text can be resized up to 200% without loss of content or functionality, and without requiring the use of horizontal scrolling.

Why It's Important (User Benefit):

• Essential for people with low vision who need larger text to read.
• Improves usability for all users on various devices and screen sizes.

What to Check / How to Implement:

• Browser Zoom: Test the page by zooming the browser up to 200% (e.g., Ctrl + Plus or Cmd + Plus).
• Relative Units: Use relative units for font sizes (e.g., `em`, `rem`, `%`, `vw`) instead of fixed pixel units (`px`).
• Responsive Design: Ensure that the layout adapts correctly and does not require horizontal scrolling.

Common Mistakes to Avoid:

• Text overlapping or disappearing at 200% zoom.
• Horizontal scrolling being required to read the entire text.

Useful Tools for Testing:

• Browser Zoom: Test directly in the browser's zoom function.

Objective: Avoid using images of text unless the text is purely decorative or is part of a logo/brand name. When images of text are necessary, provide a text alternative for all content presented visually in the image.

Why It's Important (User Benefit):

• Text in images cannot be resized, customized, or read by screen readers.
• Improves SEO as text is directly searchable.

What to Check / How to Implement:

• Actual Text: Prefer CSS-styled real text whenever possible.
• Alt Text: If using an image of text is unavoidable, ensure a comprehensive `alt` attribute that replicates the text in the image.

Common Mistakes to Avoid:

• Using images for headings, paragraphs, or important instructions.

Useful Tools for Testing:

• Disable Images: Disable image display in the browser to identify images of text.

Objective: Content must be able to be presented without loss of information or functionality, and without requiring two-dimensional scrolling, when resized to 400% width or height without increasing line length (responsive design).

Why It's Important (User Benefit):

• Crucial for users with low vision who magnify content significantly.
• Improves usability on small screens or when using screen magnifiers.

What to Check / How to Implement:

• Zoom 400%: Test the page by zooming up to 400% (typically equivalent to a viewport width of 320 CSS pixels for a desktop browser).
• No Horizontal Scrolling: Ensure no horizontal scrollbar appears at 400% zoom. Vertical scrolling is allowed.
• Responsive Layout: Implement a fluid and responsive layout that adapts gracefully to various screen sizes and zoom levels.
• Content Wrapping: Text and content blocks should wrap to fit the available width.

Common Mistakes to Avoid:

• Fixed-width layouts that break or require horizontal scrolling when zoomed.
• Content overflowing containers or overlapping at high zoom levels.

Useful Tools for Testing:

• Browser Zoom: Use the browser's native zoom functionality.
• Developer Tools: Use browser developer tools to simulate different viewports (e.g., set viewport width to 320px).

Objective: Ensure that the visual presentation of user interface components (e.g., buttons, input fields, checkboxes, sliders) and graphical objects (e.g., parts of diagrams or infographics) has a contrast ratio of at least 3:1 against adjacent colors.

Why It's Important (User Benefit):

• Helps users with low vision or color blindness to perceive and understand interactive elements and essential graphics.
• Improves the discoverability and usability of controls.

What to Check / How to Implement:

• Interactive Components:
  • Default State: Ensure a 3:1 contrast for borders or visual indicators of interactive components (e.g., a grey button border on a white background).
  • Focus/Hover State: When an element is hovered or focused, its visual change must also meet the 3:1 contrast.
• Graphical Objects:
  • Essential graphical information (e.g., distinct parts of a chart, icons conveying meaning) must have a 3:1 contrast with adjacent colors.

Common Mistakes to Avoid:

• Buttons or form fields blending too much with the background due to insufficient contrast.
• Icons that are barely visible against their background.

Useful Tools for Testing:

• Color Contrast Analyzers: Same tools as for text contrast (Colour Contrast Analyser, Axe DevTools).
• Design Tools: Use design tools (e.g., Figma, Sketch) with accessibility plugins to check contrast during design.

Objective: Ensure that users can adjust text spacing (line height, letter spacing, word spacing, paragraph spacing) without losing content or functionality, and without requiring horizontal scrolling.

Why It's Important (User Benefit):

• Crucial for users with dyslexia, cognitive disabilities, or low vision who benefit from increased spacing to improve readability.
• Supports personal stylesheets and browser extensions that modify text presentation.

What to Check / How to Implement:

• Relative Units: Use relative CSS units (e.g., `em`, `rem`) for line height, letter spacing, word spacing, and paragraph spacing. Avoid fixed pixel values.
• No Clipping/Overlap: When text spacing is increased (e.g., via a browser extension or custom stylesheet), ensure text does not overlap, get cut off, or disappear.
• No Horizontal Scroll: The layout should reflow without introducing horizontal scrolling.

Specific Spacing Requirements (from Understanding WCAG 2.1):

• Line height (line spacing) to at least 1.5 times the font size.
• Spacing following paragraphs to at least 2 times the font size.
• Letter spacing (tracking) to at least 0.12 times the font size.
• Word spacing to at least 0.16 times the font size.

Common Mistakes to Avoid:

• Using absolute units (`px`) for spacing, preventing user customization.
• Tight layouts that cannot accommodate increased spacing, leading to overlaps.

Useful Tools for Testing:

• Browser Developer Tools: Manually change CSS properties for text spacing to observe the effect.
• Browser Extensions: Text Spacing Bookmarklet, or extensions that allow injecting custom CSS, to simulate increased spacing.

Objective: Ensure that additional content displayed on hover or focus (e.g., tooltips, submenus, pop-ups) can be dismissed, is perceivable, and remains visible long enough for users to interact with it.

Why It's Important (User Benefit):

• Allows users with motor impairments to move the mouse away without losing the content.
• Ensures keyboard-only users can access and interact with the content.
• Gives users with cognitive disabilities or low vision enough time to perceive and process the information.

What to Check / How to Implement:

• Dismissible: The content must be dismissible without moving hover or keyboard focus, unless it conveys input error or does not obscure other content. Examples: pressing Esc key, or a close button.
• Hoverable (Persist on Hover/Focus): If moving the mouse or focus from the triggering element causes the additional content to disappear, that content must be hoverable so the user can move their pointer over it to keep it visible and interact with it.
  * Persistent: The content must remain visible until the user explicitly closes it, or until they move focus or pointer away from the trigger *and* the content itself.

Common Mistakes to Avoid:

• Tooltips that disappear as soon as the mouse moves from the trigger, preventing interaction.
• Submenus that close too quickly.
• Content on focus not accessible via keyboard.

Useful Tools for Testing:

• Keyboard Navigation: Use only the keyboard to access and interact with elements that show content on hover/focus.
• Mouse Test: Move the mouse slowly to see if the content persists and if you can interact with it.

Objective: All functionality of the content must be operable through a keyboard interface without requiring specific timings for individual keystrokes. This is essential for users who cannot use a mouse or other pointing devices.

Why It's Important (User Benefit):

• Essential for users with motor disabilities who cannot use a mouse.
• Allows navigation for screen reader users and those who prefer keyboard interaction.
• Improves efficiency for power users who rely on keyboard shortcuts.

What to Check / How to Implement:

• All Interactive Elements: Ensure that all interactive elements (buttons, links, form fields, pop-ups, menus, carousels, media players) can be activated and operated using only the keyboard (Tab, Enter, Spacebar, arrow keys).
• Logical Tab Order: The order of keyboard focus (when pressing Tab) must be logical and intuitive, following the visual flow of the page.
• No Keyboard Traps: Users must be able to move focus away from any component using only the keyboard. Avoid situations where focus gets "trapped" in a widget.
• Standard HTML Elements: Prefer standard HTML elements (<button>, <a>, <input>) as they have built-in keyboard accessibility.
• ARIA Attributes for Custom Components: For custom UI components built with non-semantic elements (e.g., <div>), use appropriate ARIA roles (role), states (aria-expanded), and properties (tabindex) to make them keyboard operable and expose their functionality to assistive technologies.

Common Mistakes to Avoid:

• Interactive elements that are only clickable with a mouse (e.g., a <div> with an `onclick` event but no `tabindex`).
• Illogical tab order that jumps around the page.
• Modals or custom widgets that trap keyboard focus, preventing users from closing them or interacting with other parts of the page.

Useful Tools for Testing:

• Manual Test: Navigate the entire page using only the `Tab` key (and `Shift+Tab` to go back). Use `Enter` and `Spacebar` to activate elements.
• Browser Extensions: Axe DevTools, Lighthouse (can identify some keyboard operability issues).
• Screen Reader: Test with a screen reader (e.g., NVDA, JAWS, VoiceOver) to ensure navigation and interaction work as expected.

Objective: If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can also be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.

Why It's Important (User Benefit):

• Prevents users who rely solely on the keyboard from getting stuck in specific parts of the page, leading to frustration and inability to complete tasks.
• Ensures a smooth and predictable navigation experience.

What to Check / How to Implement:

• Escape Key: For modal dialogs, pop-ups, or any temporary overlay, ensure that the `Esc` key closes them and returns focus to the previous element.
• Tab/Shift+Tab: When focus enters a component (e.g., a complex menu, a carousel with internal controls), ensure that hitting `Tab` (or `Shift+Tab`) will eventually move focus out of that component to the next (or previous) focusable element on the page.
• Instructions: If a custom component requires a specific key combination (other than standard Tab/Esc/arrows) to exit, clearly inform the user (e.g., "Press Ctrl+E to exit this section").

Common Mistakes to Avoid:

• A modal dialog opens and the user can tab through elements inside it, but cannot tab *out* of it or close it with `Esc`.
• Custom widgets that have internal tab cycles but no way to break out of them to the rest of the page.

Useful Tools for Testing:

• Manual Test: Use only the keyboard to interact with all components, especially those that open overlays or manage internal focus. Try to get "stuck" and verify exit methods.
• Browser Developer Tools: Inspect the `tabindex` values and JavaScript event listeners for focus management.

Objective: Ensure that when any user interface component receives keyboard focus, there is a visible indication of that focus.

Why It's Important (User Benefit):

• Crucial for sighted keyboard users (including those with low vision or cognitive disabilities) to know where they are on the page and which element they are currently interacting with.
• Aids navigation and reduces frustration.

What to Check / How to Implement:

• Visible Focus Indicator: Every interactive element (links, buttons, form fields, etc.) must have a clearly visible focus indicator when navigated to by keyboard (e.g., using the `Tab` key).
• Custom Focus Styles: It is acceptable to remove the browser's default focus outline provided a custom focus indicator is supplied that is equally or more visible.
• Focus Style: The focus style should be prominent (e.g., thick border, contrasting color, shadow). Avoid focus styles that are too subtle or blend with the background.

Common Mistakes to Avoid:

• Using `outline: none;` in CSS without providing a visible alternative.
• Focus indicators that have insufficient contrast.

Useful Tools for Testing:

• Manual Test: Navigate the entire page with the `Tab` key and carefully observe the focus indicator.
• Browser Extensions: Axe DevTools, Lighthouse (can detect the lack of focus style).

Objective: The default human language of each Web page can be programmatically determined.

Why It's Important (User Benefit):

• Allows screen readers to correctly pronounce content in the appropriate language.
• Improves the experience for users who use translation tools.

What to Check / How to Implement:

• `lang` attribute: Ensure that the `lang` attribute is set on the `<html>` tag with the correct language code (e.g., `<html lang="en">`).
• Consistency: The `lang` attribute must reflect the actual primary language of the page content.

Common Mistakes to Avoid:

• Omitting the `lang` attribute entirely.
• Setting the `lang` attribute to an incorrect language (e.g., `lang="es"` for an English page).

Useful Tools for Testing:

• Browser Extensions: Axe DevTools, Lighthouse (will flag missing or incorrect `lang` attributes).
• Manual Code Inspection: View the page source to verify the `<html lang="...">` tag.

Objective: The human language of each passage or phrase in the content can be programmatically determined.

Why It's Important (User Benefit):

• Allows screen readers to switch pronunciation for foreign words or phrases within the main text.
• Enhances the accuracy of translation tools for mixed-language content.

What to Check / How to Implement:

• `lang` attribute for specific elements: If a section of text, a word, or a phrase is in a different language from the primary language of the page, enclose it in an HTML element (e.g., `<span>`, `<p>`, `<div>`) and apply the `lang` attribute with the correct language code.

  <p>The restaurant offers a delicious <span lang="fr">Boeuf Bourguignon</span>.</p>

Common Mistakes to Avoid:

• Not declaring the language of foreign words or phrases, causing screen readers to mispronounce them.

Useful Tools for Testing:

• Screen Reader: Test phrases in different languages to ensure correct pronunciation.
• Manual Code Inspection: Look for instances of foreign text and verify if the `lang` attribute is applied correctly.

Objective: Changing the setting of any user interface component does not automatically cause a change of context, unless the user has been advised of the behavior before using the component.

Why It's Important (User Benefit):

• Prevents unexpected changes and disorientation, especially for users with cognitive or motor disabilities, or those using screen readers.
• Provides a predictable and stable user experience.

What to Check / How to Implement:

• No automatic submission: Do not automatically submit a form or navigate to a new page solely when a form field gains focus or its value changes (e.g., selecting an item from a dropdown should not submit the form immediately without a "Submit" button).
• Clear warnings: If a component *must* trigger a context change on focus or value change (e.g., a "Jump Menu" dropdown), clearly inform the user about this behavior beforehand (e.g., "Selecting an option will take you to a new page").
• Dedicated controls for actions: Interactive elements that trigger actions (like "Go" buttons for dropdowns or "Apply Filters") should require an explicit user action (click, enter) rather than implicit changes on focus.

Common Mistakes to Avoid:

• Dropdown menus that automatically submit the form when an option is selected.
• Form fields that, upon receiving focus, automatically trigger JavaScript to perform an action (e.g., displaying a hidden section that unexpectedly shifts content).

Useful Tools for Testing:

• Manual Test: Navigate through form fields and interactive elements using the keyboard (Tab key) and observe if any unexpected context changes occur.
• Mouse Test: Click on various form fields and controls to ensure no unexpected actions are triggered upon gaining focus.

Objective: Changing the setting of any user interface component does not automatically cause a change of context, unless the user has been advised of the behavior before using the component.

Why It's Important (User Benefit):

• Prevents unexpected changes and disorientation, especially for users with cognitive or motor disabilities, or those using screen readers.
• Provides a predictable and stable user experience.

What to Check / How to Implement:

• No automatic submission on input: Do not automatically submit a form or navigate to a new page solely when a form field's value changes (e.g., as soon as the user types a character in a text field, or selects an option in a dropdown).
• Clear warnings: If a component *must* trigger a context change on input (e.g., a "Jump Menu" dropdown), clearly inform the user about this behavior beforehand (e.g., "Selecting an option will take you to a new page").
• Dedicated action buttons: Actions that cause context changes (like form submissions, filtering results, or navigating) should be triggered by explicit user actions, such as clicking a "Submit" button or pressing Enter.

Common Mistakes to Avoid:

• Search boxes that automatically submit the query after each character typed.
• Filtering options that automatically update results or redirect the page immediately upon selection, without a "Filter" or "Apply" button.

Useful Tools for Testing:

• Manual Test: Interact with all form fields and input controls, typing or selecting values, and observe if any unexpected context changes occur without explicit user action (e.g., pressing a submit button).

Objective: Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user.

Why It's Important (User Benefit):

• Enhances predictability and reduces cognitive load, allowing users (especially those with cognitive disabilities or screen reader users) to learn and anticipate navigation.
• Promotes efficiency by enabling users to quickly find desired navigation links.

What to Check / How to Implement:

• Primary Navigation: Menus (e.g., global navigation, sidebar navigation) should appear in the same relative order on all pages where they are present.
• Footer Navigation: Links in the footer should maintain a consistent order across pages.
• Skipping Navigation: If a user chooses to reorder or customize navigation (e.g., through a personalized view), this is allowed. However, the default presentation must be consistent.

Common Mistakes to Avoid:

• Changing the order of main menu items from one page to another without user initiation.
• Shuffling the order of links in the footer across different sections of the website.

Useful Tools for Testing:

• Manual Test: Browse through multiple pages of the website and visually inspect the order of repeated navigation elements. Use a screen reader to verify the programmatic order as well.

Objective: Components that have the same functionality within a set of Web pages are identified consistently.

Why It's Important (User Benefit):

• Reduces cognitive load and confusion by ensuring that familiar functionalities are always labeled and presented similarly.
• Enhances predictability and learnability, especially for users with cognitive disabilities.
• Helps users who rely on muscle memory or visual cues to locate functions.

What to Check / How to Implement:

• Text Labels: If a button performs the same action (e.g., "Search"), its text label should be consistently "Search" across all pages, not "Find" on one page and "Look Up" on another.
• Icons: Icons used for the same functionality should be consistent (e.g., a magnifying glass for search). If an icon has a text label, that label should also be consistent.
• Alternative Text: The alternative text (e.g., `alt` attribute for images, `aria-label`) for functionally identical components should be consistent.

Common Mistakes to Avoid:

• Using different terms for the same action (e.g., "Add to Cart" on product page, "Buy Now" on category page, "Place Order" on checkout page for essentially the same "purchase" action).
• Varying icons for the same function without clear reasons.

Useful Tools for Testing:

• Manual Test: Review all pages of the website and systematically compare text labels, icons, and alternative texts for similar functionalities.

Objective: If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.

Why It's Important (User Benefit):

• Helps users with cognitive disabilities, low vision, or screen reader users to easily identify and understand what went wrong and how to fix it.
• Reduces frustration and improves the success rate of form submissions.

What to Check / How to Implement:

• Clear Textual Description: Provide a clear and concise error message in text that explains the nature of the error (e.g., "Email address is required," "Password must be at least 8 characters long").
• Programmatic Association: The error message should be programmatically associated with the field in error (e.g., using `aria-describedby` to link the input field to its error message, or `aria-invalid="true"` on the field itself).
• Visual Identification: Visually highlight the erroneous field (e.g., with a red border) in addition to the text message. However, color alone must not be the only indicator (WCAG 1.4.1).
• Placement: Error messages should be placed close to the field they refer to, preferably just below or next to it.

Common Mistakes to Avoid:

• Generic error messages like "Error submitting form."
• Highlighting errors only with color (e.g., just turning the field red without a text message).
• Error messages that are visually far from the relevant field.

Useful Tools for Testing:

• Browser Extensions: Axe DevTools, Lighthouse (excellent for detecting missing error messages and programmatic associations).
• Screen Reader: Test submitting forms with errors to ensure the error messages are read aloud and correctly associated with their fields.

Objective: Labels or instructions are provided when content requires user input.

Why It's Important (User Benefit):

• Helps all users (including those with cognitive disabilities, screen reader users, and new users) understand what input is expected in each form field.
• Essential for users who cannot rely on visual cues (e.g., placeholder text which often disappears on input or focus).

What to Check / How to Implement:

• Explicit Labels: Every input field (text fields, checkboxes, radio buttons, dropdowns) must have a clearly associated `<label>` element.

  <label for="email">Email Address:</label>
  <input type="email" id="email">

• Programmatic Association: The `for` attribute of the `<label>` must match the `id` of the input field.
• Instructions/Examples: Provide clear instructions or examples for complex inputs (e.g., "Date format: DD-MM-YYYY," "Password must contain at least one uppercase letter and one number").
• Placeholder Text: Placeholder text (the text inside an input field that disappears when typing) should *not* be used as the sole label, as it is not consistently available to all users.

Common Mistakes to Avoid:

• Form fields without any `<label>` element.
• Using only placeholder text as a label.
• Labels that are visually present but not programmatically linked to the input (missing `for`/`id` match).

Useful Tools for Testing:

• Browser Extensions: Axe DevTools, Lighthouse, WAVE (excellent for identifying missing or incorrectly associated labels).
• Screen Reader: Navigate forms with a screen reader to confirm that each field's purpose is clearly announced via its label.
• Keyboard Test: Click on labels. If they are correctly associated, clicking the label should put focus on the corresponding input field.

Objective: If an input error is automatically detected and a suggestion for correction is known, then the suggestion is provided to the user, unless it would jeopardize the security or purpose of the content.

Why It's Important (User Benefit):

• Helps users (especially those with cognitive disabilities or dyslexia) correct errors more quickly and efficiently.
• Reduces frustration and increases the likelihood of successful task completion.

What to Check / How to Implement:

• Specific Suggestions: For common errors where a correction is obvious, provide a specific suggestion (e.g., "Did you mean example@domain.com?" for a misspelled email, or "Password requires at least one uppercase letter" if missing).
• Password Errors: For security reasons, do not suggest specific password corrections (e.g., do not echo back parts of the password or give hints like "Your password is too short, you need to add 'xyz'"). Instead, state the missing requirement (e.g., "Password must be at least 8 characters long," "Password must include a number").
• Autocorrection/Autocompletion: Implement autocorrection or autocompletion features where appropriate and beneficial, as long as the user maintains control.

Common Mistakes to Avoid:

• Just stating "Invalid input" without any hint on how to fix it.
• Providing suggestions that are too vague or unhelpful.

Useful Tools for Testing:

• Manual Test: Intentionally make common input errors (e.g., misspell an email, use an incorrect date format) and check if helpful suggestions are provided.

Objective: For Web pages that cause legal commitments or financial transactions for the user, or modify or delete user-controllable data in data storage systems, at least one of the following is true:

• Reversible: Submissions are reversible.
• Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
• Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.

Why It's Important (User Benefit):

• Prevents severe or irreversible consequences for users due to errors in critical transactions (e.g., financial, legal, data deletion).
• Builds trust and confidence in the system.
• Addresses potential issues for users with cognitive, motor, or visual disabilities who might be more prone to making errors.

What to Check / How to Implement:

• Review/Edit: Allow users to review and correct information before final submission.
• Confirmation: Require explicit confirmation of submission (e.g., "Are you sure you want to proceed?").
• Cancel: Offer the possibility to cancel the transaction or change.
• Automatic Validation: Use real-time validation where possible to prevent errors before submission.

Common Mistakes to Avoid:

• Irreversible transactions that offer no possibility of review or cancellation.

Useful Tools for Testing:

• Manual Test: Simulate important transactions and check for the presence and functionality of error prevention mechanisms.

Objective: In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, there are no duplicate IDs, and each ID is unique, except when the specifications allow it.

Why it's Important (User Benefit):

• Ensures that all browsers and assistive technologies can correctly parse and interpret the content.
• Prevents unpredictable behavior or display/functionality errors.

What to Check / How to Implement:

• HTML/XML Validity: Ensure that the HTML code is valid and well-formed, without syntax errors.
• Unique IDs: Each `id` attribute must be unique within the page.
• Correct Nesting: Elements must be nested correctly (e.g., `` must not contain another ``).

Common Mistakes to Avoid:

• Unclosed or incorrectly opened tags.
• Duplicate IDs on the same page.

Useful Tools for Testing:

• HTML Validators: W3C Markup Validation Service, browser extensions like Axe DevTools or Lighthouse (often detect parsing issues).