a11y design checklist

Quick Overviews on Common Topics

1. Ensure colors have enough contrast

• Text should be legible

• Interactive things should be noticeable (stand off background)

  • 3:1 contrast should exist in all states of a component.

  • Remember that background won’t always be white or black

  • Tinted backgrounds don’t cost much in contrast but do move the bar for success

  • Remember to design all the states. States you should think about when designing:

    • default

    • hover

    • selected

    • unselected

    • error

    • focus

    • active (list controls, interactive tables)

    • 3:1 contrast not necessary in disabled state (they can effectively disappear)

    • Beware inadvertently using Disabled styling when
      you intended Inactive or Unselected

• Don’t Rely on Color Alone When Providing Important Information

  • There are millions of “color blind” people

  • There are other millions of people who have other vision impairments that affect color perception

• Consider whether a Dark and Light version will ever be needed

  • We don’t have a Dark Mode, but having Light and Dark pairs is a step in that direction.

Details

Legible text

• 4.5:1 contrast minimum for normal text

• 3:1 for 2em text

• 3:1 for 1.5em text that is also bold

• Don’t use brand red on a dark (elm) background unless it is large.

Contrast checking tools:

https://webaim.org/resources/contrastchecker/

https://webaim.org/resources/linkcontrastchecker/

Frequently, in Chrome’s Dev Tools, you can just click on a color in the CSS panel to get the contrast value vs. background.

Open

Don’t Rely on Color Alone When Providing Important Information

Reversing foreground and background colors is an exception here. Also, you can use brand colors for emphasis in tag lines.

Avoid embedding text in images

The user can’t use their own tools to remap the colors for better contrast

2. Text should flow

• Change viewport width up to 1920px and down to 320px. All text should still be readable at all intermediate viewport widths.

• Line length is a usability issue but affects some people who have reading disabilities

• Using non-default browser text size (not talking about browser zoom here) up to 200%, text should not collide with containers. With this optional technique, ugly layout is OK but unusable is not.

3. Consider the size of the viewport in your design

• A lot of low-vision people use relatively small (~1280px max) screens because they have lower usable peripheral vision. A bigger screen means missing things and moving their neck a lot.

• Full-screen magnification is different that browser zoom.  Full screen magnification means things may be happening out of the zoom rect and not noticed.

• Setting focus to something (through user actions or programmatically) will automatically move the magnifier zoom rect to show the newly-focused thing.  

• Make Your Design Responsive (WCAG 2.1 requirement) unless something just won’t fit due to the type of info.

  • Data tables are an exception to this rule but some still collapse well into nested lists.

4. Ensure the heading (h1 - h6) structure makes sense

• Make the page structure make sense

• Be (generally) consistent within levels

• Generally there should be one and only one H1

• You can skip levels visually (example: H1 → H3) but probably not semantically

• Absolutely avoid inversions of levels (ex: don’t use Paragon’s H4 as superordinate to a Paragon H3 styling)

5. Ensure that links are discernible

• Links need to be discernible but don’t have special styling requirements when standing alone.

• There are special styling requirements vs. peer text when inline. Paragon generally handles this for you.

• The text of the link should stand alone / make sense out of context.

  • Avoid Click Here, Learn More, etc. (unless modified with screen-reader-only text).

6. Forms

• Include Textual Labels for Inputs and Form Elements

  • Icon is sufficient affordance for Search boxes.

• Don’t rely on placeholders in lieu of labels (though Paragon labels look just like placeholders when not focused)

• Don’t rely on title attribute tooltips

  • Use title attribute tooltips for icons only where they are needed for sighted-user usability.

  • Title attribute tooltip text should match or be a superset of the Accessible Name for an icon (for enabling sensible speech input – example: If a Search icon has a title=”Search”, and the user says “Click Search button” to their speech input program, the word “search” should be included in the Accessible Name).

7. Images

May or may not need alternative text. The way we have Paragon configured, you shouldn’t have to think about text alternatives for regular SVGs.

If you’re making decorative SVGs, they can have empty-string text alternatives if they aren’t conveying needed info (helps with efficiency of getting through the page). If they have needed info, you’ll need to add a text alternative (alt attribute for IMGs, aria-label for SVGs).

8. Support Keyboard Navigation for everything

• Try to use standard keyboard methods to match expectations from role & visual appearance

• No keyboard traps. You should be able to move through all interactive elements in the entire page with Tab, Shift+Tab, Esc (to dismiss pop-ups), and arrow keys.

• Sometimes more skip links (to jump over predictable / repeated content) are helpful

• Provide skip links to escape from deep / infinite-scrolling lists.

• Manually setting tab order is generally a bad idea; rely on browser default order in almost all cases.

9. Ensure animations don’t introduce usability issues

• Short ones (<2s) are sometimes helpful 

  • More noticeable

  • Reassuring that user action was received

• Generally it’s better if things (an item or surrounding items) don’t bounce (from CSS layout redraw) as you interact with something

  • Using box-shadows instead of border changes are frequently better for this reason, with the same or similar net result.

10. Other stuff

• Focus management is mostly taken care of for you in Paragon

• There should probably (in order to satisfy a likely WCAG 2.2 candidate Guideline) be a way to get to Learner Support of Help from every page

• Some interactive things could use dedicated HTML hotkeys

• Timeouts are problematic. Don’t assume people type, think, or move quickly.

• Provide Controls for Auto-Playing Media Content

• Things shouldn’t flash between 2x and 59x/second, to avoid triggering photsensitive epilepsy.

• Page <title>s and URL (back link queue) should change when the main header changes

  • A good <title> is frequently though not always some derivative of the main header.

  • If multiple tabs are open, you should be able to find your way back to the right tab based on the tab / page <title>.