Diving Deeper into WCAG 1.3 Adaptable: Specific Success Criteria for Inclusive Content
Posted: Tue Jul 15, 2025 1:13 pm
Dear WCAG Plus Forum members,
In our previous discussion, we explored the foundational concept of WCAG Guideline 1.3 Adaptable – making content flexible enough to be presented in various ways without losing meaning or structure. Today, let's zoom in on several key Success Criteria under this guideline. These criteria provide concrete, measurable ways to ensure your content truly adapts to diverse user needs and technologies.
---
1. Success Criterion 1.3.2 Meaningful Sequence (Level A)
"When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined."
What it means: This criterion ensures that the order in which information is presented in the code (the Document Object Model, or DOM) makes logical sense. If you were to remove all CSS and just read the raw HTML, would the story still flow correctly? This is vital because screen readers and other assistive technologies navigate content based on its underlying code order, not its visual layout.
Why it's crucial: Imagine a conversation where sentences are randomly jumbled. Confusing, right? The same applies to content. If visual design moves elements around (e.g., using CSS Flexbox `order` properties or `float`s), but the HTML remains out of order, screen reader users will experience a disjointed, illogical sequence of information, making comprehension nearly impossible.
How to meet it:
---
2. Success Criterion 1.3.3 Sensory Characteristics (Level A)
"Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, color, size, visual location, orientation, or sound."
What it means: You cannot solely use visual or auditory cues to convey information or instructions. For example, telling a user "Click the green button" is insufficient if they cannot perceive color.
Why it's crucial: This criterion directly addresses barriers for users with various sensory impairments:
How to meet it:
---
3. Success Criterion 1.3.4 Orientation (Level AA)
"Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential."
What it means: Your website or app should work equally well whether a device is held in portrait or landscape mode. Users should be able to rotate their device without losing functionality or content.
Why it's crucial:
How to meet it:
---
4. Success Criterion 1.3.5 Identify Input Purpose (Level AA)
"The purpose of each input field collecting information about the user can be programmatically determined when: The input field serves a purpose identified in the Input Purposes for user interface components section; and The content is implemented using technologies with support for identifying the expected meaning for form input data."
What it means: For common user data input fields (like name, address, email, phone number), their specific purpose should be programmatically identifiable. This primarily uses the `autocomplete` attribute in HTML5.
Why it's crucial:
How to meet it:
---
5. Success Criterion 1.3.6 Identify Purpose (Level AAA)
"In content implemented using markup languages, the purpose of user interface components, icons, and regions can be programmatically determined."
What it means: This is an extension of 1.3.5, but for *all* user interface components, icons, and major regions of a page, not just input fields. Their purpose should be programmatically identifiable.
Why it's crucial: This provides a much richer semantic understanding of the page for assistive technologies and users who rely on them. It goes beyond mere labeling to communicate the *role* or *purpose* of elements, helping users navigate complex interfaces more efficiently.
How to meet it:
---
Building a Truly Adaptable Web
These Success Criteria under Guideline 1.3 are essential for creating a web that truly adapts to its users, rather than forcing users to adapt to rigid designs. By focusing on strong semantic markup, logical sequencing, and providing robust programmatic information, we enable assistive technologies to do their job effectively and empower all users to access and interact with content in the way that best suits them.
Implementing these criteria means less frustration for users and a more robust, future-proof product for you.
What challenges have you faced with these specific criteria? Do you have any clever solutions or examples to share? Let's discuss in the comments below!
In our previous discussion, we explored the foundational concept of WCAG Guideline 1.3 Adaptable – making content flexible enough to be presented in various ways without losing meaning or structure. Today, let's zoom in on several key Success Criteria under this guideline. These criteria provide concrete, measurable ways to ensure your content truly adapts to diverse user needs and technologies.
---
1. Success Criterion 1.3.2 Meaningful Sequence (Level A)
"When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined."
What it means: This criterion ensures that the order in which information is presented in the code (the Document Object Model, or DOM) makes logical sense. If you were to remove all CSS and just read the raw HTML, would the story still flow correctly? This is vital because screen readers and other assistive technologies navigate content based on its underlying code order, not its visual layout.
Why it's crucial: Imagine a conversation where sentences are randomly jumbled. Confusing, right? The same applies to content. If visual design moves elements around (e.g., using CSS Flexbox `order` properties or `float`s), but the HTML remains out of order, screen reader users will experience a disjointed, illogical sequence of information, making comprehension nearly impossible.
How to meet it:
- Design with DOM order in mind:[/b;] Plan your HTML structure so it naturally follows the intended reading order.
- Use semantic HTML: Headings, paragraphs, lists, and form elements should appear in the code in the same order they are meant to be read.
- Test with CSS disabled: A simple way to check is to temporarily disable CSS in your browser. If the content still reads logically, you're on the right track.
---
2. Success Criterion 1.3.3 Sensory Characteristics (Level A)
"Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, color, size, visual location, orientation, or sound."
What it means: You cannot solely use visual or auditory cues to convey information or instructions. For example, telling a user "Click the green button" is insufficient if they cannot perceive color.
Why it's crucial: This criterion directly addresses barriers for users with various sensory impairments:
- Users who are blind or have low vision cannot rely on visual shape, color, size, or location.
- Users who are deaf or hard of hearing cannot rely on sound.
- Users with cognitive disabilities might struggle to process abstract sensory cues.
How to meet it:
- Provide redundant cues: Always pair a sensory characteristic with a text label or another non-sensory indicator. Instead of "Click the red button," say "Click the 'Submit' button (red)."
- Use text labels: Buttons should have clear text labels, not just icons. If using icons, provide accessible names (e.g., using `aria-label`).
- Describe visual instructions: For diagrams or visual instructions, provide equivalent text descriptions.
- Note on color: While you can't rely *solely* on color, color can be used as an *additional* cue. For specific color contrast requirements, refer to Guideline 1.4.
---
3. Success Criterion 1.3.4 Orientation (Level AA)
"Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential."
What it means: Your website or app should work equally well whether a device is held in portrait or landscape mode. Users should be able to rotate their device without losing functionality or content.
Why it's crucial:
- Users with mobility impairments: Some users might have their device mounted in a fixed orientation on a wheelchair or stand, making it difficult or impossible to rotate.
- Comfort and Preference: Users should be able to choose the orientation that is most comfortable or convenient for them.
How to meet it:
- Implement responsive design: This is the primary way to achieve this. Ensure your CSS media queries handle both portrait and landscape layouts gracefully.
- Avoid hardcoding orientation locks: Unless genuinely essential for the functionality (e.g., a piano app that requires landscape for keys, a banking app for a check deposit, or AR/VR content where orientation is intrinsic to the experience), do not lock the screen orientation.
---
4. Success Criterion 1.3.5 Identify Input Purpose (Level AA)
"The purpose of each input field collecting information about the user can be programmatically determined when: The input field serves a purpose identified in the Input Purposes for user interface components section; and The content is implemented using technologies with support for identifying the expected meaning for form input data."
What it means: For common user data input fields (like name, address, email, phone number), their specific purpose should be programmatically identifiable. This primarily uses the `autocomplete` attribute in HTML5.
Why it's crucial:
- Users with cognitive disabilities: Explicitly identifying the purpose helps them understand what information is being asked for.
- Users with mobility impairments: Autocomplete functionality significantly reduces typing effort and errors, especially for those who rely on on-screen keyboards or switch devices.
- Browser functionality: Allows browsers to offer more accurate auto-fill suggestions, improving efficiency for all users.
How to meet it:
- Use `autocomplete` attribute: Apply the appropriate `autocomplete` token (e.g., `autocomplete="name"`, `autocomplete="email"`, `autocomplete="street-address"`) to your form input fields as defined in the HTML Living Standard.
---
5. Success Criterion 1.3.6 Identify Purpose (Level AAA)
"In content implemented using markup languages, the purpose of user interface components, icons, and regions can be programmatically determined."
What it means: This is an extension of 1.3.5, but for *all* user interface components, icons, and major regions of a page, not just input fields. Their purpose should be programmatically identifiable.
Why it's crucial: This provides a much richer semantic understanding of the page for assistive technologies and users who rely on them. It goes beyond mere labeling to communicate the *role* or *purpose* of elements, helping users navigate complex interfaces more efficiently.
How to meet it:
- Use ARIA roles and properties: Supplement native HTML semantics with appropriate ARIA roles (e.g., `role="navigation"`, `role="main"`, `role="search"`) and properties (e.g., `aria-label`, `aria-describedby`) where native HTML doesn't suffice.
- Leverage HTML5 semantic elements: Utilize elements like `<header>`, `<footer>`, `<nav>`, `<main>`, `<aside>`, `<section>`, `<article>` to define regions.
- Provide accessible names for icons and components: Ensure icons have text alternatives or accessible names that convey their purpose.
---
Building a Truly Adaptable Web
These Success Criteria under Guideline 1.3 are essential for creating a web that truly adapts to its users, rather than forcing users to adapt to rigid designs. By focusing on strong semantic markup, logical sequencing, and providing robust programmatic information, we enable assistive technologies to do their job effectively and empower all users to access and interact with content in the way that best suits them.
Implementing these criteria means less frustration for users and a more robust, future-proof product for you.
What challenges have you faced with these specific criteria? Do you have any clever solutions or examples to share? Let's discuss in the comments below!