3 Ways to Start Incorporating Accessibility

Traditionally, many think accessibility only benefits those with disabilities and helps people using mobile devices or those who experience slow network connections. In other words, by incorporating accessibility, you are expanding your user base and potential customers. The equity and equality of a website also become apparent; just like it is wrong to bar access to building for folks with disabilities, it would also be wrong to block access to your website.

A note before we continue, assistive technology will mostly be referred to by AT throughout this post.

1) Add Text Alternatives & programmatically determined names

• Text alternatives or alternative text are text-based substitutes for non-text content on the web. Non-text content can include images, multimedia, data visualizations, and other visual or auditory presentation of information.
• Programmatically determined names are the accessible names available to the browser and accessible technologies. Browsers use an algorithm called the Accessible Name and Description Computation to determine these names. It's the information used by assistive technologies(AT) to identify the HTML element.
  • The accessible name for an element can be derived from the element's content, an attribute, or an associated element.
  • ie. When a Screen Reader reads through the DOM and comes to an interactive element, it will announce the element and its name.
  • i.e., Using speech recognition, a user can target an element by the accessible name.

Benefits

Adding text alternatives to non-text content serves several functions:

• AT will present the text-based substitution to its user, helping those with visual or certain cognitive disabilities be able to perceive the content and function of the non-text content.
• If an image file becomes corrupt, broken, fails to load, or the user has blocked images from loading, the browser will provide the user with the text alternative.
• Good Text alternatives provide good SEO, and search engines will use text alternatives' content in their page assessment and rating.

Applying descriptive and concise accessible names provides access:

• Providing role, state, and value information on all user interface components enables compatibility with AT, such as screen readers, screen magnifiers, and speech recognition software used by people with disabilities.

Text Alternative and Accessible Names in action

Different ways to apply text alternatives

ARIA

• aria-describedby MDN reference
  • This attribute lists the ids of the elements that describe the object.
  • Can be used with images, form controls, widgets, groups of elements, regions with headings, definitions, and more
  • When AT reads associated aria-describedby text, all semantics are removed

<img src="EllenTerry-ladymacbeth.jpg" alt="Lady Macbeth" aria-describedby="heading p1">
<h2 id="heading">Ellen Terry as Lady Macbeth</h2>
<p id= "p1">Lady Macbeth, standing, draped in a blue and green dress, raising a crown above her head. This painting dates back to 1889 and is oil on canvas. John Singer Sargent is the painter of the portrait of famous actress Dame Ellen Terry in her role of Lady Macbeth</p>

For your inspection:

Ellen Terry as Lady Macbeth

Lady Macbeth, standing, draped in a blue and green dress, raising a crown above her head. This painting dates back to 1889 and is oil on canvas. John Singer Sargent is the painter of the portrait of famous actress Dame Ellen Terry in her role of Lady Macbeth

HTML/ Inherent Attributes and Elements

• alt="descriptive text here" MDN reference
  • Defines an alternative text description of the image.
  • Setting the alt attribute to an empty string indicates that this image is a decorative element and is not essential to the content.
    • You can also set an image to be decorative if there is enough information from the contextual text to provide the description.
    • i.e. a profile picture followed immediately by the name of the person (this example is not always applicable in social media use cases.)
• SVG: <title /> MDN reference
  • The SVG accessible name element
  • Provides an accessible, short-text description of any SVG container element or graphics element

    <!-- Using the alt text to describe the information present in the image -->
    <img src= "EllenTerry-ladymacbeth.jpg" alt= "Lady Macbeth standing, draped in a blue and green dress raising a crown above her head"/>

    <!-- Decorative Images -->
    <img src="decorativeBG.jpg" alt=""/>

For your inspection:

Different ways to apply accessible names

ARIA

• aria-labelledby MDN reference

  • Enables developers to reference other elements on the page to define an accessible name
  • With aria-labelledby an element or elements that label the control are applied to it
  • When AT reads associated aria-labelledby text, semantics are removed
  • ARIA labels override the content and accessible names for HTML elements

• aria-label="descriptive text here" MDN reference

  • Defines a string value that labels an interactive element
  • When the default accessible name is missing or does not accurately describe the content/functionality, and aria-labelledby isn't used to reference other content that could give it meaning, apply aria-label
  • ARIA labels override the default text and accessible names for HTML elements

<!--aria-labelledby-->
<section>
    <input type="checkbox"  aria-labelledby="TermsConditions" />
    <p id="TermsAndConditions">I agree to the Terms and Conditions.</p>
</section>

<!--aria-label-->
  <button aria-label="Close Dialogue" onclick="close()">
    <img src="close.svg" alt="" />
  </button>

HTML

• Associating the <label> element explicitly MDN reference

  • Best practice for accessible form elements is to use the label element to associate text with form elements explicitly.
  • Utilizing the for attribute that takes in a single id for the form-related element
    • When using libraries like React, you'll use htmlFor to programmatically set the for attribute React Ref

    <label for="firstname">First name:</label>
    <input type="text" name="firstname" id="firstname">

• Associating the <label> element implicitly MDN reference
  • In some cases, form controls cannot be labeled explicitly
    • i.e. a form field is generated by a script, there may and/or may not be an id, and the developer may not have knowledge of the id and its contents
  • To implicitly label a form control, you use the <label/> as a wrapper

    <label>
      First name:
      <input type="text" name="firstname" >
    </label>

• Labeling buttons MDN reference
  • The label and name for a button are set inside the element.
    • Button content/labeling can include markup
    • If creating a button using the <input/> tag, the label is set with the value attribute

  <button type="submit">Submit</button>
  <button type="button">Cancel</button>

  <input type="submit" value="Submit">
  <input type="button" value="Cancel">

Learning Resources

Alt Text

• WCAG References
  • WCAG: Understanding SC 1.1 Text Alternatives Guideline
  • WCAG SC1.1.1 Non-text Content (Level A)
• WebAIM - techniques - alt text
• W3C Image Tutorials

Accessible Names

• WCAG References
  • WCAG SC 4.1.2: Name, Role, Value (Level A)
  • WCAG SC 1.3.1: Info and Relationships (Level A)
• WebAIM - Decoding Label and Name for Accessibility
• W3C Labeling Controls
• WebAIM - Links and Hypertext

2) Use Semantic HTML

What does it mean to write Semantic HTML?

Using Semantic HTML5 to write the markup of the document content provides meaning and structure. This meaningful structure makes it easier for the browser and AT to digest the content and make it perceivable to the users.

A few Basics on Semantic HTML

There are over 100 HTML elements; a couple don't offer any semantic value but often need to be used more in defining a page structure.

• <div />
• <span />

Using elements that don't offer semantic value have their place, but contribute very little when defining the hierarchy of the page. Defining a hierarchy is helpful for users of AT for perception, operation, and understanding. Many users of AT use this hierarchy to navigate through a page.

<!-- Using div and span by themselves offer 
a poor user experience for AT users -->

<div>
  <span>LOGO</span>
  <div>
    <a>home</a><a>about</a><a>contact</a>
  </div>
</div>
<div>
  <span>Some Important Words</span>
  <div>
    <span>content</span>
    <span>content</span>
    <span>content</span>
    <span>content</span>
  </div>
  <div>
    <span>content</span>
    <span>content</span>
    <span>content</span>
    <span>content</span>
  </div>
</div>
<div>
  <span>copyright</span>
</div>

While the visual presentation can give a little perspective to the code above, it only does a little for how an AT can interpret and provide context. The only elements with semantic value are the anchor(<a/>) tags, which let the AT know that those elements are links and the user knows that they'll be navigated somewhere by interacting with them. But if we refactor the code above with accessibility in mind, we'll see something of much greater value to AT users.

<!-- 
Using semantics provides a better user experience for AT users.
 -->
<header>
  <span>LOGO</span> 
<!-- 
I prefer not to have the Logo be the h1 element as it is a redundant item and doesn't reflect page content. 
-->
  <nav>
    <ul>
      <li><a>home</a></li>
      <li><a>about</a></li>
      <li><a>contact</a></li>
    </ul>
  </nav>
</header>
<main>
  <h1>Some Important Words Defining the Page Content</h1> 
<!-- 
I prefer having my h1 reflect the content of the page,
the content of the h1 should also be similar to the unique content of 
the page title element 
-->
  <section>
    <h2>Some Important Words defining the Section Content</h2>
    <h3>subheader content</h3>
    <p>content</p>
  </section>
  <section>
    <h2>Some Important Words defining the Section Content</h2>
    <h3>subheader content</h3>
    <p>content</p>
    <article>
      <header>
        <h4>Some Important Words defining the Article Content</h4>
      </header>
      <!--
        If the `<header>` element is used inside `<article>`and `<section>` elements are not associated 
with those elements.
        It does not get the WAI-ARIA banner role 
and needs certain behavior in assistive technologies.
      -->
      <p>content</p>
      <h4>subheader content</h4>
      <p>content</p>
    </article>
  </div>
</section>
<footer>
  <p>copyright</p>
</footer>

By using semantics in the code example above, the hierarchy is defined using the heading(h) tags, and the structure of the page is determined using the landmark tags <header />,<main />,<footer />, and <nav />. The landmarks' structures are defined by the grouping or region tags <section /> and <article />. We can now understand the architecture because we provide meaning and structure using these semantic HTML5 elements.

Headings and Hierarchy

tags, ranging from 1 to 6. They represent the six levels of section headings.

• <h1> is the highest ranking in the hierarchy.
  • It is the most important of the levels
  • Best practice: there should only be one <h1> per page.
  • Its content should describe the page content at the highest level
  • The heading tags after are nested in order
• <h6> is the lowest in the hierarchy

Do

<h1>Heading 1</h1>
<h2>Heading 2</h2>
<h3>Heading 3</h3>

Don't

<h1>Heading 1</h1>
<h4>Heading 4</h4>
<h6>Heading 6</h6>

Nesting

In the list below, we can see an example of how to use the heading(h) tags for defining hierarchy within the page.

• h1 Main Topic
  • h2 h2.1 supporting main topic
  • h2 h2.2 supporting main topic
  • h2 h2.3 supporting main topic
    • h3 h3.1 supporting h2.3 > main
    • h3 h3.2 supporting h2.3 > main
    • h3 h3.3 supporting h2.3 > main
  • h2 h2.4 supporting main topic
    • h3 h3.4 supporting h2.4 > main
      • h4 h4.1 supporting h3.4 > h2.4 > main
    • h3 h3.5 supporting h2.4 > main
      • h4 h4.2 supporting h3.5 > h2.4 > main
      • h4 h4.3 supporting h3.5 > h2.4 > main
    • h3 h3.5 supporting h2.4 > main
    • h3 h3.7 supporting h2.4 > main

Semantics Elements for Structure

<header />

• The top-level <header> is considered a landmark role, and the implicit ARIA banner role
• It has different semantics depending on where it is nested
  • When a <header> is nested in <main>, <article>, or <section>, it just identifies it as the header for that section and isn't a landmark.

<nav>

• Ids content as navigation
• If nested in the top level <header>, the <nav> is considered the main navigation
• If it were nested in an <article> or <section>, it would be internal navigation for that section only
• Considered a landmark

<main>

• Ids the main content of the document
• There is only one
• Considered a landmark

<section>

• Nested in the <main>
• Sections should have a heading, with very few exceptions
• Encompasses generic standalone sections of a document
  • When there is no more specific semantic element to use
• Articles can be nested within Sections
• Implicit role of region

<article>

• Nested in the <main>
• Represents a complete or self-contained module of content
  • Independently reusable
• Implicit role of article

<aside>

• For content that is indirectly or tangentially related to the document's main content
• The <aside> is also a landmark, with the implicit role of complementary

<footer>

• The main <footer> is considered a landmark role and the implicit ARIA contentinfo role
• It has no specific role if it is nested and is not a landmark if not the main <footer>, the accessibility tree would call it a FooterAsNonLAndMark

Full List of Semantic elements in HTML:

• <article>
• <aside>
• <details>
• <figcaption>
• <figure>
• <footer>
• <header>
• <main>
• <mark>
• <nav>
• <section>
• <summary>
• <time>

Check them out on MDN

The Role Attribute

When building out your sites or apps, it is best practice to use Semantic HTML elements before using ARIA roles. The role attribute describes an element's role in the document's context. The role attribute is global, so every element accepts this attribute. The role is used primarily by AT, but can be used to cast elements into different roles(this is not recommended). There are six categories of ARIA roles:

• Document structure roles
• Widget roles
• Landmark roles
• Live region roles
• Window roles
• Abstract roles

For more on ARIA Roles checkout the W3C documentation on the Role Models

Learning Resources

• W3C Page Structure Tutorial
• WebAIM - Semantic Structure: Regions, Headings, and Lists
• web.dev - Semantic HTML
• web.dev - ARIA and HTML
• web.dev - Introduction to ARIA
• MDN WAI-ARIA Basics
• WebAIM - Introduction to ARIA - Accessible Rich Internet Applications

3) Make your Website/App Responsive

Responsive design is good practice for multi-device experiences but can also yield good accessibility results. Some WCAG success criteria can be met by keeping responsive design in mind.

• 1.4.4 Resize text
  • Introduced in WCAG 2.0
  • The page is readable and functional when the page is zoomed to 200%.
• 1.4.10 Reflow
  • Introduced in WCAG 2.1
  • No loss of content or functionality occurs, and horizontal scrolling is avoided when content is presented at a width of 320 pixels.
    • This requires responsive design for most websites.
    • This is best tested by setting the browser window to 1280 pixels wide and then zooming the page content to 400%.
• 1.4.12 Text Spacing
  • Introduced in WCAG 2.1
  • No loss of content or functionality occurs when the user adapts paragraph spacing to 2 times the font size, text line height/spacing to 1.5 times the font size, word spacing to .16 times the font size, and letter spacing to .12 times the font size.

Tips for Responsive Design

• Use the viewport meta tag
  • match the screen's width in device-independent pixels by setting content=" width=device-width
  • Establish a 1:1 relationship between CSS pixels and device-independent pixels by setting initial-scale=1.0
  • Instructs the browser to fit your content to the screen size

<meta name="viewport" content="width=device-width, initial-scale=1.0" />

• Don't disable zooming

  • avoid these settings:maximum-scale=1 or user-scaleable=no

• Use relative units for text

  • This will enable the whole site to reflow as the user zooms, creating the reading experience they need to use your site.
  • em
    • This unit of measure adjusts relative to the parent element
  • rem
    • This unit of measure adjusts relative to the root element

• Keep DOM order and Visual order connected

  • Don't use CSS to reorder the HTML elements. It can confuse tab order as well as folks that use screen readers in combination with the visual presentation.
  • Use CSS Grid and Flex-box appropriately
    • Utilize the flexible nature of these layout methods.

Learning Resources

• Codecademy - Cheatsheets/Responsive Design and Accessibility
• web.dev - Responsive web design basics
• Make your website more accessible with these Responsive Design tips
• web.dev - Accessible responsive design
• BIA - Responsive Design and Accessibility

Those are just three easy ways to start incorporating accessibility into your developing practice.

Give this post a reaction if you found it helpful, and follow me on Twitter and Dev.to to keep up with new posts!