Accessibility Best Practices

by | Dec 2, 2022 | Knowledgebase

What to consider when thinking about accessible websites:

  • Color vision impairment
  • General vision impairment
  • Auditory impairment

And how these users can navigate a website. A website should be able to be entirely navigated with keyboard only!

Four Principles of Accessibility:

  • Perceivable
  • Operable
  • Understandable
  • Robust

Development Checklist

Appearance/Design

  • Color
  • Text: >16
  • Ensure text can be resized to 200% without loss of content or function (to be tested by AccessiBe audit before launch).

Structure

  • Present items in logical order
  • Use clear and helpful page titles
    • Only one H1 per page, following headings should be in sequence, heading levels should not be skipped
  • Consistent navigation bars on all pages
  • Avoid using sliders. The Accordion and Toggle modules in Divi may be used in conjunction with Divi Accessibility Plugin.
  • There should be multiple ways to access different pages/information on a website (e.g. search bar, nav menus, sitemap, breadcrumbs, helpful links after content).

Keyboard Access/Navigation

  • The Divi Accessibility plugin takes care of most of the accessible navigation issues for us. Here’s a list of the issues it solves:
    • Hide icons from being read by screen readers. Images that are decorative, like icons, should be hidden from screen readers. Otherwise, the names of the icons will be read out loud as text. This interrupts the reading pace. (“Hide icons” is checked in the plugin by default)
    • Dropdown menus are able to be opened using keyboard (“Dropdown keyboard navigation” is checked in the plugin by default)
    • Keyboard focus needs to be visible when used.
      • Hit tab a couple of times on any website – this is how you use keyboard navigation. Sometimes arrow keys are used too.
      • If there are no frames, you don’t know where you are in the navigation/site. To be able to use forms, buttons and links the user must be able to see which element they have selected. See an example of a site that uses keyboard focus frames.
      • “Keyboard navigation outline” is checked in the plugin by default
    • User needs to be able to jump to content
      • For people who use a screen reader, it can be annoying to have to listen to the same menus over and over again. For example every time they open a new page or post the entire menu gets read first before the content. (“Skip navigation link” and “Screen reader text” are checked in the plugin by default. This adds a “Skip to content” button which is not visible to the user until they hit ‘tab’ on their keyboard)

Links

  • Make the purpose of every link clear from its context (example: “There is a lot more information about accessibility on the W3C website.”)
  • Links in the body are distinguished from surrounding text (usually by underlining).

Images

  • Workflow: Change file name, upload to media library, and edit alt text FROM the media library that provides a relevant description. This will push alt-text to all places the image is used on the site.
  • Avoid images with text in them.
  • Why Alt tags are important:
    • If an image fails to load on a web page, a user can mouse over the area originally intended for the image and read a brief description of the image. This is made possible by the description you provide in the alt attribute.
    • Visually impaired users often browse the web with the aid of screen reading software. When you include the alt attribute, the screen reading software can read the image’s description out loud to the visually impaired user.
    • The alt attribute also plays a role in Search Engine Optimization (SEO), because search engines cannot “see” the images on websites as they crawl the internet. Having descriptive alt attributes can improve the ranking of your site.

Videos/Audio

  • Should not automatically play, should be able to be paused and muted using the keyboard.
  • Always make sure they have captions. Upload to YouTube and embed to get captions fast. You can edit the captions if what it automatically comes up with is incorrect.

Forms

  • Gravity Forms claims to be the most accessible form builder on the market. They made an Accessibility Guide for Developers! This is a great resource for learning some accessibility guidelines in the context of forms.
  • They do what needs to be done for us, but in general, do not hide field labels. Keep them visible.
  • According to Gravity Forms, keep headings, HTML blocks, standalone paragraphs, and other non-form-related information outside of a form. The screen reader won’t pick these up.
  • Input errors need to be clearly identifiable by the user (through visual cues and through the screen reader).

PDFs

  • Screen readers can’t read PDFs, so consider the information it needs to convey when embedding them in a site (or avoid embedding them on a site!). Add that information in text elsewhere.
  • As we get a handle on accessibility, consider offering PDF accessibility optimization?

Appendix/Further Resources

W3C Resources
AA Compliance List

There are three levels of conformance:

  • Level A is the minimum level (beginner)
  • Level AA is intermediate and includes all Level A and AA requirements. Many organizations strive to meet Level AA.
  • Level AAA is Advanced and includes all Level A, AA, and AAA requirements.

We’re going for AA, which includes everything below:

To be compliant at the beginner level, your website must:

  • Provide text alternatives for non-text content
  • Provide an alternative to video-only and audio-only content
  • Provide captions for all videos which include audio
  • Use more than one sense for all instructions
  • Not use presentation that relies solely on color
  • Make all functionality accessible by keyboard only
  • Ensure users have control over time limits
  • Provide user controls for moving content
  • Provide a “skip to content” link
  • Use clear and helpful page titles
  • Present items in a logical order
  • Make the purpose of every link clear from its context
  • Ensure page elements do not change when they receive focus on input
  • Clearly identify input errors

To be compliant at the intermediate level, your site must, in addition to the above:

  • Ensure the contrast ratio between text and background is at least 4.5:1
  • Ensure text can be resized to 200% without loss of content or function
  • Not use images of text
  • Offer several ways to find pages
  • User clear headings and labels
  • Ensure the keyboard focus is clear and visible
  • Inform users when the language on a page changes
  • Use all menus consistently
  • Use all icons and buttons consistently
  • Suggest fixes when users make errors
  • Reduce the risk of input errors for sensitive data
Getting Technical

ARIA is a W3C specification that stands for “Accessible Rich Internet Applications.” It consists of markup that can be added to HTML in order to communicate the roles, states, and properties of user interface elements to assistive technologies (AT). This information helps screen readers and other AT to better understand the elements on a web page and to provide a user interface that enables their users to effectively interact with those elements.

  • See an example of how a screen reader reads links, and how we can control how it reads.
  • Best Practice: If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.
Example Checklist 1

Section 1: Alternatives

  • Alt text (1.1.1): All images and non-text content needs alt text (there are exceptions)
  • Video & Audio alternatives (1.2.1): All video-only and audio-only content has a text transcript. Transcripts are clearly labeled and linked below the media.
  • Closed captioning (1.2.2): All video with sound contains accurate closed captioning.
  • Audio description (1.2.3): For any video with relevant information not conveyed by audio, add an audio description of information conveyed visually or include a text transcript.
  • Live captions (1.2.4): Any more formal, live presentations must have closed captions.
  • Audio description (1.2.5): An audio description is optional under 1.2.3 level A but not in 1.2.5 AA.

Section 2: Presentation

  • Website structure (1.3.1): Use proper markup techniques to structure your website’s content (e.g. use correct heading tags and HTML for ordered and unordered lists)
  • Meaningful order (1.3.2): Present content in a meaningful order and sequence so that it reads properly.
  • Sensory characteristics (1.3.3): When providing detailed instructions, make it so they aren’t reliant on a single sensory ability.
  • Use of color (1.4.1): Do not rely on color alone to convey information.
  • Audio control (1.4.2): Any audio must be able to be paused, stopped, or muted.
  • Color contrast (1.4.3): There must be a color contrast ratio of at least 4.5:1 between all text and background.
  • Text resize (1.4.4): Text must be able to be resized up to 200% without negatively affecting the ability to read content or use functions.
  • Images of text (1.4.5): Do not use images of text unless necessary (e.g. logo).

Section 3: User Control

  • Keyboard only (2.1.1): All content and functions on a website must be accessible by keyboard only (i.e. no mouse).
  • No keyboard trap (2.1.2): Keyboard-only users must never get stuck on any part of the website; they must be able to navigate forwards and backwards.
  • Adjustable time (2.2.1): If there any time limits on a website, users have the ability to turn it off, adjust it, extend it.
  • Pause, stop, hide (2.2.2): If there is content that blinks, scrolls, moves, users must have the ability to pause, stop, or hide it.
  • Three flashes or below (2.3.1): Web pages do not contain anything that flashes more than three times in any one second period.
  • Skip navigation link (2.4.1): A “Skip to Content” or “Skip Navigation” link allows users to bypass the header / navigation menu and go straight to the main content.

Section 4: Understandable

  • Page titles (2.4.2): Each page of a website needs to have a unique and descriptive page title.
  • Focus order (2.4.3): Users must be able to navigate through a website in a logical sequential order that preserves meaning.
  • Link anchor text (2.4.4): The purpose of each link should be clear based on its anchor text (e.g. don’t use “click here”)
  • Multiple ways (2.4.5): There are multiple ways to access different pages/information on a website (e.g. search bar, nav menus, sitemap, breadcrumbs, helpful links after content).
  • Descriptive headings and labels (2.4.6): Headings and programmatic labels must be clear and descriptive. They do not need to be lengthy.
  • Focus indicator (2.4.7): Any “user interface control” that receives focus from a keyboard user should indicate that focus on the current selected element (e.g. add a visible border around a text link).
  • Website language (3.1.1): Set the language for your website.
  • Language changes (3.1.2): Indicate any language changes for an entire page or within the content.

Section 5: Predictability

  • No focus change (3.2.1): Nothing changes merely because an item receives focus; a user must actively choose to activate an item (e.g. hit enter to submit) before a change takes place.
  • No input change (3.2.2): Nothing changes just because information is inputted into a field (e.g. form doesn’t auto submit once all fields are filled out).
  • Consistent navigation (3.2.3): Keep navigation layout consistent throughout all pages of the website (e.g. same links in the same order).
  • Consistent identification (3.2.4): Components that have the same function within a website are identified consistently (but not necessarily identically) (e.g. two check marks can indicate two different things as long as their function is different — one indicates “approved” on one page but “included” on another).
  • Error identification (3.3.1): Make any form errors easy to identify, understand, and correct.
  • Form labels and instructions (3.3.2): Programmatically label all form or input fields so that a user knows what input and what format is expected.
  • Error suggestions (3.3.3): If an input error is automatically detected, then suggestions for correcting the error should be provided.
  • Error prevention on important forms (3.3.4): For pages that create legal commitments or financial transactions or any other important data submissions, one of the following is true: 1) submissions are reversible, 2) the user has an opportunity to correct errors, and 3) confirmation is available that allows an opportunity to review and correct before submission.
  • Parsing (4.1.1): Make sure HTML code is clean and free of errors, particularly missing bracket closes. Also, make sure all HTML elements are properly nested.
  • Name, role, value (4.1.2): For all user interface components (including forms, links, components generated by scripts), the name, role, and value should all be able to be programmatically determined; make sure components are compatible with assistive technology.
Example Checklist 2

APPEARANCE

  • Text at least 16 px in size. (There is no standard, but 16 px is generally agreed to be a safe minimum size. )
  • Minimum color contrast rules are followed (see below for links to tools to help you do this)
  • States are not communicated just by color

KEYBOARD ACCESS

  • All links are keyboard-accessible (usually by using the tab key)
  • All navigation (menus) are keyboard-accessible
  • All dynamic elements (i.e., accordions, tabs, etc.) can be operated by keyboard
  • All other functionality is operable by keyboard (i.e., doesn’t require a mouse)
  • Keyboard focus is visible

LINKS

  • < a > tag is used for links
  • Links in body are distinguished from surrounding text (usually by underlining)
  • Link text is descriptive

STRUCTURE

  • Only one h1 per page
  • Headings should be in sequence
  • Heading levels should not be skipped

IMAGES

  • Images have relevant alt text or captions unless purely cosmetic
  • Images do not have title attributes

VIDEOS

  • Video does not auto-play
  • Video can be paused
  • Video has accurate transcript or captions (read how to edit YouTube captions)

FORMS

  • Fields have label tags
  • Fields are keyboard-accessible

PDFS

  • PDFs are accessible or have HTML equivalents. Note that making PDFs accessible is the responsibility of the client. Check out this guide on how to make PDFs accessible. Here are PDF techniques for WCAG 2.0 from W3C.