Accessibility for front-end developers

Reading time: 7 minutes

Getting started

Accessible front-end development ensures people with different abilities can access, understand, and navigate web content, regardless of how they’re accessing it. Front-end developers collaborate with other members of a cross-functional team to implement a robust user experience.

How to use this guide:

We recommend conducting accessibility testing throughout the design and development processes.
A good place to start testing is on high-touch pages, critical user paths, and site-wide templates.
If you have project-specific questions, ask your agency’s accessibility team.

Keyboard access

Can you reach anything that’s interactive using the tab key?

Why it’s important

Maria has tendonitis and is unable to use a mouse; instead, she uses the keyboard to navigate the web.

Steps to take

Use the keyboard to navigate through the page using the tab key.
Make sure you can reach all interactive elements and trigger them with the spacebar, enter key, or arrow keys.

Use semantic HTML elements that are accessible by default (For example: buttons, labeled inputs, etc.). If you must use divs for interactions, ensure they are focusable and labeled appropriately.

Check to see that focus is always visible and appears in logical order.
Make sure that no content gets focused offscreen or is hidden from view.
Check to see that the page includes a skip navigation link (if navigation is present before the main content). This will allow users to skip past navigation to reach the page’s main content.

Resources

Web Content Accessibility Guidelines (WCAG) 2.0 references:

Video tutorial:

How I do an accessibility check

Can you use a screen reader to access the page content?

Why it’s important

Devonte is blind and uses a screen reader to navigate the web.

Steps to take

Use a screen reader to make sure you can land on controls and that they’re announcing things as they should.
Determine whether the HTML document has a language attribute so that screen readers will read it with the correct accent and pronunciation. For example: <html lang="en">.
If forms are present, make sure the screen reader reads labels and instructions.
Make sure that all links are properly descriptive. For example, the link text “Read More” provides no context about where the user will go if they click it, while “Read more about dinosaurs” describes what’s on the other side of the link.

Turn VoiceOver on: command (⌘) + F5
Go into web area: control + alt + shift + down arrow (⬇)
Navigate right: control + alt + right arrow (➡️️)
Navigate by heading: control + alt + command (⌘) + H
Click: control + alt + spacebar

Use rotor to browse pages. The rotor lists common elements like headings, links, and images, and lets you navigate directly to the element of your choosing.

Turn on rotor: control + alt + U
Navigate rotor: left and right, up and down arrows

Resources

Download NVDA screen reader (NV Access)

Web Content Accessibility Guidelines (WCAG) 2.0 references:

1.3.1 Info and Relationships

Video tutorials:

Screen Reader Basics: VoiceOver

Video tutorial: How I do an accessibility check (screen reader)

Headings

Are you using accurate headings on your page?

Why it’s important

Lalit is blind and uses a screen reader to navigate the web. She hears an outline of the page’s main ideas, then backtracks to read the parts she’s most interested in.

Steps to take

Headings briefly describe the section it introduces. Headings represent an outline of the content.
Use h1–h6 to define your section headings, where h1 is the highest section level and h6 is the lowest.
Avoid skipping heading levels: Always start with h1, use h2 next, and so on.
Use only one h1 per page for the page title.

Note

While HTML5 allows you to reset headings to h1 on new section elements, some screen reader users will have difficulty discerning the structure of pages with multiple h1s. For this reason, it’s best to include only one h1 per page.

Resources

Web Content Accessibility Guidelines (WCAG) 2.0 references:

2.4.6 Headings and Labels

Video tutorials:

Using headings

How I do an accessibility check (page structure)

Page structure

Are you using semantic elements and roles?

Why it’s important

Carlos is low-sighted and navigates pages by jumping to the page section he wants to get to.

Steps to take

Use sectioning elements to create a broad outline of your page content; examples of these elements include header, nav, main, and footer. Use content sectioning elements like section, article, and aside to organize the document content into logical pieces.
Add role="banner" to your masthead and role="contentinfo" to your page footer once per page to define landmark elements.

Resources

Web Content Accessibility Guidelines (WCAG) 2.0 references:

Video tutorial:

Landmarks

Images

Do images have good alt text?

Why it’s important

Carmen’s page didn’t load all the way and didn’t get to download the images.
Amanda is blind and has to read the alt text to understand the contents of the image.
John is looking for information with a search engine and needs help being directed to the right content (descriptive alt text will improve search).

Steps to take

Include meaningful information describing each image in the alt text.
Use null (empty) alt text when text describing the image is already on the page (alt="").
Don’t start the alt text with Image of or Photo of – the screen reader already announces that images are images.
If the image is decorative and you don’t want the screen reader to announce it at all, use null (empty) alt text (alt="") or CSS background images.

Resources

Web Content Accessibility Guidelines (WCAG) 2.0 references:

Color and contrast

Why it’s important

Is there enough contrast between text and its background color?

Rohit has low vision and needs content to have enough contrast to read it.
Esther is red-green colorblind and can’t make sense of information conveyed with color alone.

Steps to take

Use a color contrast tool and test that the contrast between the text and background is greater than or equal to 4.5:1.
Use an automated tool to quickly scan for color contrast problems.
Don’t use color alone to convey meaning. Use icons, text, and other visual elements to reinforce the meaning of the content.

Resources

Web Content Accessibility Guidelines (WCAG) 2.0 references:

1.4.3 Contrast (Minimum)

Video tutorials:

Meeting contrast requirements

How I do an accessibility check (contrast)

Automated testing

Did your accessibility testing tools provide accurate results?

Why it’s important

Including automated accessibility testing throughout the development process can help quickly catch many accessibility errors, but can’t guarantee that your site is accessible.

Always combine automated testing with ongoing manual testing. Manual testing is the most reliable method to assess accessibility.

Steps to take

Quick check: Use a tool to quickly check for common errors in your browser. You can use HTML CodeSniffer, aXe, Lighthouse Accessibility Audit, Accessibility Insights, or WAVE.
Build process: Integrate a tool like axe-core, jsx-a11y, Lighthouse Audits, or AccessLint.js into your project to programmatically add accessibility tests and catch errors as you build out your website.
Continuous integration: Use a tool like AccessLint to find accessibility issues in your GitHub pull requests.
Simulate impairments: Use tools to simulate color blindness, low vision, zoom, low contrast, high contrast, and more.

Resources

GOV.UK: What we found when we tested tools on the world’s least-accessible webpage

Video tutorial:

How I do an accessibility check (tools and extensions)

Disclaimer: All references to specific brands, products, and companies are used only for illustrative purposes and do not imply endorsement by the U.S. federal government or any federal government agency.

Accessibility for teams

Sections