Digital Accessibility Learning Path: Developers – Part 1

Accessibility resources for Web and App Development teams and individuals

Accessible Web Development: Part 1 – Identifiable

Table of Contents

Logical Content Structure

Include a descriptive page Title

  • Apply a descriptive, concise <title> for each unique page in a group of web pages. The page <title> is necessary to differentiate web pages. Titles are visible on each open web browser tab, and it is the first thing read by a screen reader when a page is opened.
  • Make sure the naming convention is consistent across all pages in a group of pages. The <title> may be similar to the text of the main heading (h1).
Example of <title> attribute on Northeastern University webpage Tabs

Ensure robust page structure

Page layout and programmatic structure has a large impact on usability and accessibility, and can facilitate understanding and navigation when used effectively. Structural markup is often viewed as the page outline, which can facilitate the identification of page content and sections. Consider the following best practices:

  • Use page headings, and be sure to apply them in a logical, nested, hierarchical order without skipping heading levels. Heading markup should always match the visual presentation, and can be used to identify the beginning of a content group. Use CSS to style headings as needed.
  • Use Page Regions or Landmarks to section content. Ensure descriptive labels are included.
  • The following image of page structure example includes:
    • <nav>
    • <main>
    • <h1>
    • <h2>
    • <h3>
    • <aside>
    • <footer>
Page structure example which includes landmarks and heading elements
Image provided by the Webaim WAVE®
accessibility tool

Logical Order of Content

  • Page content must be presented in a way that is logical and preserves meaning for all users. Keyboard focus and the reflow of content should align with the logical reading order, and be consistent with the visual order.
  • This is also true for alert messages and new content that appears on-screen, or populates page areas. Focus should move to new content or be placed on the next focusable item in the visual or logical Tab sequence when a user takes action; and/or all users should be informed when new content has appeared or pre-existing content has changed.

Easy to Read and Understand

Label form elements

  • All form controls must have descriptive, programmatic labels.
  • Groups of controls must be easily identifiable and use text that represents the group in addition to each form controls’ unique label (e.g.; use fieldset and legend elements to identify a group of radio controls).
  • The “title” should not be relied upon as a form control label for non-visual users.
  • Screen reader and Voice Control users must be able to associate a form’s input elements with its programmatic label (see the following code example). If the input elements aren’t labeled or described appropriately, the user may complete the wrong field or be unable to successfully submit the form.
  • Labels for interactive controls must be accurate (for and id attributes must match) and the programmatic language must be consistent with the visual presentation and all text based references and instructions.
  • Form elements may include:
    • <input>
    • <select>
    • <textarea>
    • <button>
    • <fieldset>
    • <legend>
    • <datalist>
    • <output>
    • <option>
    • <optgroup>

Example of a basic textfield input <label>

<label for="name">Name (first and last name):</label>

<input type="text" id="name" value="name" />

Example of grouped Checkboxes using <fieldset> and <legend>

  <legend>I am interested in the following (check all that apply):</legend>
    <input id="photo" name="interests" type="checkbox" value="ph">
    <label for="photo">Photography</label>
    <input checked="checked" id="watercol" name="interests" type="checkbox" value="wa">
    <label for="watercol">Watercolor</label>
    <input checked="checked" id="acrylic" name="interests" type="checkbox" value="ac">
    <label for="acrylic">Acrylic</label>

Ensure the site is readable with stylesheets disabled

  • If you disable CSS, the site must be readable, logical and meaningful. The site content should not be confusing or lose information.

Do not rely on Sensory Characteristics

  • Users who perceive color differently, experience various forms of color blindness, or have low vision or blindness, may not understand context, when color alone is used to convey information.
  • Ensure the use of color for text and background, meets or exceeds minimum contrast specifications in all states, including (mouse) hover, and on-focus (keyboard).
  • Avoid language that relies on specific sensory perception such as “Press the Red button on the Left to continue.” If color is used, also include another indicator such as an asterisk, and refer to it with instruction.
  • Use guidance for spacial orientation that is linear (e.g., “At the beginning of the page”), or refers to the programmatic title of a section, Landmark or content group (e.g., “following the Events section”).

Example of Color Alone being used to convey information.

Example of how the use of color may appear, for some people without color vision

Example using Color as well as a visual indicator to convey information that does not rely on color vision.

Use appropriate markup for Data Tables

  • Data tables are used to organize data with a logical relationship in grids. Accessible tables need HTML markup that indicates header cells and data cells and defines their relationships. Assistive technologies use this information to provide context to users.
  • Header cells must be marked up with <th>, and data cells with <td> to make tables accessible. For more complex tables, explicit associations may be needed using scopeid, and headers attributes.
  • Do not use tables for layout purposes alone.
Example of a Data Table with 4 Column Headers 2 Row Headers and data cells
<table class="table-design table-a11y" role="table">
  <caption>Table Caption</caption>
    <tr role="row">
      <th id="columnheader1" role="columnheader" scope="col">Column Header 1</th>
      <th id="columnheader2" role="columnheader" scope="col">Column Header 2</th>
      <th id="columnheader3" role="columnheader" scope="col">Column Header 3</th>
      <th id="columnheader4" role="columnheader" scope="col">Column Header 4</th>
    <tr role="row">
      <th id="item1" role="rowheader" scope="row" headers="columnheader1"><span class="col-header" aria-hidden="true">Column Header 1</span>Row 1 - Cell 1</th>
      <td role="cell" headers="item1 columnheader2"><span class="col-header" aria-hidden="true">Column Header 2</span>Row 1 - Cell 2</td>
      <td role="cell" headers="item1 columnheader3"><span class="col-header" aria-hidden="true">Column Header 3</span>Row 1 - Cell 3</td>
      <td role="cell" headers="item1 columnheader4"><span class="col-header" aria-hidden="true">Column Header 4</span>Row 1 - Cell 4</td>
    <tr role="row">
      <th id="item2" role="rowheader" scope="row" headers="columnheader1"><span class="col-header" aria-hidden="true">Column Header 1</span>Row 2 - Cell 1</th>
      <td role="cell" headers="item2 columnheader2"><span class="col-header" aria-hidden="true">Column Header 2</span>Row 2 - Cell 2</td>
      <td role="cell" headers="item2 columnheader3"><span class="col-header" aria-hidden="true">Column Header 3</span>Row 2 - Cell 3</td>
      <td role="cell" headers="item2 columnheader4"><span class="col-header" aria-hidden="true">Column Header 4</span>Row 2 - Cell 4</td>

Use descriptive text or labels and identify all Interactive content

  • The purpose of a link and all other interactive content must be easy to understand for all users. Although adjacent content and visual indications can be helpful for sighted users, a text based description must be available for non-visual users and users of various Assistive Technologies to identify each component and its purpose.
  • Descriptive and identifying labels can be implemented using plain text that is programmatically available to all users, or by presenting text that is “hidden” visually, which is often used for components that are visually identifiable using icons or other visual information.
    If hidden text is preferred:
    • CSS can be used to place text off-screen (see the following code example)
    • ARIA can be applied to an element (e.g. aria-label or aria-labelledby) to provide a non-visual label.
  • The role of each interactive component should be easy to understand programmatically, without relying on visual presentation. For instance, a button that triggers an action, should be identified as such, and the same is true for a select menu or a hyperlink (for example).
    This is particularly important when custom elements are being used and cannot be understood by assistive technology. ARIA roles can often be used successfully; however, it must be considered that there are behaviors for Patterns that must also be honored, and implemented for custom components to match their native counterpart and meet the expectations of users. E.g., a tablist must behave as expected for a keyboard user in order to be identifiable as such (role=tablist). Keyboard interaction and focus management is important for the Tabs Pattern and should be considered for all interactive components. To put it simply, you shouldn’t call it a dog if it looks like a dog, but behaves like a chicken.

sr-only class example:

<a>Read more<span class="sr-only"> about kittens</span></a>

hidden text class example:

.sr-only {
    clip: rect(1px, 1px, 1px, 1px);
    clip-path: inset(50%);
    height: 1px;
    width: 1px;
    margin: -1px;
    overflow: hidden;
    padding: 0;
    position: absolute;

Identify Document Links

  • It is useful for all users when linked document format types are identifiable. Include the document format in the link text, e.g.; “4th Quarter Report (PDF)”.
  • If icons are used, ensure a programmatic descriptive label is applied appropriately. When the format is also conveyed in plain text, the icon can be programmatically hidden to avoid redundancy.
Document icon examples


Related Resources: Part 1 – Identifiable

Logical Content Structure

Easy to Read and Understand

Additional Resources

Accessibility Guidance for Developers

The General Services Administration (GSA) provides accessibility guidance for developers. Multiple resources can be found on the 18F Accessibility Guide Homepage, including the Accessibility Checklist which helps identify important behaviors and component presentations integral to an accessible web experience.

Developing for Web Accessibility (W3C)

Web Content Accessibility Guidelines (WCAG)

Northeastern policy identifies WCAG 2.0 as the Minimum Web Accessibility Standards (MWAS) for which development should strive to conform. The World Wide Web Consortium (W3C): The creators of WCAG, offer a How to Meet WCAG (Quick Reference) guide providing insight into understanding the guidelines as well as techniques and code based examples.

Accessible Rich Internet Application (ARIA)

In addition to WCAG techniques W3C provides additional semantic specifications for creating accessible web experiences found on the ARIA Authoring Best Practices Guide (APG). The guide provides pattern examples for specific components, including:

Your Feedback is Welcome

We would love to hear your thoughts on this learning content. Please let us know if you have completed any of the modules, have any feedback or just want to say hello. Email us at