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.

Texas Gas Service Homepage

Another accessibility disaster. It’s great that people are finding creative ways to use JavaScript but it is not okay to ignore progressive enhancement techniques.

Your users should never see this instead of content:

Our site requires javascript, please enable javascript and refresh the browser window.

JS frameworks do a disservice to the Web after all the innovation and hard work that has gone into creating a separation model for content, presentation and client-side scripting.

drawing of a peanut M&M candy showing content as the peanut, presentation as the chocolate layer and client-side scripting as the candy shell
Layering content, presentation and client-side scripting – Drawing by Dave Stewart

The Texas Gas Service website gives us lots of examples. Let’s see how well we can use the site without a mouse, a.k.a tabbing through.

(Step 0: What is with this trend to play videos as background images? I thought we learned this lesson years ago. Having movement your users can’t disable is annoying and bad practice. Stop it.)

screenshot of the Texas Gas Service home page with user login form
Texas Gas Service homepage

  1. Links I can’t click; let me count the ways
    From the “I want to…” select menu to the hamburger menu to the footer, dozens of “links” are not marked up as <a href> and cannot be tabbed to, nor would they be read as links by a screen reader.

    screen shot of the expanded I want to... menu
    These aren’t links

    This is lazy and wrong. If something is a link, make it a link. Fake links achieved with JS only are a large accessibility barrier.

    <div click.delegate="goTo('home', true)" class="btn pill-btn white-fill-btn au-target" show.bind="!session.loggedIn" au-target-id="111">Pay my bill</div>

  2. Tabbing order fail
    The tabindex attribute can be a really useful tool. It can also completely screw up a user’s ability to access important information, like the “username” field. When I could not tab to the “username” field, I looked at the code and saw the field was set to tabindex=-1. I had to look this one up. Here’s a 2014 explanation from The Paciello Group:

    When tabindex is set to a negative integer like -1, it becomes programmatically focusable but it isn’t included in the tab order. In other words, it can’t be reached by someone using the tab key to navigate through content, but it can be focused on with scripting.

    From my perspective as a customer who visits this page, being able to log in is the number one user story but it isn’t possible using a keyboard.

  3. Form validation errors
    The only time the “username” field seems to get focus is if that field is empty when clicking the “Login” button. Plenty of client-side field validation solutions work without removing a field from the tabbing order.

    screen shot of the login form with validation errors for the empty username and password fields
    Login form validation errors with login button disabled

    If a user tries to login with bad data, a small modal window with a an unhelpful developer-style error message of “Login failed” appears at the top right of the page. There is no associated help text about the causes of the error, or which fields have errors, and focus is removed from the form making it that much harder to update the data.

    screenshot of the error message login failed in a modal window
    Login failed error modal window

    Adding to the confusion is the little green check in both fields indicating what would usually mean the field data is valid. But for this form, a green check merely indicates that a field isn’t blank. There isn’t any robust client-side validation occurring at all.

Pet peeve: What is the point of removing the browser scrollbar from the page? It provides a simple and useful way to indicate where I am on the page. This is something I really miss on mobile devices.

Bad Forms – WHY?

Forms.

So easy to get right, yet so often poorly constructed.

screen shot of a form fields with light gray text on white

Today I came across this gem with a contrast ratio of 1.26:1, as in barely above 1:1 which is invisible. Gray on white should always have contrast checked.

Other form infractions include

  • Using placeholder text as labels. Once a user starts typing, it’s no longer clear what information was requested or what format the data should be in.
  • When tabbing through the form, there is no visual indicator when you’re on a select field or a button.
  • I just don’t see the point in trying to reinvent the form experience. In this case, they’ve chosen a skeuomorph design, attempting to recreate a paper form experience digitally.
  • I like the address suggestion but it’s not possible to tab to it and select anything.

    screen shot of the address field with a drop down of address suggestions
  • I could not tab through the t-shirt size options and select anything using the arrow keys, even though these were coded as radio buttons.
    screen shot of the t-shirt form field with circles for each sizeUsing the browser inspector, I unhid the radio buttons and then could tell that after I made a selection, I was tabbing through the radio buttons.
    screen shot of selected radio button for shirt size
  • It was really hard to tell if I could tab to the submit button without visual indication. Adding a button focus style with the inspector showed that it was getting focus.

So much has been written about the IA of good forms, the proper markup of form elements and form usability, it’s amazing to me designers don’t follow a known pattern for an account creation process. It’s not the time to get fancy.