Digital.gov Guide

Accessibility for teams

A ‘quick-start’ guide for embedding accessibility and inclusive design practices into your team’s workflow
Illustration of seven people in a meeting in office. One is standing, six, using laptops, are seated at a conference table. One employee is in a wheelchair.

Accessibility for front-end developers

Reading time: 7 minutes

On this page

    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

    1. Use the keyboard to navigate through the page using the tab key.
    2. 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.
    1. Check to see that focus is always visible and appears in logical order.
    2. Make sure that no content gets focused offscreen or is hidden from view.
    3. 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

    Screen reader

    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

    1. Use a screen reader to make sure you can land on controls and that they’re announcing things as they should.
    2. 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">.
    3. If forms are present, make sure the screen reader reads labels and instructions.
    4. 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.

    Use VoiceOver screen reader on Mac

    • 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

    Web Content Accessibility Guidelines (WCAG) 2.0 references:

    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

    1. Headings briefly describe the section it introduces. Headings represent an outline of the content.
    2. Use h1h6 to define your section headings, where h1 is the highest section level and h6 is the lowest.
    3. Avoid skipping heading levels: Always start with h1, use h2 next, and so on.
    4. 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:

    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

    1. 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.
    2. 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

    1. Include meaningful information describing each image in the alt text.
    2. Use null (empty) alt text when text describing the image is already on the page (alt="").
    3. Don’t start the alt text with Image of or Photo of – the screen reader already announces that images are images.
    4. 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

    1. Use a color contrast tool and test that the contrast between the text and background is greater than or equal to 4.5:1.
    2. Use an automated tool to quickly scan for color contrast problems.
    3. 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:

    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

    1. 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.
    2. 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.
    3. Continuous integration: Use a tool like AccessLint to find accessibility issues in your GitHub pull requests.
    4. Simulate impairments: Use tools to simulate color blindness, low vision, zoom, low contrast, high contrast, and more.

    Resources

    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.