The web is inherently accessible

Originally posted 7 February 2021. Updated 13 April 2022.

It all started when I built the Accessible Web tool which removes CSS and JS from a webpage, leaving plain HTML. I built it as a sarcastic response to a developer who changed his website to require visitors to disable JavaScript before they could view the content. The reactions to this gatekeeping on Twitter were hilarious! So many angry developers didn’t get the joke that they put up similar barriers when they require that people have JavaScript enabled to view anything on their websites.

I created an About page for the project that requires the user to disable CSS to view a message about web accessibility and the importance of semantic markup. The following is a blog article version of that webpage with code examples.

Accessible Web - please disable CSS to view this website

The web is inherently accessible

Your weekly reminder that the web is accessible by default and it’s our design decisions that stop it being accessible #a11y

k.mar (@Kevmarmol_CT) on Twitter December 7, 2020

Why did you have to disable CSS to view this webpage? No reason other than a design choice that excludes sighted people.

Did you know? This is how many visitors “view” webpages already:

  • Search engines
  • Bots
  • Site crawlers
  • Analytics
  • Blind people

This webpage is fully accessible to people with screen readers and Braille displays. But many websites are not due to poor design choices that exclude some people.

What is web accessibility?

When a page is accessible, it was developed with the intention of working for as many people with disabilities as possible. A good place to start learning is the W3C’s Introduction to Web Accessibility. Find out the different ways people with disabilities interact with the web.

Web Content Accessibility Guidelines (WCAG)

WCAG is a set of success criteria for determining if a page is accessible, led by four guiding principles:

  • Perceivable: Information and user interface components must be presentable to users in ways they can perceive.
  • Operable: User interface components and navigation must be operable.
  • Understandable: Information and the operation of the user interface must be understandable.
  • Robust: Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies.

These contain guidelines and a hierarchy of success criteria from Level A to Level AAA. Many accessibility laws, and current best practice, point to WCAG 2.1 Level AA compliance. There are 50 discrete success criteria to evaluate, though many are not applicable to all pages. For example, if a page doesn’t contain video, you don’t have to evaluate against success criteria for captions or audio descriptions.

See the full list of success criteria

Did you know? The WCAG guidelines were first published in 1999. Web accessibility is not a new concept but a lot of people are learning about it only now.

Semantics

So what’s the point? The point is to develop accessible pages from the bottom up, starting with semantic HTML. A whole lot of developers think they know HTML but are actually pretty sloppy about it. Many don’t think it matters if they use a link or a button, but it does. Every semantic mistake introduces accessibility issues into your code. If you’ve never really “learned” HTML, check out this beginner’s guide to writing good HTML.

By far, CSS color contrast issues are the most frequent accessibility issues I encounter, but the HTML ones are problematic too. Outlined below are the top HTML-related accessibility issues I encounter.

Headings

If you visually scan this page, you can quickly see how it is broken up into sections. That’s due to using headings or the h1-h6 elements. It’s important that every page have at least one h1 so people and search engines know what the topic of the page is. From there, cascade down to h2, h3, and so on.

Did you know? People using screen readers can navigate by headings in much the same way that sighted people can visually scan the page for items of importance.

Buttons and links

Buttons and links may seem similar but they have very different semantic uses. If you use them interchangeably, people can get confused about what a button or link is going to do when activated.

Buttons

Buttons are used for controlling actions on the page, such as a form submit button or toggle button.

It’s preferable to use a native button element instead of creating a custom one:

  • It already has the button role
  • It’s keyboard focusable
  • It’s activated with ENTER and SPACE keys

The button element can have various states depending on its purpose:

Collapsed

<button aria-expanded="false">Menu</button>

Expanded

<button aria-expanded="true">Search</button>

Not pressed

<button aria-pressed="false">Light mode</button>

Pressed

<button aria-pressed="true">Dark mode</button>

Links

Links are used for navigation, literally for linking to another page or place on the same page. When you use a link, people expect to go somewhere new when it’s activated.

It’s important that the link text properly convey the link purpose. Avoid generic text like “click here”.

Same page link

<a href="#headings">Headings</a>

New page link

<a href="/site-map/">Site map</a>

External link

<a href="https://eff.org">EFF</a>

Email link

<a href="mailto:info@eff.org">info@eff.org</a>

Images

The one thing about accessibility most people know is that images need alt text. This may seem straightforward but let’s look at three examples.

1) Alt text

Semantically speaking, every image needs an alt="" attribute. This alone will pass an automated accessibility checker. If an image is purely decorative, you can even leave the alt value empty. But if an image provides context to the content, the alt text must accurately describe the content of the image for people who cannot see it.

<img src="cats.jpg" alt="two cats on an easy chair under a blanket">
two cats on an easy chair under a blanket

2) SVG

Inline SVG doesn’t support the alt attribute. Instead, add role="img" to the svg element to identify it as an image. Give it an accessible name using the aria-label attribute on the svg.

<svg role="img" aria-label="Bar chart showing the years 2016 to 2021 as the percentage of US consumers with a streaming video service increased from 52% to 78%." xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 650 400">...</svg>
US Consumers 52% 64% 69% 74% 78% 78% 2016 2017 2018 2019 2020 2021 0 20% 40% 60% 80% 100%

Go to the Tables section for information on providing access to all data points in the graph.

3) Icons

Any time you display icons that convey meaning to the user, you must provide a text equivalent for users of assistive technology. For example, it’s common to insert an external link icon after link text that opens in a new tab or window.

Icon fonts are not announced reliably by assistive technology. First, hide the icon using the aria-hidden attribute. Then provide a text equivalent with visually-hidden text.

Exposed icon

☎ 1-800-799-SAFE

<a href="tel:1-800-799-7233">☎ 1-800-799-SAFE</a>

Hidden icon

Call 1-800-799-SAFE

<p><a href="tel:1-800-799-7233"><span class="visually-hidden">Call</span><span aria-hidden="true">☎</span> 1-800-799-SAFE</a></p>

Tables

There are many legitimate uses for tables on the web but they are often coded incorrectly. Table data cells need corresponding table headers. This allows the applicable table header to be read by a screen reader before the table data cell contents. Additionally, tables need captions to provide a description of the table to people using screen readers.

In the SVG example under Images, we looked at a svg bar chart where we provided a snapshot of the data using aria-label. We need to provide all the data in a format that assistive technology can navigate and an easy way to do that is to provide all data points in a table.

US consumers with a streaming video subscription
Year US Consumers
2016 52%
2017 64%
2018 69%
2019 74%
2020 78%
2021 78%
<table>
  <caption>US consumers with a streaming video subscription</caption>
  <thead>
    <tr>
      <th>Year</th>
      <th>US Consumers</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>2016</td>
      <td>52%</td>
    </tr>
    <tr>
      <td>2017</td>
      <td>64%</td>
    </tr>
    <tr>
      <td>2018</td>
      <td>69%</td>
    </tr>
    <tr>
      <td>2019</td>
      <td>74%</td>
    </tr>
    <tr>
      <td>2020</td>
      <td>78%</td>
    </tr>
    <tr>
      <td>2021</td>
      <td>78%</td>
    </tr>
  </tbody>
</table>

Forms

Every input needs a label. It’s really that simple. The label needs to be visible and persistent (avoid using placeholder). This helps people remember what information they’ve entered. Programmatically link each pair matching the for attribute on the label with the id attribute on the input.

This enables a couple things:

  • People can now click or tap on the label to give focus to the input. This is especially useful for checkboxes and radio buttons that often have small hit areas.
  • People using screen readers will now hear the label announced when the input is in focus.

When you have a group of related form fields, like checkboxes or radio buttons, group them with a fieldset element and provide an accessible name for the group with a legend element.

<fieldset>
  <legend>Cat's Colors</legend>
  <p><label for="black"><input type="checkbox" id="black"> Black</label></p>
  <p><label for="white"><input type="checkbox" id="white"> White</label></p>
  <p><label for="brown-tabby"><input type="checkbox" id="brown-tabby"> Brown tabby</label></p>
  <p><label for="orange-tabby"><input type="checkbox" id="orange-tabby"> Orange tabby</label></p>
  <p><label for="torbie"><input type="checkbox" id="torbie"> Torbie</label></p>
  <p><label for="gray"><input type="checkbox" id="gray"> Gray</label></p>
</fieldset>

Many modern browsers do cursory form field validation with the required attribute though error messages are not always accessible. Let assistive technology users know when a field is required by adding the aria-required="true" attribute to inputs.

<label for="email">Email<span aria-hidden="true"> *</span></label>
<input type="email" id="email" autocomplete="email" name="email" aria-required="true">

For a deeper dive into forms, check out my blog article and talk Structuring accessible forms.

In summary

  • Web accessibility is an ongoing process
  • Use semantic markup: Native HTML + ARIA
  • Headings help people navigate
  • Buttons and links do different things
  • Images need text equivalents
  • Use tables for data
  • Structure forms in accessible ways

Structuring accessible forms

On 28 September 2021, I was a guest on Ben Myer’s Twitch stream where we demonstrated best practices for structuring accessible forms. Following is the example code and an explanation of what we covered.

See the Pen Accessible Forms by Rachele (@racheleditullio) on CodePen.

Creating our form fields

The two basic parts of a form field are its <label> and <input> elements. We semantically link the two by

  • Using the <label for="uniqueID"> attribute which matches the <input id="uniqueID"> attribute; or
  • Making the <input> element a child of the <label> element

Doing so allows screens readers to announce the field’s <label> when the <input> gets focus. It also enables the <label> as an additional hit area when using the mouse to focus on an <input>, which is especially useful for checkboxes and radio buttons.

We also need to specify the type of input using the <input type=""> attribute. Putting those together, we have a basic form with one text field and two radio buttons.

<form>
  <label for="name">Cat's name</label>
  <input type="text" id="name" name="name">

  <label><input type="radio" id="yes"> Yes</label>
  <label><input type="radio" id="no"> No</label>

  <button type="submit">Send</button>
</form>

A note on combo boxes

As much as possible, use native HTML <select> and <option> elements to create an expandable list of single-select options.

...
<label for="markings">Cat's markings</label>
<select name="markings" id="markings">
  <option value=""> select an option </option>
  <option value="solid">Solid</option>
  <option value="bi">Bi-color</option>
  ...
</select>
...

Grouping similar fields

Our radio buttons are labeled ‘yes’ and ‘no,’ but what are they for? We need to use the <fieldset> and <legend> elements to provide that semantic meaning. The <fieldset> groups the related form fields while the <legend> provides a name for the grouping. These are most often used for checkboxes and radio buttons but they can be useful for grouping other related fields, e.g. Shipping address.

Since radio button options may have similar names, group like radio buttons with the name="groupName" attribute. Keyboard users move between radio buttons in a group with the arrow keys.

...
<fieldset>
  <legend>Is your cat altered?</legend>
    <label><input type="radio" name="altered" id="yes"> Yes</label>
    <label><input type="radio" name="altered" id="no"> No</label>
</fieldset>
...

Marking required fields

Let’s create a required field for collecting email address with <input type="email">. Provide a visible indication of the required field for sighted users, such as an asterisk, but hide it from assistive technology using the aria-hidden="true" attribute.

Then there are two attributes we can use to programmatically define required fields: aria-required="true" and required.

Use one (not both) of these attributes to ensure required fields are conveyed appropriately to assistive technology. Screen readers will say required when announcing the form field name, role and state.

...
<label for="email">Your email<span aria-hidden="true">*</span></label>
<input type="email" id="email" name="email" aria-required="true">
...

The required attribute provides a first layer of form validation on submit. Many modern browsers will not submit a form with empty required fields and will even provide a visible error message.

a requried field in a web form that is empty and displays the message please fill out this form field.
Required field in Firefox for Windows

However, user agent error handling is not dependable as these error messages are not always announced or available to assistive technology; they can’t be styled or resized; and they are not persistent.

Handling errors

It’s important to provide a list of all errors at the top of the form or provide them in-context of the field in error. We can programmatically link the error message with the form field using the aria-describedby attribute.

...
<input type="email" id="email" name="email" aria-required="true" aria-describedby="error-email">
<p id="error-email">Email format email@domain.com</p>
...

When assistive technology users focus on the email field, the error message is announced along with the name, role and state of the field.

Verifying data

In addition to marking fields as required for assistive technology, we also have to indicate if the data entered into each field is valid. All required fields should also include the aria-invalid="true" attribute. Update this to “false” when it passes validation.

It’s also an accessibility requirement to make entering valid data as easy as possible. HTML has a set of autocomplete values that we need to use for any fields collecting personal information that might already be stored in the user’s browser. Email is one of these fields.

...
<input type="email" id="email" name="email" aria-required="true" aria-describedby="error-email" aria-invalid="true" autocomplete="email">
...

We can further enforce data validation in HTML for fields that aren’t necessarily required by using the pattern attribute that accepts a regular expression. Let’s create a field for collecting birthday with a required format of mm/dd/yyyy.

...
<input type="text" id="birthday" name="birthday" aria-describedby="help1" pattern="^\s*(1[012]|0?[1-9])\/(3[01]|[12][0-9]|0?[1-9])\/((?:19|20)\d{2})\s*$">
<p id="help1">Birthday format mm/dd/yyyy</p>
...

This pattern matching prevents the form from submitting if the data entered does not match the specified pattern.

Conclusion

I hope you found something to make your forms more accessible. I like forms because they have such a strong semantic structure. There are a lot of things to get right but it’s pretty straightforward what “right” means in this context: Make sure anything that is conveyed visually is also conveyed to assistive technology, including the states of form fields.

How accessible is the 2020 US census?

Like most US households, I received my 2020 census form in the mail this past week and I decided to see how accessible the process really is since it’s a US government website subject to Section 508 compliance.

envelope for the 2020 US census form

The first thing to note is that someone with low vision or who is blind might have trouble with this whole process because the paper form that arrived in the mail does not have particularly large print nor does it include even cursory instructions in Braille. For deaf or hard of hearing people, there is a TDD number but only if you speak English. I think it’s safe to say that many people with disabilities will have to rely on someone else’s help to complete the process.

Let’s take a look at the website that the paper form directs you to visit: my2020census.gov.

screen shot of the Census 2020 homepage

I found a few oddities with the home page while using a screen reader:

  • The very first text a screen reader user encounters is a technology warning: If you are using a screen reader, it is recommended that you use the latest version of Internet Explorer and the JAWs [J-A-W-S] screen reader. I’m testing with Chrome and NVDA and this website should work with all major browser/screen reader combinations.
  • The first focusable element is a “skip to main content” link which works fine for a keyboard user but announces blank when using a screen reader because focus is moved to a <div> element with a role=button but no label.
<div role="button" tabindex="0">
<img src="/static/images/start-here.png" class="img-responsive" alt="Start Here Shape your future">
<button type="button" title="Start Questionnaire" name="Start Questionnaire">Start Questionnaire</button>
<div id="recaptcha-container"></div>
  • And as we can see from the screen shot below, the reading order does not match the focus order. The “skip to main content” link sends focus to after all the important instructional information.
screen shot of the census 2020 home page with the focus on the right side of the page
  • Lastly, neither the home page nor the questionnaire pages have <h1> headings or unique page titles to adequately convey place in site.

Start the questionnaire

At the top of the questionnaire pages is a status bar similar to what you might see during a checkout process for online shopping.

screen shot of the census 2020 status bar starting with address verification, household questions, people questions, then final questions.

There are two problems here:

  1. There isn’t any screen-reader accessible help text explaining that it’s a status bar, like a heading, nor any text to indicate which step the user is currently on so it’s useless for someone using a screen reader.
  2. This is the login in screen but the “Address Verification” step is highlighted in the status bar.

The login form itself has very good screen reader label text for the three form fields.

screen shot of the census ID form fields and login button.
  • Enter the first 4 digits of your Census ID
  • Enter the next 4 digits of your Census ID
  • Enter the last 4 digits of your Census ID

But it’s kind of ironic because someone who can’t see the paper letter with their census ID won’t be able to type it in anyway unless someone reads it off to them.

Address verification section

Once you get past the login screen, the status bar at the top properly indicates to a screen reader user where they are the process: progress bar You are on section 1, the address verification section. But, they are unlikely to benefit from this because every time you click the “Next” button, focus is moved to the question text, not the top of the page.

screen shot of a census question with focus indicator on the question text.

Each question has a “Help” link next to it that opens a modal dialog window which is properly coded by:

  • Moving focus to the modal window heading <h1>
  • Keeping focus in the modal window
  • Providing close buttons to exit the modal window
screen shot of a modal window with focus on the help heading and includes an x button and a close button.

If you click the “Next” button without completing the required fields, you get an alert and the required fields are outlined in a thick, red border.

<div role="alert">Your name is required to continue the 2020 Census questionnaire. If you prefer not to provide your name, please provide a nickname or unique description.</div>
screen shot of an alert message above required form fields that are blank.

The three “Telephone Number” fields are required but leaving them blank triggers a separate alert message after filling out the name fields. All required fields should be clearly indicated both visually and to a screen reader user.

Household questions

When the “Household” section loaded, the screen reader was silent so there’s something going on with managing focus on this section. It’s hard to troubleshoot because the application is not designed to let you go back to previous questions or sections.

Instead of a “Help” link for the first question, there was this link text: For more information on who to include, click here. What the screen reader announced, though, was: Help link popcount question. A look at the code shows there are both a title attribute and an aria-label attribute on the link with this nonsensical name.

<a href="#" title="Help link popcount question" aria-label="Help link popcount question">For more information on who to include, click here.</a>

People questions

Just as with the “Household questions” section, when the questionnaire moved to the “People questions” section, the screen reader was silent and I could see focus remained on the “Next” button that was removed from the DOM.

screen shot of the census dashboard with focus indicator on invisible button.

These are not marked up as headings.

This section asks information about each of the persons entered in the “Household questions” section, including birthday.

screenshot of a form asking for birthdate as month, day, year and then verify calculated age.

After selecting the month, day and year, the next input displays a calculated age but the help text after the label does not get read by a screen reader in forms mode because it is not programmatically associated with it using aria-describedby or located inside the <label>.

<label for="P_AGE_INT">Verify or enter correct age as of April 1, 2020.</label>
<span>For babies less than 1 year old, do not enter the age in months. Enter 0 as the age.</span>

The site does a nice job with its session expiration warning both visually and by sending an alert to screen reader users.

screen shot of a session expiration warning with 17 seconds remaining.

Submit questionnaire

This screen also has a focus management issue. The screen reader doesn’t announce anything when the final screen loads and you can see in the screen shot below how focus remains on the “Next” button that was removed from the DOM.

screen shot of the last screen in the questionnaire with focus left on an element removed from the DOM.

And the same thing happens after clicking the “Submit Questionnaire” button and you’re shown the confirmation page. This site needs more testing with a screen reader and better focus management.