Strategy Phase

This section highlights accessibility considerations for content strategy, including: sitemap structure, and wireframe creation.

Perceivable

1.3 Page structure

Important The page order is clear and makes sense.

Maintaining a logical order of elements on the page, both visually and in the source code avoids confusion for all users.

How to do it

Avoid changing the order and position of elements more than necessary across different breakpoints of the wireframes.

Use more than one sense for instructions.

Avoid relying solely on things like shape, sound, position and size to identify page elements in instructions.

How to do it

Consider tab navigation and non-visual page interaction when developing specialized design patterns.

Make instructions detailed but clear, considering that elements may move depending on the device, or may be interacted without visual feedback.

1.4 Text size, links, and color contrast

Critical Audio that plays automatically has controls to play, pause, mute, or adjust volume.

How to do it

The best practice is to avoid audio that plays automatically in the first place. But if you have to, give users control of that audio, so it isn’t competing with screen readers, or generally annoying everyone.

Note - Short audio alerts less than three seconds are excluded from this rule.

Operable

2.1 Keyboard access

Critical All page functionality is available using the keyboard.

How to do it

Navigation with tab, ← ↑ → ↓, and spacebar are the most common methods of browsing with a keyboard. Consider this when developing interactive patterns at the wireframe stage.

Page-specified shortcut keys do not conflict with existing browser and screen reader shortcuts.

How to do it

Avoid shortcut keys. They can seem like a good idea, but in practice try to keep the functionality of the site the same as the rest of the web. If you need shortcut keys the underlying design may just need some tuning to be more traditionally accessible.

2.2 Moving content and time limits

Important Any page or application with a time limit, offers the user options to turn off, adjust, or extend that time limit.

How to do it

Work with the developer and client to decide how the time limit will be eliminatd or extended, and include any necessary controls in the wireframes.

Carousels that rotate automatically have controls to stop and start the action.

Provide people control over the speed they read content as well as a way to reduce the visual distractions on the page.

Note - This also applies to moving, blinking, scrolling, or automatically updating content.

How to do it

Typically this means including play/pause controls on automatic carousels. Other dynamic time-based content will need controls added to the wireframes as well.

Level AA Multiple ways to navigate content

How to do it

Make sure a site has more than one way to navigate the site.

  • Clear and consistent main navigation.
  • Site search on every page.
  • An HTML sitemap page (which links to every page on your website) with a link to it after the "Skip to Content" link.
  • A related links section.

Exceptions - Confirmation pages, and sites with very few pages may not need multiple navigation paths.

How does a site map affect accessibility? Hover vs. click.

Menus have to open on click/tap. Touch devices typically can’t access hover states, and keyboard access isn’t good if a menu relies on hovering. There are two main approaches:

  1. If the site map is set up using folders and pages, every menu item has one of two functions. Either it links to a page OR it opens a folder (drop down menu). Not both.
  2. If there are no folders and pages themselves have child pages, then each menu item potentially needs to do two things. The navigation must have a link to the page itself AND a link to open a menu to show children.

This is an architectural choice that must be made up front and isn’t easy to change. The first option is simpler to design and make accessible. It also works more like typical menus at the OS level. The second approach is currently more common on the web, but is more complicated to make work well for everyone.

Understandable

3.2 Predictable site behavior

When an element receives focus it doesn’t change the page in confusing ways.

How to do it

Avoid overloading the focus state with additional functionality.

Interacting with a control doesn’t change the page in unexpected ways without informing the user ahead of time.

How to do it

Include submit buttons along with any form elements in the wireframes, and plan on having the user click before updating content or submitting data. A common way to fail here is to submit a form when an option is chosen in a select box.

Level AA Repeated navigation and other key elements stay in the same location across the site.

How to do it
  • Keep navigation menus in the same location on all pages.
  • Present the options in navigation menus in the same order on all pages.
  • Keep all other standard elements (for example, your search box) in the same location on all pages.

Level AA Repeated functionality is consistently identified.

How to do it
  • Icons are used consistently (for example, ‘Print page’ or Twitter link).
  • Elements with the same function are labelled and named consistently.
  • Elements with the same function have a consistent text alternative.

3.3 Forms and error handling

Required form elements or specific format requirements are noted in the element’s label.

Identify form validation errors and provide feeback close to the form element.

How to do it
  • If a form requires input in a certain format, show and describe the required format.
  • If a mandatory field is empty, highlight the field and explain what’s required.
  • Don’t ask for too much information, just what you need.
  • Be specific. Use clear, concise instruction and form field labels.
  • Highlight mistakes in forms with colors AND symbols.
  • Provide contact details on all pages (the footer is fine).

Important Sufficient labels, cues, and instructions for required interactive elements are provided.

Clear labels and instructions mean users will know what to do.

How to do it
  • Where a field needs a specific format, give an example (For example, for a ‘date’ field in a form you might use ‘Enter the date as dd/mm/yyyy’)
  • Mark required fields with an icon and explain what the icon means before the form.
  • Keep labels simple. (ex: ‘First name’, ‘Email’ , ‘Your message’)
  • Keep instructions simple. (ex: ‘Required fields are in red and have a * symbol’, ‘Fill in this form and click ‘Submit’ to get in touch’)