Accessibility for designers
On this page:
Accessibility is everyone's job. It isn't just something developers add in at the end, because critical decisions are made throughout the design and development process that affect how a design will be developed.
Following are a few questions designers, information architects, and others should consider during the design phase of a project. Answering these questions will help you design for accessibility.
Structure is an essential part of the design phase, and it is critical for accessibility. Structure helps people navigate and understand your website or application.
- Are navigation elements consistent across pages? Any element that appears in more than one place should be identified consistently. For example, if the same button appears on several pages, it should look the same and have the same label each time. This helps people learn how your website or application works.
- What will the heading structure be? Headings are critically important because they form an outline. Assistive technology users refer to this outline to get an overview of the page. If you have multiple content areas, such as in an application, make sure each area's headings are structured the same. Check whether each page has an h1 (highest level) heading.
- How will the content be ordered? Consider how to arrange content for a large screen versus mobile or small screens. Your designs and the final product often may be two-dimensional, but the code to implement them is not. Screen readers read the content in the order it is presented in the code. This is the same order in which someone using a keyboard will reach interactive elements such as buttons and links.
- In what order will interactive items be reached? People who use a keyboard move through interactive elements such as buttons and links in sequential order. The order should make sense and be meaningful. All interactive items must be reachable and useable with a keyboard. This is essential for anyone using a keyboard or keyboard emulator, including screen readers, voice control or switch control.
- Is there content, such as navigation, that is repeated across multiple pages? Skip links provide a way to, for example, skip past the navigation to the main content. At minimum, is needed. Many content management systems will supply this, and perhaps . There might be other skip links that would improve the experience for someone using a keyboard, such as a link to skip past an embedded social media widget.
- How will the website or application look on different screen sizes? For example, in what order will different sections appear on a mobile device? A responsive design also resizes more elegantly for people who use screen magnification.
A lot of things need labels, and someone has to come up with them. Labels help people understand what actions they can take and are announced by assistive technology.
- Do all links, buttons, and other interactive elements have unique, descriptive labels? Beyond links and buttons, there are form fields (text fields, radio buttons, checkboxes, etc.) and other interactive items. If someone can click on it, it needs a name that can be shared by assistive technology. For example, if you have a link, more what? If possible, there should be visible text, and the label should match or start with the visible text.
- Are there any icons used without text? These need labels that can be announced by assistive technology. For example, an arrow icon button to expand or collapse options needs a label that can be announced to assistive technology. However, a checkmark icon next to the text "Success!" does not need a separate label because the text provides a label. If you would add a tooltip to identify the icon, that information is not available to someone using a keyboard and might need to be included as a visible label. For example, a star icon can mean several things: favorite, rate, or even bookmark. Consider adding visible text rather than using a tooltip to identify the icon's meaning in your design.
- What are the major regions of your design? Screen readers can navigate by regions called landmarks. For simple pages (web pages or applications), the landmarks are often a banner (the header), a single navigation, the main content, and the contentinfo (the footer). You may also have complementary landmarks, which are not the main content but related. The most common situation where you will need to consider landmarks is if there are multiple navigation areas. Each navigation area will need a name. The names help distinguish each navigation section for assistive technology users (for example, main, section, utility, or actions). You should also provide names for any complementary landmarks in your design.
- Does each page within the website or application have a unique title? The title should inform people of where they are, with the most specific information first. The title is the first piece of information announced by a screen reader when navigating to a new page.
Images and graphics
Images need alternative (alt) text, and someone has to write it. Alt text is announced by screen readers and is intended as a text alternative for people who may not see the image. Alt text will also appear as an onscreen text alternative if an image fails to load. Some images will be the responsibility of a content creator, but you will want to write the alt text for any images or graphics you provide. This includes logos, icons, charts and graphs, and any other images.
- Is each image, icon, or graphic meaningful or decorative? If you removed it, would you need text to replace it? If so, provide the replacement text as your alt text:
alt="description of the image".
- Is there visible text in close proximity to the image that describes it (that is not an image caption)? For example, on a profile page, the person's name might be located next to their image. In this case, alt text would be redundant. You can indicate this for your developer as
- Do any of the images include images of text? If so, assistive technologies don't have access to that text. The text in the image should be included in the alt text.
Color and style
Not everyone perceives color. The way colors are used, and the combination of colors chosen, can affect how well people with low vision or color vision deficits understand your website or application. Color contrast is especially important. Text and other objects need enough contrast to the background to be discernible.
- If your prototypes have color fidelity, have you checked the color contrast? You should check the color contrast of text to its background, inline link text to paragraph text, and buttons and other interactive elements to the background. The color combinations should exceed the recommended contrast ratios.
- Do you have any instructions that rely only on color? For example, "choose the green button to continue" doesn't help someone who can't distinguish which button is green.
- Is important information conveyed only through color? For example, if the only indication that something is overdue is red text, not everyone will perceive that. That doesn't mean the red text can't be used, only that another method of indicating the same information needs to be used. In the example above, adding the text "Overdue" would convey that information to people who can't distinguish the color. In some cases, such as graphs, patterns should be used in addition to color. Is any information lost if you view your design in grayscale, without color?
- Do any instructions rely only on sensory descriptions? Just as with color, not everyone can perceive sensory descriptors, like "the large button" or "on the right." Some descriptions, such as left and right, may not apply if content has been rearranged to fit a smaller screen or when accessed with a screen reader.
- Have you styled keyboard focus indicators? Vivid, visual focus indicators help anyone using a keyboard easily recognize which item is currently focused and can be interacted with. If the indicator relies on color, such as a ring around the interactive item, it must also exceed recommended contrast ratios.
Well-made tables are easier to understand. They are also easier to navigate and understand when using assistive technologies.
- Have you provided a name for any data tables? Is a visible name possible? Data table names are conveyed by screen readers and other assistive technologies, which helps people understand the purpose of the table. This is particularly important if you have more than one table on a page.
- Have you marked the headers for any data tables in your design? Your table might have column headers, row headers, or both column and row headers. Screen readers announce the column and row headers for each data cell, which helps with orientation and understanding.
- If a table has more than one row and one column of table headers, is there a way to simplify or restructure the table? Complex tables are difficult to understand. It is also more difficult to correctly attach headers to the data cells in complex tables.
Simplifying an interaction or process reduces cognitive load. Simplification may mean more interactions are required to achieve the same end result. For example, a wizard acts as a guide through a complicated process in many steps. It may take longer but should increase confidence. Simpler interactions are usually easier to make accessible.
- Does the user interface (UI) behave in a predictable way? People with cognitive impairments are better able to complete their tasks when the UI behaves the way they expect it to. This also helps people with limited vision who may only see a small portion of the interface at any time. Simplifying an interaction is often about aligning expectations. How can you set expectations?
- Is there an easier interaction that would do the same thing? Choosing a familiar interaction helps people understand what actions they can take and how to take them. Complex widgets can also be difficult to use with a keyboard or a screen reader. Simpler widgets often have less chance of breaking.
- How will the widget work with a keyboard? Native HTML widgets come with built-in keyboard access. If you are designing a custom widget, you must also specify how it will work with a keyboard.
- Are any instructions clear? Clear instructions help everyone complete their task. For example, required fields or specific formatting should be clearly indicated on a form. How will you provide feedback, for example, if there is a wait while something happens?
- How easy is it for the system or the person using it to recover when something goes wrong? What sort of errors might occur? Can actions be reversed? Have you written clear error messages that will help someone correct the errors? Where will error messages appear? Does the UI help prevent errors before they happen, especially if the error would be destructive or have financial or legal consequences?
Decisions made during the design process directly affect over 80% of the 61 Web Content Accessibility Guidelines (WCAG) 2.0 success criteria. The following lists of criteria include accurate success criteria numbers and levels, with very simplified descriptions.
The following 25 criteria listed here are related to the questions above:
- 1.1.1 Level A - Images are described. Alt text.
- 1.3.1 Level A - The elements are semantic.
- 1.3.2 Level A - The order makes sense.
- 1.3.3 Level A - Description does not require senses.
- 1.4.1 Level A - Color is not the only indicator.
- 1.4.3 Level AA - Text contrasts with its background.
- 1.4.5 Level AA - Text is not part of an image.
- 1.4.6 Level AAA - Text contrasts more with its background.
- 2.1.1 Level A - Can reach everything by keyboard.
- 2.4.1 Level A - Can skip repeated things. Skip links.
- 2.4.2 Level A - The page has a title.
- 2.4.3 Level A - Actionable elements receive focus in an order that makes sense.
- 2.4.4 Level A - Links understood if moved. No more than 1 "read more".
- 2.4.6 Level AA - Pages, sections, and inputs are described.
- 2.4.9 Level AAA - Links understood if moved.
- 2.4.10 Level AAA - Sections are described.
- 3.2.3 Level AA - Instances of navigation are in the same order.
- 3.2.4 Level AA - Identification and patterns are predictable through consistency.
- 3.3.1 Level A - Errors are shown and described.
- 3.3.2 Level A - Inputs are clearly labeled.
- 3.3.3 Level AA - Error correction is described.
- 3.3.4 Level AA - Success or failure is communicated.
- 3.3.5 Level AAA - Help text is available.
- 3.3.6 Level AAA - Errors are prevented or reversible.
- 4.1.2 Level A - Code is valid.
By considering these questions, you will also address these three WCAG 2.1 success criteria.
- 1.4.10 Level AA - The view can be scaled.
- 1.4.11 Level AA - Controls contrast with their background.
- 2.5.3 Level A - Software sees the same name the user does.
Designers affect another 26 WCAG 2.0 success criteria not addressed here:
- 1.4.2 Level A - Sound can be stopped.
- 1.4.4 Level AA - The text can be scaled 200%.
- 1.4.7 Level AAA - Audio recordings don't have background sound.
- 1.4.8 Level AAA - Text is spaced for easy reading.
- 1.4.9 Level AAA - Text is not part of an image, no exceptions.
- 2.1.2 Level A - Won't get stuck while using keyboard.
- 2.1.3 Level AAA - Can reach everything by keyboard, no exceptions.
- 2.2.1 Level A - No time limit.
- 2.2.2 Level A - Can stop anything that moves automatically.
- 2.2.3 Level AAA - Interactions don't depend on timing.
- 2.2.4 Level AAA - The user isn't interrupted by updates and alerts.
- 2.2.5 Level AAA - Data is saved during re-authentication.
- 2.3.1 Level A - Nothing flashes.
- 2.3.2 Level AAA - Nothing flashes at all.
- 2.4.5 Level A - There is more than one way to find a page.
- 2.4.7 Level AA - The element in focus is clear.
- 2.4.8 Level AAA - Users know "You are here."
- 3.1.1 Level A - Doc has a lang attribute and value.
- 3.1.2 Level AA - Language changes are clear.
- 3.1.3 Level AAA - Idioms and jargon are explained.
- 3.1.4 Level AAA - Abbreviations are expanded.
- 3.1.5 Level AAA - Plain language is used.
- 3.1.6 Level AAA - Tips to help with pronunciation.
- 3.2.1 Level A - Element focus doesn't change things outside.
- 3.2.2 Level A - The context isn't changed upon input.
- 3.2.5 Level AAA - Context only changes on user request.
Additionally, these 14 WCAG 2.1 success criteria are affected by design decisions:
- 1.3.4 Level A - Can be used in any orientation.
- 1.3.5 Level AA - Inputs make sense.
- 1.3.6 Level AAA - Icons and regions make sense.
- 1.4.12 Level AA - The text can be scaled. Line height and spacing.
- 1.4.13 Level AA - Pointer or focus can move to new content.
- 2.1.4 Level A - Shortcut keys can be re-assigned.
- 2.2.6 Level AAA - Data isn't lost on timeout.
- 2.3.3 Level AAA - Can stop anything that moves on interaction.
- 2.5.1 Level A - Can tap instead of swipe.
- 2.5.2 Level A - Nothing completes while touching a screen.
- 2.5.4 Level A - Anything activated by motion can be activated another way.
- 2.5.5 Level AAA - Clickable areas are big enough.
- 2.5.6 Level AAA - Users can switch between keyboard, mouse, touch, voice.
- 4.1.3 Level AA - User knows the same status the software does.