Understanding WCAG SC 1.3.1 Info and Relationships
Version and Level: 2.0/2.1/2.2 (Level A)

WCAG SC 1.3.1 requires that information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. This ensures that content is accessible to all users, including those using assistive technology such as screen readers,text-to-speech, or custom style sheets extensions.

Some of the website content we create may be visibly perceived by most sighted users. However, users with disabilities such as blindness perceive the same content differently through various modalities and presentations.

Let’s quickly understand the page structure to see how we might fail to adjust it for all presentation modes: The page is mostly built by three languages:
HTML, CSS, and JavaScript.
HTML is responsible for the structure and tags of the document, such as headings and titles represented by specific tags like <h1>. CSS is responsible for implementing design onto the HTML since HTML itself lacks design.

For instance, to increase the size of our heading <h1>, we use CSS. Many website authors and developers may misuse HTML markup and override it with CSS, making the visible presentation of elements logical for sighted users. However, users with disabilities, relying on assistive technologies like screen readers, interact only with the HTML tags and structure, not with the CSS.

When the HTML tag differs from its end result due to CSS modifications, screen readers interpret only the HTML written on the document. Consequently, blind and sighted users may perceive the same content differently.

For example, if the <h1> tag represents a heading in HTML, some website authors may use a different tag like <p> but style it with CSS to resemble a heading. Sighted users perceive it as a title, while blind users’ screen readers interpret it as a paragraph.

As website authors, we must exert all necessary effort to ensure that the content is universally perceived in the same way across all modes and presentations.

Benefits:

  1. Improved Accessibility: Ensures that users with visual impairments or cognitive disabilities can understand and navigate the content.
  2. Consistent User Experience: Helps create a consistent and predictable user experience across different devices and assistive technologies.

Main Objective:

To separate visual presentation from the underlying information, structure, and relationships, ensuring they are programmatically accessible and preserved when the presentation format changes.

Best Practices:

  • Emphasis: Use <em> and <strong> for emphasis instead of just styling text with CSS.

  • Headings: Use only one <h1> on your page, and use a logical hierarchy of headings to structure content.

  • Tables: Tables: Use HTML table markup with appropriate headers. Avoid nested tables when possible. Use proper table markup ( <table>, <thead>, <tbody>, <th>, <td>) and include row and column headers.

  • Layout Tables: Don't use special table parts that form relationship between data like table headers, if your table is just for organizing layout. This helps screen readers understand that there's no data inside the table cells.

    Forms: Ensure all form elements have programmatically associated labels. Group related form controls using <fieldset> and <legend>, or ARIA roles for custom controls.

    Lists: Use <ol> or <ul> as the direct parent element of your list items, <li>.

    Semantic Markup: Prioritize native HTML semantic elements and use ARIA roles sparingly.

    Labels and Form Controls Linkage: Ensure labels and form controls are correctly linked by using the “for” attribute on the <label>, and associate it with the “id” of the form control to clarify the relationship between them to assistive technologies.

Examples & Explanation:

Example 1: Use of form elements

What Should Be Avoided

HTML/CSS

              <div>
                <p>User Information</p>
              
                <label for="username">User Name:</label>
                <input type="text" id="username" name="username">
              
                <label for="email">Email:</label>
                <input type="email" id="email" name="email">
              </div>

Explanation:The incorrect implementation uses <div> instead of <fieldset> for grouping related elements, lacks the <legend> element as a group caption, and directly associates labels with input fields without using the <label> element.

What Should Be Done

HTML/CSS

              <form>
                <fieldset>
                  <legend>User Information</legend>
                  <label for="username">User Name:</label>
                  <input type="text" id="username" name="username">
                  <label for="email">Email:</label>
                  <input type="email" id="email" name="email">
                </fieldset>
              </form>

Explanation:The correct implementation uses <fieldset> for grouping related elements, <legend> as the group caption, and <label> for associating labels with input fields. This ensures semantic structure and accessibility, improving user experience and facilitating form navigation.

Example 2: Use of table elements

What Should Be Avoided

HTML/CSS

              <table>
                <tr>
                  <td>Contact Information</td>
                </tr>
                <tr>
                  <td>John</td>
                  <td>Doe</td>
                  <td>john.doe@example.com</td>
                </tr>
              </table>

Explanation:Lack of semantic structure: In this example, the table is missing the <thead> element, which is typically used to define column headers. Instead, it simply has a row with "Contact Information", which is not semantically marked as a header.

What Should Be Done

HTML/CSS

              <table>
                <thead>
                  <tr>
                    <th>First Name</th>
                    <th>Last Name</th>
                    <th>Email</th>
                  </tr>
                </thead>
                <tbody>
                  <tr>
                    <td>John</td>
                    <td>Doe</td>
                    <td>john.doe@example.com</td>
                  </tr>
                </tbody>
              </table>

Explanation:In the correct implementation, the table includes <thead> to define column headers, providing a clear structure to the data. Each row is appropriately marked up with <tr>, and data cells are indicated with <td>. This improves accessibility and ensures the table is correctly interpreted by assistive technologies.

Example 3: Styling with CSS

What Should Be Avoided

HTML/CSS

              <div style="font-size: 24px; font-weight: bold;">Chapter 1: Introduction to Algebra</div>
              <p>This chapter covers the basics of algebra...</p>

Explanation:In the incorrect example, the heading is utilized by an incorrect element <div> and styled with CSS to visibly resemble a heading. Users who have cognitive disabilities tend to use browser extensions to disable the CSS of a page. If this were to happen in the above scenario, the heading would appear as plain text. Consequently, the same content that is easily perceived by most users may not be interpreted similarly by users who utilize such extensions or by assistive technologies.

What Should Be Done

HTML/CSS

              <h1 style="font-size: 24px; font-weight: bold;">Chapter 1: Introduction to Algebra</h1>
              <p>This chapter covers the basics of algebra...</p>

Explanation: In the correct implementation, the heading is marked up using the <h1> element, ensuring semantic correctness. While CSS is still used for styling, the structural integrity of the heading is preserved even if CSS is disabled. This approach ensures that users, including those with cognitive disabilities or who utilize browser extensions to disable CSS, can properly interpret the content, as the heading maintains its significance and structure regardless of styling.

Next Up

Expand your understanding with SC 1.3.2 - Meaningful Sequence. Learn to ensure your content is logical and accessible for all users.

Go to SC 1.3.2