Web Content Accessibility

What did you see first on this page? The big bold text? Those are headings!

Why It Matters

Headings let people with sight skim the content. People who use screen readers can skim headings too when they're coded as headings.

Best Practices

• Use <h1> through <h6> tags to code headings.
• Keep heading text brief.
• Headings should summarize the content that follows.
• Users don't like skipped heading levels.
   

Your design should flex.  

Why It Matters

Users like to zoom in to see things better. On the web, most users have small screens.

Best Practices

• At 200% Zoom, text size must increase. Use real text, not images of text.
• At 400% zoom, content must reflow

Font style choices make or break readability.

Why It Matters

When text is hard to read, users complain or leave.

Best Practices

• Text must have good contrast.
• Font size is up to you. WCAG provides no minimum size requirement.
• Users like to zoom in. Text must be resizable up to 200%.
• Sans-serif fonts are easy to read.

Measure your text contrast.

Why It Matters

When text contrast is too low, it's hard or impossible to read, especially for a person with low vision.

Best Practices

• Test your text contrast using a contrast checker.
• Most text must be at least 4.5:1 with its background.
• Large text must be at least 3:1.

Visibility is usability.

Why it Matters

Informational graphics need good contrast so that people with low vision can see them.

Best Practices

• Graphical objects must have a contrast of at least 3:1 with adjacent content (with some exceptions).

Not everyone can see all colors. 

Why It Matters

If color shows meaning, show it another way too.

Best Practices

• Colorblind users need text, icons, shape, texture, or other visuals.
• Blind users need text. The text can be visually hidden.

Smart decisions start with data.

Why It Matters

A person who uses assistive technology wants to see and compare data. Build it wrong and the meaning is gone.

Best Practices

• Tables should display data, not build a page.
• When there are many data tables on a page, give each one an accessible name.
• Header cells must be programmatically associated to the data cells.
• If you use color to highlight data, think how a person who can't see color will understand the meaning of the color.

🚨 Your design can cause physical harm.

Why It Matters

Flashing can trigger epileptic seizures to some people.

Best Practices

• Don't let things flash.
• If things must flash, it must follow this rule.
• Users must be able to pause, stop, or hide animations that last for more than 5 seconds.
• Keep animations subtle.

Test with a keyboard.

Why It Matters

Not everyone uses a mouse.

Best Practices

• Do it with a mouse. Now do it with a keyboard.
• Focus should move in an order that makes sense.
• Don't let focus disappear while tabbing.
• Don't let the keyboard focus get trapped.
• Shortcut keys should use a modifier key (alt, shift, ctrl, opt).

Developer Tips

• Learn how tabindex works.

An accessible form is a huge win for everyone.

Why It Matters

When forms aren't accessible, people can't get the services they need.

Best Practices

• Screen readers should say what sighted users see.
• Describe errors clearly.
• Give users suggestions on how to resolve errors.
• Let users confirm, correct, or reverse important submissions.
• Do the fields have boundaries with good contrast?
• Use autocomplete on fields when possible.

Visibility is usability.

Why It Matters

People can't see controls that have low contrast.

Best Practices

• Controls must have a contrast of at least 3:1 with adjacent colors.
• Disabled/inactive controls don't have a contrast requirement.

Keep everyone in the loop.

Why It Matters

When things appear on screen, users who can't see want to know about it.

Best Practices

• Dialogs must get focus when they appear. When dialogs close, manage focus.
• Screen readers should speak status messages.
• Let users know when content will change on input.
• Don't change context when items get focus.

Some users need more time.

Why It Matters

If there is a session timeout, let users know before time expires so that they can ask for more time.

Best Practices

• Give users at least 20 seconds to respond to a timeout warning message so they can extend their time.
   

Get to the good stuff fast

Why It Matters

Navigation should get users to where they want to go. Quickly.

Best Practices

• Give each page an appropriate page title.
• Keep menus and navigation consistent.
• Links should make their purpose obvious.
• Add skip links so keyboard users can bypass repeating content like navigation.
• Use landmarks to structure the page.

Users want to understand your instructions the first time.

Why It Matters

A person with a disability might do a task a differently.

Best Practices

• Describe controls by name, not just by how they look or where they are.
• People who are blind or have low vision need non-visual instructions.
• "Click" is an instruction for mouse users. Words like "activate", "select", or "press" work for anyone.
• Use plain language: Clear, concise, and well organized instructions.

Some images provide info.

Why It Matters

People who can't see an image want to understand its meaning.

Images that provide information visually, need alt text.

Best Practices

• Try to keep alt text short. Don't say "image of".
• Don't use images of text when you can just use text.
• If there's text on the image, put it in the alt text.
• For complex images (charts, infographics), provide the details another way - a list or data table.

Some images are decorative.

Why It Matters

People who can't see want to ignore images that are decorative. If they aren't coded as decorative, they get in the way.

Best Practices

• If it's just for looks, mark it decorative.
• Images that duplicate info are decorative.
• How to make images decorative

Show. And tell.

Why It Matters

People who can't see want to understand the data.

Best Practices

• Label things. Use text.
• Can a colorblind person understand it?
• Test it with a keyboard.
• Provide a table with the data.

Go Deeper

• Tableau accessibility
• Power BI accessibility

People want info in a way that works for them.

Why It Matters

• People that can't see, want to read or hear the info in the video.
• People that can't hear, want to read captions or a transcript.

Best Practices

• Video-only files must be accompanied with an accurate text description.
• Pre-recorded video must have accurate and synchronized captions.
• Pre-recorded video must have audio descriptions of important information that is provided visually.
• Videos that automatically start playing must provide a way to pause, stop, or hide the video.

People that can't hear, want to read.

Why it Matters

Information in audio format isn't accessible to people who can't hear.

Best Practices

• Audio-only files must be accompanied with an accurate text transcript or text description.

Make documents accessible.

Why It Matters

Documents should work for everyone.

Best Practices

• Test documents against WCAG.
• PDFs need tags for people using assistive tech.
• Word, Power Point, and Excel documents need to be accessible.

Let screen readers say it right.

Why It Matters

A screen reader can pronounce other languages correctly when the page is coded correctly.

Best Practices

• Use the HTML lang attribute.
• Set the lang attribute for the language of the page.
• Set the lang attribute for passages or phrases in a different language.

Choose the right HTML tag. Always.

Why It Matters

People who can't see need to know what things are.

Go Deeper

Some HTML tags provide semantics. Screen readers speak the semantics to the user.

• Semantics describe what content is, not just how it looks.
• The <h1> tag makes a screen reader say "heading level 1".
• The <button> tag makes a screen reader say "button".
• The <div> tag makes a screen reader say nothing extra.
• Using a <div> to create a button makes no sense and won't be accessible without a lot of extra work.

Developer Tips

• Choose the right HTML tag.
• Use native HTML instead of ARIA when possible.

Things go with other things.

Why It Matters

A user who doesn't see may not know when two things go together.

Go Deeper

A programmatic association connects things together in code.

Example 1: A text box with an associated label

• <label for="x1">Name</label>
<input type="text" id="x1">
• Label's for attribute references the textbox id, programmatically associating the elements.

Example 2: Radio buttons within a fieldset under a legend.

• <fieldset>
<legend>Do you agree?</legend>
<label><input type="radio">Yes</label>
<label><input type="radio">No</label>
</fieldset>
• The radio buttons, inside the fieldset, are programmatically associated to the legend. They are also (implicitly) associated to their labels.

Developer Tips

• Form fields should have associated labels.
• Form fields with a visible group label, should be programmatically grouped using fieldset/legend or role=group.
• Use aria-labelledby and aria-describedby to name and describe elements using text from other elements.

Manage focus as content changes.

Why It Matters

As things show and hide, users of assistive tech need you to guide them.

Go Deeper

When interactive content appears, it's usually the right thing to send focus to it. Users probably want to use it right away.

Developer Tips

• Use the JavaScript focus() method to manage focus.
• To be focusable, an element must be a natively interactive element or have a tabindex.
• The autofocus attribute sets focus on form fields at page load.
• To troubleshoot focus issues, document.activeElement says which element has focus.
• A Single Page Application (SPA) should pay extra attention to focus management.

Never Do This

• Don't tediously manage the general keyboard tab order with JavaScript focus() or tabindex greater than zero. Let the code order control the tab order.

Screen readers can speak without moving focus.

Why It Matters

Screen reader users need to hear status messages without the system focus moving.

• A status message is a short update that tells users something changed on the screen.

Go Deeper

ARIA live regions make screen readers announce status messages.

• A live region is a container for status messages.
• Screen readers constantly monitor live regions for content changes. When a change is detected, the content is announced.

Developer Tips

• The aria-live attribute creates a live region.
• To make the screen reader announce something, change the live region's text content using JavaScript.
• Certain roles (role=alert) can also create live regions.

ARIA is for experts.

Why It Matters

When ARIA is coded wrong, accessibility gets worse.

Go Deeper

ARIA helps assistive tech understand custom, complex components. 

• What is ARIA? (Accessible Rich Internet Applications)

ARIA can do powerful things that HTML cannot:

• Declare live regions: aria-live
• Build complex structures like tabs, trees, grids: role
• Hide stuff from screen readers: aria-hidden
• Override the accessible name: aria-label

Developer Tips

• You don't have to use ARIA. Use native HTML when possible.
• Know what you're doing when you use ARIA. Consult the ARIA spec or an expert.

Let users read better.

Why It Matters

Browser extensions and bookmarklets let users change text spacing to make it easier to read.

Go Deeper

Changing some specific text style properties should not break the page layout; things should reflow and flex.

People that like to increase text spacing:

• A person with dyslexia
• A person with low vision
• A person with a cognitive disability

Developer Tips

• Allow for these text-spacing overrides.
• Don't set fixed pixel height on containers. Allow containers to grow in height with text.
• Don't set overflow:hidden on text containers.
• Don't set white-space:nowrap on buttons, tabs, or links.
• Don't use text-overflow:ellipsis without a mechanism to reveal the full text.

Give users time to read new content.

Why It Matters

Content that appears on hover or keyboard focus shouldn't disappear or get in the way.

Go Deeper

Users want to control non-persistent content at their own pace. And dismiss it when they're ready.

Non-persistent controls: Temporary content that appears on hover or keyboard focus.

• Tooltips
• Dropdown Menus
• Pop-ups
• Popovers

Unpredictable temporary content can be difficult to use and disruptive for some people:

• A person with a motor disability
• A person with a cognitive disability
• A keyboard user

Developer Tips

• Content that appears on hover must be dismissible and persistent.
• Content that appears on keyboard focus must be dismissible, hoverable, and persistent.
• Don't use the HTML title attribute as the sole source of information because some users (mobile/keyboard) cannot trigger title attribute tooltips.

Provide simple pointer alternatives.

Why It Matters

Some people can't do complex pointer gestures. People click things by mistake.

Go Deeper

A complex pointer gesture is a multipoint or path-based gesture. Examples:

• Click, drag, drop
• Tap, slide, release
• Pinch to zoom
• Twist / Rotate
• Two Finger Scroll
• Three Finger Swipe

A simple pointer operation is a basic click or tap without a making path. Examples:

• Click a button.

People click/tap things accidentally. Users need a way to cancel the click/tap.

Developer Tips

• Provide simple click or tap actions as an alternative to multipoint gesture and path-based actions.
• Allow users to cancel accident clicks and taps. Use JavaScript "up" events (mouseup, pointerup) instead of "down" events (mousedown, pointerdown)

Don't force orientation and motion controls.

Why It Matters

Users may not be able to rotate or move their device because it's fixed to a wheelchair.

Developer Tips

• If device motion controls page content, provide another way or let the user turn motion off.
• Don't lock content to portrait or landscape orientation.