Accessibility for designers

• Overview
• Structure
• Labels
• Images and graphics
• Color and style
• Tables
• Widgets
• WCAG criteria

---

Overview

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

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.

Consistent navigation

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.

• Do use the same label and style each time the same item appears.
• Don't change the location or order of navigation items.

Hierarchical headings

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.

• Do use a hierarchical heading structure, starting with a level 1 heading.
• Do give distinct content areas descriptive headings.
• Don't skip heading levels.

Content order

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.

• Do consider the order in which content will appear on both large and small screens.

Focus order

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.

• Do consider the order in which interactive items will be reached.
• Don't include non-interactive items in the focus order.

Repetitive content

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, Skip to content is needed. Many content management systems will supply this, and perhaps Skip to navigation. 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.

• Do consider adding links to skip past areas like embedded social media widgets.
• Don't overdo skip links. Including too many skip links just adds more keystrokes.

Responsive design

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.

• Do design for different screen sizes.

Labels

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.

Interactive elements

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 More link, more what? If possible, there should be visible text, and the label should match or start with the visible text.

• Do provide labels for all buttons, links, form fields and groups of form fields, and all interactive items.
• Do use unique and descriptive labels.
• Do match or start the label text with the visible label.
• Don't use the same label on different items on the same page.

Icons

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.

• Do label every icon without text that is interactive. Examples include arrow buttons, plus and minus buttons, and edit pencil buttons.
• Do consider adding visible text, especially if you would include a tooltip to identify the icon's meaning in your design. For example, a star icon can mean several things: favorite, rate, or even bookmark.
• Don't label icons used with text, like a checkmark next to the text "Success!".

Landmarks

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.

• Do name navigation areas (for example, main, section, utility, or actions) to distinguish each navigation section for assistive technology users.
• Do name complementary landmarks.

Titles

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.

• Do give each page a unique title.
• Do format the title with the most specific information first. An example format is page title - section name - site name.

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.

Meaningful vs. decorative images and graphics

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".

• Do provide alt text for meaningful images, icons, and graphics: alt="description of the image".
• Do indicate if an image is purely decorative with alt="". (Assistive technology will ignore the image.)
• Do provide alt text if you aren't sure.
• Don't duplicate caption text in the alt text. Alt text describes the image while a caption gives context.

Images and graphics near descriptive text

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 alt="".

• Do indicate that alt text is not needed with alt="".
• Don't include redundant information in your alt text.

Images of text

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.

• Don't use images of text, if possible.
• Do include the image's text 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.

Color contrast

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 check color contrast.
• Do exceed the recommended minimum contrast ratios.

References to color

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.

• Don't rely only on color to identify something.
• Do find other ways to identify items.

Emphasizing with color

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?

• Don't rely only on color to indicate a point.
• Do include icons or text in addition to color.
• Do use patterns in addition to color for graphs, charts, and other complex graphics.
• Do view your design in grayscale to see if any information is lost. (Both Mac and Windows users can change their display to grayscale in the system preferences.)

References to senses

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.

• Don't rely on size, location or shape to identify something.
• Do find other ways to identify items.

Keyboard focus indicators

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.

• Do design vivid, visual focus indicators for all interactive items.

Tables

Well-made tables are easier to understand. They are also easier to navigate and understand when using assistive technologies.

Names

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.

• Do provide a name for any data tables.
• Do make the name visible, if possible.

Headers

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.

• Do mark header rows and columns.

Structure

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.

• Do simplify complex tables whenever you can.

Widgets

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.

Predictability

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?

• Do follow conventions so people know what to expect.
• Don't prioritize efficiency over expectations.

Familiarity

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.

• Do choose the simplest widget for the job.

Keyboard interaction

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.

• Do consider how a widget would work with a mouse, keyboard, and touchscreen.

Clarity

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?

• Do mark required fields on forms and indicate any special formatting.
• Do provide feedback.
• Do provide instructions for using complex widgets.

Recovery

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?

• Do write clear error messages.
• Do help prevent errors, especially if the error would be destructive or have financial or legal consequences.

WCAG criteria

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.