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:

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.

5 ways to improve table accessibility

I recently came across this example of an HTML table that was marked up correctly, for the most part, but lacked some of the important coding nuances needed to make a table truly accessible. Below is a screen shot of that table with the areas of concern highlighted.

screenshot of an HTML table with 4 columns, a header row, and 6 data rows. Areas of the table are highlighted with the numbers 1 through 5.

Depending on the complexity of your table, it can be helpful to review the Table Concepts tutorial from the W3C Web Accessibility Initiative (WAI).

Here are five things to check when creating your next table.

1) Caption that table

While this table has what looks like a caption of “Choose a plan”, that text was actually marked up as a heading level <h3>. Moving it inside the <table> element and marking it up as a <caption> instead allows assistive technologies (AT), like a screen reader, to announce the text as being programmatically associated with the <table>.

Table with 7 rows and 4 columns, caption, choose a plan

NVDA screen reader

2) Include header text for every column

In this example, the very first table cell is empty. The screen reader announces: row 1 column 1. That’s it. But what about the contents of the rest of the cells in this column? They need a header to explain what they are. Visually, the content author doesn’t want a header for column one, but AT users benefit when the name of the column is announced before the contents of subsequent cells.

To fix this issue, I added a hidden column header for column one of “plan feature.”

<th><span class="visually-hidden">Plan feature</span></th>

Now, when a screen reader gets to the beginning of a new row, it’s clear what content is contained in the first cell of each row.

Row 3, plan feature, column 1, number of users

NVDA screen reader

3) Use alt attributes meaningfully

The content author decided to use green check mark images to indicate when a plan feature is included in a particular plan, but they didn’t include alt attributes. AT users have no way of knowing when a feature is included because the cells with images don’t communicate anything.

To fix this, make sure you include alt text on images that provides meaning to the user. An alt attribute of “check mark” would not be meaningful even though it’s visually correct. Instead, I used “feature included.” (Though I would argue using an icon font would be better than an image.)

<td><img src="icon-checkmark-green.svg" alt="feature included"></td>

Team plan, column 3, [graphic] feature included

NVDA screen reader

4) Have data in every table cell

When a feature is not included, we must also communicate that to AT users. The last row of the table has three empty cells which indicate to sighted users that a feature is not included, but like 2) above, we need to add some hidden helper text.

<td><span class="visually-hidden">not included</span></td>

Personal plan, column 2, not included

NVDA screen reader

5) Check your (con)text

Screen readers don’t always handle abbreviations and punctuation as expected. I found two interesting examples with this table. First, the number of users for the Team plan visually looks like “2-50” but it gets announced as “250” because the hyphen is ignored. To accurately convey this meaning, we can add the word “to” as visually-hidden helper text, and we can hide the hyphen from AT to be safe.

<td>2<span aria-hidden="true">-</span><span class="visually-hidden">to</span>50</td>

Team plan, column 3, two to fifty

NVDA screen reader

Second, the plan feature “2FA” in row six does not get announced properly. My screen reader announces this as “2-fah”, not “2-F-A”. Again we need to add helper text for AT users.

<td><span aria-hidden="true">2FA</span><span class="visually-hidden">2 factor authentication</span></th>

Row 6, plan feature, column 1, 2 factor authentication

NVDA screen reader

Please check out the full HTML for this <table> in my first Codepen entry.

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

Creating useful alternative text for your images

Providing alternative text (alt text) for images is necessary to pass success criterion 1.1.1: Non-text content. On many of the websites I evaluate, it’s very common for alt text to be incomplete, incorrectly applied or missing entirely. When performing accessibility testing, I find it helpful to use a tool like this image bookmarklet to highlight all the images on the page and display their alt attributes.

screen shot of two images with alt attributes displayed by a bookmarklet tool.
Two webpage images highlighted using a bookmarklet tool for alt attributes

The key to writing good alt text is to consider the purpose of the image when trying to decide how to describe its meaning. Let’s look at five types of webpage images:

  1. Informative
  2. Actionable
  3. Decorative
  4. Redundant
  5. Complex

Informative images

These are images intended to convey pertinent information to the user. Most images in the main content of a webpage, like a photo supporting a news story, are informative images.

  • Informative images must have programmatically-discernible alt text that is accessible to people using assistive technologies (AT) like screen readers and braille displays.
  • Alt text must be meaningful and accurately convey the purpose and intent for those who can’t see it.
  • Alt text shouldn’t include words that identify the element as a graphic or image because screen readers announce that automatically.
  • Alt text should be concise. (We will look at complex images that require long descriptions separately.)

Let’s look at an example. Below is a screen shot of a table with two columns. Each table row lists a feature in the first column and has an icon of a check mark in the second column. The content author gave the check mark icon alt text of “check mark”.

screenshot of the header row and 2nd row of a table. the first column is labeled what's included and the 2nd column has a checkmark icon.
Alt text provided: check mark
<img class="block--center" src="icon-check.svg" alt="check mark.">

But what is the actual meaning of the symbol of a check mark in this context? It’s there to indicate visually which features are included. Better alt text would be the word “yes” because that conveys through text what the icon conveys symbolically. A screen reader would announce:

Row two column one What’s included
Product research and development
Row two column two Included

Tip: End your alt text with a period (full stop). This prevents it from being announced by a screen reader like a run-on sentence with text that follows.

Actionable images

Any time an image is used as a link, button or control, it must provide alt text that conveys its purpose in that context so that AT users understand what will happen if they follow the link or activate the control. Let’s look at the following carousel banner image:

screenshot of an image with lots of embedded text.
Alt text provided: Forrester names OpenText a leader in ECM Content Platforms. Read the report.
<a href="/info/forrester-wave">
<img src="forrester-wave.jpg" alt="Forrester names OpenText a leader in ECM Content Platforms. Read the report.">

When an image is used as a link, its alt text must explain the purpose of the link or control.

Tip: Avoid embedding text in images when it’s possible to display the content using real text.

Decorative images

When an image serves a purely visual function, it doesn’t need to convey anything to AT users. All inline images must include the alt attribute on the <img> element but it can be empty when the context is decorative. If the alt attribute is missing, though, a screen reader will often try to announce the file name instead of moving past it to the next block of text.

screen shot of a block of text and link with a decorative image above it.
<img src="circuit-board.jpg" alt="">

Redundant images

Sometimes, an image is redundant because its context is conveyed by adjacent text. Like decorative images, it’s okay to have a null value for the image’s alt attribute if it doesn’t need to convey additional meaning to AT users. In the image below, a circle icon with the word “Process” is visible to the left of a heading reading “Digital Process Automation.”

screen shot with an icon that repeats the adjacent heading text
<img src="icon-process.svg" alt="">
<h2>Digital Process Automation</h2>

The icon is redundant to the heading text and serves a mostly decorative purpose. It doesn’t convey additional meaning.

Complex images

When an image is complex in nature, like a chart or diagram, alt text should should describe the image briefly. Provide a complete explanation in an associated long description. Some content authors use a supporting element like <figcaption> with an aria-describedby attribute to programmatically link the <figcaption> to <img>.

Diagram of the OpenText intelligent and connected enterprise.
Alt text provided: Diagram of the OpenText intelligent and connected enterprise.
<img aria-describedby="long-desc" alt="diagram of the OpenText intellgent and connected enterprise." src="opentext-intelligent-and-connected-enterprise-graphic.jpg">
<figcaption id="long-desc">The OpenText EIM Suite and OpenText Cloud combine to support EIM applications and EIM platforms with an intelligent information core of automation, AI, APIs and data management.</figcaption>

The long description should be visible for sighted users as well as they might benefit from the robust explanation, particularly when it comes to lengthy charts and graphs.


Alt text is both simple and complicated at the same time but a little forethought into the purpose of your images in each context goes a long way towards making them meaningful for AT users who won’t perceive them visually.