Quick Overviews on Common Topics
| Table of Contents |
|---|
1.
...
Ensure colors have enough contrast
| Tip |
|---|
Use the Paragon palette. These are the top issues it handles for you: |
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
Avoid embedding text in images
The user can’t use their own tools to remap the colors for better contrast
We don’t have a Dark Mode, but having Light and Dark pairs is a step in that direction.
| Expand | ||
|---|---|---|
| ||
Legible text
Interactive things should be noticeable (stand off background)
3:1 contrast
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.  Don’t Rely on Color Alone When Providing Important Information Consider whether a Dark and Light version will ever be neededReversing 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 1920 1920px and down to 320320px. It 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 an one and only one H1
You can skip levels visually (example: H1 → H3) but probably not semantically
Absolutely avoid 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.
Special There are special styling requirements vs. peer text when inline. Paragon generally handles this for you.
Text 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
| Tip |
|---|
Paragon form components handle these requirements for you. |
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
9. Animations
Short ones 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 noticeable
reassuring 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 help Learner Support of Help from every page
Most pages should have SkipNav links
Some pages could have extra jump-to-* links
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 titles <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>.