Evaluating healthcare.gov for WCAG 2.1 Level-AAA & Section 508 accessibility compliance

A 2-hour design challenge in search of specific defects like focus management, keyboard accessibility, and color contrast

My task

Create a list of accessibility improvements for the provider search tool that is part of the Healthcare.gov ‘Window Shopping tool’

These should include (but are not limited to) improvements to:

  • Visual to the UI (CSS, visual elements)
  • Technical changes: HTML, JS, ARIA attributes, other
  • Content

Window Shopping provider search tool

The provider search tool enables users to search for Medical providers (such as doctors), Medical facilities, and prescription drugs to add to their temporary window shopping search for insurance plans. Once added, consumers can then quickly determine which plans cover their doctors, medical facilities, or prescription drugs.

Steps to be taken

  1. Go to the ‘See plans’ page of healthcare.gov
  2. Enter ZIP code 60647
  3. For “Who’s in your household, enter “just you”
  4. For “Tell us about you”, enter an age and sex, leaving the other items unchecked
  5. Choose “continue” on “Confirm your household members”
  6. Enter an income amount
  7. Choose “Continue” on the “Estimated savings overview” page
  8. Choose “Continue to Plans” on the “Review your information” page
  9. Choose “Close” on the “Help comparing plans” pop-up modal.
  10. Click ”See if providers & drugs are covered”. Enter a prescription drug (Ibuprofen, for example) or the name of a doctor (Smith, for example), then view results.

A few notes about the evaluation

  • I used only Chrome’s Developer Tools (the `Elements` tab, specifically) during my evaluation
  • In addition to the ‘Plans’ page, I reviewed each step preceding it — while staying within the 2-hour time limit
  • Given the 2-hour time limit, my evaluation focused mainly on testing WCAG 2.1 criteria related to keyboard navigation
  • I consciously triggered a session time-out by leaving my desk for over 30 minutes. Doing this allowed me to re-tread the initial steps and come to new revelations regarding accessibility
  • My observations and recommendations for each of the three sections below are grouped respective of the corresponding steps

Visual to the UI (CSS, visual elements)

Landing page modal

  • Nice touch: ‘Enter email address’ is auto-focused
  • Minor oddity with tab order: goes from email UP to select a state. Either switch the order or auto-focus ‘select a state’ dropdown

See plans & prices

  • Good: skip to main content link

Who’s in your household?

  • Cursor disappears when tabbing from ‘Household’ step menu item to ‘Skip’ button.
  • Bad: Regular keyboard actions offer no visual feedback when interacting with radio buttons
  • Bad: Lack of visual indicators makes it seem that when landing on this page, nothing is focused. However, pressing Spacebar reveals that one of the two radio buttons is focused.

I recommend updating all button-styled radio buttons to account for the various states in a compliant manner: active, focused, hovered, selected, unselected, etc.

Tell us about you

  • Default browser blue outline is nearly impossible to see when placed over the branded blue background of the form. I recommend styling focused/active form elements some other way (different color or a more prominent indicator than a thin outline)
  • Usability issue: placement of ‘I’ info icons so far from the checkbox and label creates an unhelpful disassociation. Recommend placing directly after label.

Confirm your household members

  • ‘Edit’ button focus state makes it appear too similar to its background color…thus nearly hiding it. The default state (white background) is great, though. Recommend identifying a different way to indicate focus. Additionally, this ‘Edit’ button style is different from all others, it seems. Others have a default state of blue background and focused state of lighter blue background with right and left borders. For consistency and compliance, all ‘Edit’ buttons should match.

Household income

  • Observation: checkmark appears next to ‘Household’ step menu item. However, the size, positioning and color of this checkmark make it difficult to see and relate to its menu item. Recommend exploring other visual designs for marking a step complete. Also, why does ‘Zip code’ not have a checkmark, too?
  • On page load, focus did not appear to be on the single input field. It did not have the usual blue outline and cursor.
  • Nice to see the real-time formatting of the entered dollar amount as it is typed

Estimated savings overview

  • Observation: Callout about eligibility for coverage was confusing at first. It said `Person 1 0`. Turns out, this was because I left `age` as `0` (when testing form validation). Changing age to any other number corrected this message to say `Person 1 (age X)`.

Review your information

  • Observation: ‘Edit’ buttons appear to be styled differently. Their default, unfocused state makes them appear disabled. When focused, they ‘light up’ nicely with left- and right-border styles and a lighter shade of blue for a background. Recommend changing default state to avoid anyone thinking the button is disabled.

(At last!) The Plans page

The `Help comparing plans` modal

  • In second panel, ‘Fast facts’, the dollar signs ($$$$) don’t offer enough color contrast to discern 1, 2 or 3 of 4 $ highlighted

The main page

  • Cursor is lost for two tab presses between ‘Espanol’ and ‘Refine results’: it seems that the ‘Plan Type’ and ‘Sort By’ dropdown menus have no focus styles
  • Cursor is lost for a whopping 17 presses of the tab key between ‘Refine results’ and the ‘I’ info icon in the first ‘Deductible’ box.
  • Cursor incorrectly moves back to that same info icon after tab key is pressed when focused in the ‘See if providers & drugs are covered’ blue-outlined box within the ‘Medical providers & prescription drugs covered’ box

See if providers are covered

  • Upon entering ‘Ibuprofen’, the list of possible matches appeared: 1. It is intimidating as there are so many options. 2. Two matches appeared identical: items 4 and 5 — Ibuprofein/pseudoephedrine
  • After selecting ‘See plans’, the page loads to show plans, however, there is no visual artifact telling me why I see these plans. By that I mean, it requires me to remember that I selected those two drugs…
  • …I see now that the only way to ‘edit’ what I just set is using the outlined ‘Edit’ button in the far-right grey box within each plan.

I recommend exploring more clear ways for a person to edit drugs or doctors after initially selecting them.

Plan detail view

  • Print preview displays a what appears to be an unstyled page. I recommend adding a print stylesheet to appropriately and consciously match website styles, to an extent.
  • The copy-able Link input and button that appear after pressing ‘Link’, while styled well, seem oddly placed on the page. It’s possible that a bit of padding will make it feel better positioned.
  • It’s a bit disorienting to be taken ‘Back’ to the Detail view, when…I clicked ‘Like this plan’ from the main list view. I expected to be taken back to the main list view, instead.

Comparison view

  • It’s difficult to compare two things when their shared attributes don’t line up horizontally.
  • Also, given how much information there is to compare, it would be nice if the plan name remained in the viewport at all times when scrolling

Technical changes: HTML, CSS, Javascript, ARIA attributes

Landing page modal

  • Great: Successful keyboard trap in modal

See plans & prices

  • Bad: skip to main content link does not appear to work — triggering it added `/#/skipnav` to the URL, but did not re-position the cursor
  • Observation: this is an Angular app (identified by the ng-app attributes on `<body>`)
  • Great: Navigation via keyboard is noticeably intuitive

Who’s in your household?

Same as above: I recommend updating all button-styled radio buttons to account for the various states in a compliant manner: active, focused, hovered, selected, unselected, etc.

Tell us about you

  • Bad: `<label>` form elements are missing the necessary `for` relational attribute that correctly associates each `<label>` with its corresponding `<input>`
  • Odd that the `<h2>Tell us about you</h2>` has a `tabindex` of `0`. Headings are not usually tab-focusable.

Observations related to form validation on this page

  • Odd: Entered ‘0’ for age, was hoping that was invalid entry…it appears to be accepted
  • Returned to page to enter a string…successfully met with error message. However, the styling of the error message (white text on red background…on blue background) is troublesome to look at.
  • Also tried entering long string of numbers…met successfully with another error message about 125 age cap

Household income

  • Good: the `Expected 2019 income` label has a `for` attribute correctly linking it with the `input` field
  • Good: `Estimate your income` modal has a proper keyboard trap

(At last!) The Plans page

The `Help comparing plans` modal

  • The ‘Next’ button is oddly not focusable. Upon inspection, it does not have the required ‘href’ attribute. Adding this, even with the empty value of “#” makes it focusable
  • Nice to see three instructional boxes marked up as an ordered list.
  • Also nice to see the use of `<figure>` for the images.
  • However, the paragraph with additional helper information could be marked up as a `<figcaption>` for added semantics.

The main page

  • Bad: Skip to main content link appears to do nothing with the cursor
  • Bad: Nearly all buttons within a plan are not focusable via the tab key. ‘Quick View’, ‘Details’, ‘Like this plan’
  • Bad: Button labeled ‘See if providers & drugs are covered’ is not keyboard accessible. This is likely because it is an `<a>` without the `href` attribute.

See if providers are covered

  • The outlined box floating to the right is nicely marked up as an `<aside>`, however, the heading and paragraph inside are incorrectly marked up as `<div>`s
  • Small heading, ‘Matches for…’ — while marked up in a `<header>`, is further poorly marked up as a `<div>` with `<span>`s.
  • Each item’s markup starts great, but then breaks-down into unsemantic tags: ul > li > header > h3 — all good. `<div>` for the short paragraph: bad. `<label>` linked via ‘for’ attribute to `<input>` with — screen-reader class: good.
  • I see you have hidden the `<input>` and instead use ::before inside the `<label>` to place a custom-styled box instead. Good news is pressing ‘Spacebar’ on the keyboard correctly appears to toggle the ‘selected’ and ‘unselected’ states.

Plan detail view

  • The way everything is marked up in this view warrants tremendous room for semantic improvement. Nearly everything is a `<div>` deeply nested in other `<div>`s. There are a few `<ul>`s where appropriate. There are several areas where a `<dl>` is used correctly, and others where a `<dl>` would be more semantic than a `<div>`.

Quick view

  • It is odd for a modal window to scroll in and out of view. I recommend having three sections: `header`, `body` and `footer` (i.e. action bar). Make the body `overflow: scroll;`. That way, the plan name and buttons remain visible at all times, and only the details scroll in and out of view.


The Plans page

The main page

  • Scrolling to the bottom, I see an Important note about prices. This should be moved to the top of the page given its subject matter and importance

See if providers are covered

  • Odd that selecting one drug presents ‘1 drug selected’, but selecting 2 drugs presents ‘2 prescription drugs selected’. Why the omission of the word ‘prescription’ when 1 drug is selected?

In conclusion

Aspects of the entire flow are surprisingly rich with accessibility considerations — through color contrast, semantic markup, and well-labeled content.

There appear to be a few ‘low-hanging fruit’ defects that, once accounted for, could help make the experience for people using assistive technologies or only a keyboard much more accessible.

Your turn: visit healthcare.gov/see-plans




Designer, Developer, DataViz, Dad • rmion.com

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

DIY scrapbooking style wedding album: design ideas

Award-Winning Startup: ecospire™️

How to reboot your productivity using UX writing strategies

My Windows 11 Experience

PM: Week 3


Designing for Outcomes: Building Better Hackathons, Design Jams & Workshops

The Truth About $5 Fiverr Logos

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Robert Mion

Robert Mion

Designer, Developer, DataViz, Dad • rmion.com

More from Medium

Human Decision Making is Rarely Rational

The Story of Kieran and the Problem of Unknown Knowns

A Different Type of Not Working, and Then Looking for Work

A collaborative project from Masai school.