Accessibility for front-end developers
[ad_1]
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
tabkey. - Make sure you can reach all interactive elements and trigger them with the
spacebar,enterkey, 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
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
- 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.
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
- Headings briefly describe the section it introduces. Headings represent an outline of the content.
- Use
h1–h6to define your section headings, whereh1is the highest section level andh6is the lowest. - Avoid skipping heading levels: Always start with
h1, useh2next, and so on. - Use only one
h1per 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:
- 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, andfooter. Use content sectioning elements likesection,article, andasideto organize the document content into logical pieces. - Add
role="banner"to your masthead androle="contentinfo"to your page footer once per page to define landmark elements.
Resources
Web Content Accessibility Guidelines (WCAG) 2.0 references:
Video tutorial:
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:
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
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.
[ad_2]
