Introduction to Web Accessibility

2021-08-21 · 8 min read

What is Accessibility?

In general

Accessibility can be viewed as the "ability to access" and benefit from some system or entity. The concept focuses on enabling access for people with disabilities, or enabling access through the use of assistive technology; however, research and development in accessibility brings benefits to everyone.

Accessibility - Wikipedia

Let's narrow down to Web Accessibility

Web accessibility is the inclusive practice of ensuring there are no barriers that prevent interaction with, or access to, websites on the World Wide Web by people with physical disabilities, situational disabilities, and socio-economic restrictions on bandwidth and speed.

Web accessibility - Wikipedia

How disabilities surf the Web?

For social justice
- To make the use of technology less challenging for those with disabilities.
For business
- To encourage more people to use our services/products.

For example, although we tend to center our discussion of accessibility on users with physical impairments, we can all relate to the experience of using an interface that is not accessible to us for other reasons. Have you ever had a problem using a desktop site on a mobile phone, or seen the message "This content is not available in your area", or been unable to find a familiar menu on a tablet? Those are all accessibility issues.

Accessibility | Web Fundamentals | Google Developers

An example from Google Web Developer Guides

Before

a form with poor accessibility

The text is low contrast, which is hard for low-vision users to read.

Having labels on the left and fields on the right makes it hard for many people to associate them, and almost impossible for someone who needs to zoom in to use the page; imagine looking at this on a phone and having to pan around to figure out what goes with what.

The "Remember details?" label isn't associated with the checkbox, so you have to tap or click only on the tiny square rather than just clicking the label; also, someone using a screen reader would have trouble figuring out the association.

After

Now let's wave our accessibility wand and see the form with those issues fixed. We're going to make the text darker, modify the design so that the labels are close to the things they're labeling, and fix the label to be associated with the checkbox so you can toggle it by clicking the label as well.

a form with improved accessibility

As a web developer, what can I do?

Four principles

According to Web Content Accessibility Guidelines (WCAG) 2.0, there are four principles (often called by the acronym POUR):

Perceivable: Can users perceive the content? This helps us keep in mind that just because something is perceivable with one sense, such as sight, that doesn't mean that all users can perceive it.

Operable: Can users use UI components and navigate the content? For example, something that requires a hover interaction cannot be operated by someone who can't use a mouse or touch screen.

Understandable: Can users understand the content? Can users understand the interface and is it consistent enough to avoid confusion?

Robust: Can the content be consumed by a wide variety of user agents (browsers)? Does it work with assistive technology?

Accessibility | Web Fundamentals | Google Developers

Approaches

Semantic HTML
ARIA

Semantic HTML

Using meaningful tags to describe your content.

Div Soup vs Semantic HTML source

Using these HTML tag to wrap our content instead of <div>:

<header>
- Header of our website
- It is usually used to wrap website title, logo and man navigation.
<nav>
- Navigation of our website
- <nav> often accompanies list tag (i.e. <ul> and <ol>)
<main>
- Main content
<aside>
- Commercial ads and sidebar can be put inside <aside>.
<article>
- In most cases, an <article> contains one article.
<section>
- At least one heading in <section>, or it will be untitled section.
- When we want to wrap more descriptions, then <section> can be a good alternative of <div>.
<footer>
- It is usually used to wrap contact info, links, copyright notice...etc.

In addistion to make our pages more accessible, semantic tags can improve search engine optimization (SEO) as well.

ARIA

The Web Accessibility Initiative's Accessible Rich Internet Applications specification (WAI-ARIA, or just ARIA) is good for bridging areas with accessibility issues that can't be managed with native HTML. It works by allowing you to specify attributes that modify the way an element is translated into the accessibility tree.

Introduction to ARIA | Web Fundamentals | Google Developers

An example from Google Web Developer Guides

<li tabindex="0" class="checkbox" checked>
  Receive promotional offers
</li>

<li tabindex="0" class="checkbox" role="checkbox" checked aria-checked="true">
  Receive promotional offers
</li>

Real-world case

Now, let's take a look at a real-world case.

At this part, I am gonna addressing some accessibility issues of my personal website.

The analysis tool I used: Lighthouse

Lighthouse is an open-source, automated tool for improving the quality of web pages. You can run it against any web page, public or requiring authentication. It has audits for performance, accessibility, progressive web apps, SEO and more.

Lighthouse | Tools for Web Developers | Google Developers

First analysis

1st Lighthouse analysis

Addressing Lighthouse's issues

Contrast

Lighthouse raised a contrast issue

This issue is raised because of the low-contrast text on my header navigation, and we can solve it easily by changing the text color (or background color of the header).

before
after

Internationalization and localization

Lighthouse raised a localization issue

If a page doesn't specify a lang attribute, a screen reader assumes that the page is in the default language that the user chose when setting up the screen reader. If the page isn't actually in the default language, then the screen reader might not announce the page's text correctly.

This issue is also simple, we just need to put lan attribute on <html> tag.

<html lang="en" />

Tables and lists

Lighthouse raised a tables and lists issue

This issue is raised because I wraped button links in <ul> without list item <li>, and we can fix it by adding <li> or removing <ul>. In this situation, I choose removing <ul> because it is redundant tag.

before

<Toolbar disableGutters>
  <List>
    {tabLinks &&
      tabLinks.map((link) => (
        <NavLink
          button
          $active={isTabActive(link)}
          key={link.title}
          href={link.url}
        >
          {link.title}
        </NavLink>
      ))}
  </List>
</Toolbar>

after

<Toolbar disableGutters>
  {tabLinks &&
    tabLinks.map((link) => (
      <NavLink
        button
        $active={isTabActive(link)}
        key={link.title}
        href={link.url}
      >
        {link.title}
      </NavLink>
    ))}
</Toolbar>

Second analysis

After addressing Lighthouse's issues, I used the tool again:

2nd Lighthouse analysis (after fixing Lighthouse's issues

As you can see, the score is better than that of the first time, and which probably means my website is more accessible.

After reading and handling these stuffs, I believe that we have a preliminary understanding of Web Accessibility. However, all of these cannot make our products or services fully accessible, so we need to keep it in mind, consider more about the usage scenarios, and practice more when we are developing applications.

If you are interested in getting know more about Web Accessibility, you can check Google's Udacity course on Accessibility.