Skip to content

Instantly share code, notes, and snippets.

@Londeren

Londeren/web-accessibility-a11y-guide.md

Last active August 2, 2022 12:48
Show Gist options
  • Save Londeren/6e5ef0fa55ba1a86f06223c173428d19 to your computer and use it in GitHub Desktop.
Save Londeren/6e5ef0fa55ba1a86f06223c173428d19 to your computer and use it in GitHub Desktop.
Download ZIP
Web accessibility (a11y) guide and best practices
Raw
web-accessibility-a11y-guide.md

Web accessibility quick intro

According to the WCAG (Web Content Accessibility Guidelines), there are four principles at the top of a11y that provide the foundation for a11y: perceivable, operable, understandable, and robust.

The key principles

  • Semantic markup — allows the application to be understood on a more general level rather than just details of what's being rendered.
  • Keyboard accessibility — the application must still be usable when using only a keyboard.
  • Visual assistance — color contrast, focus of elements and text representations of events.

Semantic markup

Use appropriate HTML tags and ARIA roles and attributes to make the application accessible. See Design patterns below.

Keyboard accessibility

  • Every interactive element should be accessible via tab key or space wherever it is appropriate (lists, tabs, chips etc.).

  • All modals, menus, popups should be accessible via tab key.

  • All the forms should be completed using only a keyboard.

  • If a modal or overlay opens, keyboard focus should be trapped inside the new context until it is closed. All modals should be closed via ESC key.

Visual assistance

  • The contrast ratio for text or elements and background should be at least 4.5:1.

  • The application, with resize to 200% in the browser, should be usable.

  • Every element with focus should have a visual indicator.

A11y design patterns

To make the application conform WCAG success criteria, it’s important to use semantic markup on a page.

See a list of the patterns described on ARIA (APG). See also the list of all ARIA design patterns indexed either by role or by ARIA properties and states.

Accessibility basc validation checklist

Semantic markup

  1. Use semantic HTML whenever possible: headings, buttons, navigation, links, lists (ul, ol, dl), tables...

  2. Nest headings from h1 downwards to show their relative importance. Don't skip heading levels.

  3. Use descriptive labels on controls and input fields: buttons with the icon only, links, inputs, text areas, radios, checkboxes, dropdown lists, list boxes.

  4. All images should have an alt text.

  5. Use autocomplete for inputs where appropriate.

Keyboard accessibility

  1. Make each screen fully keyboard navigable and operable by making sure that all screen elements that can be accessed with the mouse can be reached using the keyboard alone.

  2. All actions that can be performed using a mouse can be performed using the keyboard alone.

  3. All modals, menus, popups should be accessible via tab key.

  4. All the forms should be completed using only a keyboard.

  5. If a modal or overlay opens, keyboard focus should be trapped inside the new context until it is closed.

  6. All modals should be closed via ESC key.

Visual assistance

  1. Make all screen elements able to gain focus and the focus indicator clearly seen when using the keyboard alone.

  2. Add error explanation close to the error, showing what is wrong and how to fix it.

  3. All the required fields should be marked as required (*) and be pronounced as Required.

  4. Users should be able to resize the content in their web browser up to 200% without loss of meaning or function.

Getting started

Accessibility basics quick start

  1. Watch Accessibility Fundamentals with Rob Dodson
  2. Watch A11ycasts with Rob Dodson
  3. Read MDN on Accessibility

Dive deeper

Testing web accessibility

Manual and semi-manual

Automated

Additional resources

  • Web Accessibility Initiative WAI — Strategies, standards, and supporting resources to help you make the Web more accessible to people with disabilities.
  • WAI-ARIA (Web Accessibility Initiative — Accessible Rich Internet Applications) is a specification written by the W3C, defining a set of additional HTML attributes that can be applied to elements to provide additional semantics and improve accessibility wherever it is lacking.
  • ARIA Authoring Practices Guide (APG), recommends approaches to help web application developers make widgets, navigation, and behaviors accessible using WAI-ARIA roles, states, and properties.
  • WebAIM

Way more additional resources

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment