Accessibility Principles and Guidelines for UX Designers

Universal Design is the process of creating one product for users with the widest range of abilities and in the widest range of situations. When designers began considering how to include an even broader range of people in their designs. It often excludes a lot of people because it only proposes one solution for everyone. Universal design is a one-size-fits-all solution.

Inclusive Design, which focuses on finding solutions to meet different needs. Inclusive design means making design choices that take into account personal identifiers like ability, race, economic status, language, age, and gender. Inclusive design is solve for one, extend to many. you solve for one type of user, and the benefit of that solution can extend to many other types of users. There’s no average person or target audience that we should design for.

• Accessibility is just one aspect of inclusive design.
• Only benefits the group the design was created for and existing users.

Designing products, devices, services, or environments for people with disabilities is called accessibility.

Equity-focused design: It asks designers to focus on designing for groups that have been historically underrepresented or ignored when building products. Instead of building products for groups of people who are currently being excluded, which is the goal of inclusive design, equity-focused design seeks to build products that meet the needs of specific individuals in groups who have been excluded in the past. The goal of equity-focused design is to uplift groups that have been historically underrepresented when building products.

Equality means providing the same amount of opportunity and support to all segments of society.

Equity means providing different levels of opportunity and support for each person in order to achieve fair outcomes.

a11Y = accessibility

In academia and the tech industry, we tend to think about accessibility in four big categories: People with motor disabilities; people who are deaf or hard of hearing; people with cognitive disabilities, like developmental, learning, or intellectual disabilities; and people with vision disabilities.

Some people have concurrent disabilities, where for example, a motor or cognitive disability can contribute to challenges with speech.

When designers focus on accessibility considerations, cognitive, visual, motor, and hearing impairments are the four main categories.

The social model of disability, which defines a disability as being caused by the way society is organized or how products are designed rather than a person’s ability or difference.

We need to account for disabilities that are permanent, temporary, or situational in our designs.

Situational challenges often aren’t considered legal disabilities, but we still need to solve them.

If we make the design of a product easier for people with disabilities, we also often make it a better experience for everyone else.

No two users are exactly alike. Physical and cognitive disabilities, as well as environmental factors, can inhibit people from fully engaging with technology: hardware, software, and beyond.

Accessibility is almost always intersectional; norms of gender, religion, or class may further include or exclude people from technology.

Learn about global user communities and how they use technology

• Don’t exclude people with disabilities from advancing and meaningfully making use of your app; expand your idea of the “average” in representation choices.
• Attend talks and meetups to learn from people who are accessibility experts in a certain geographic region or thematic area.
• When conducting your own user research, expand your sample to include participants with disabilities.
• If travel is difficult, use remote research tools to gather feedback from global users.

Be mindful about representing users inclusively

• Include diverse representation in your application: race, clothing, physical ability, and social class.
• Pay attention to details, as they speak for themselves.
• Learn about local design and embrace the aesthetics you find in your app’s visual language and imagery.

Accommodate different levels of literacy and many different languages

For people with disabilities, the literacy rate is even lower. When these users open your app, they may rely on symbols and pictures, potentially with accessibility aids, to perform tasks.

• Use simple, basic English and avoid jargon.
• Translate to languages your users are most comfortable with for reading. Test various languages and text flows in your app’s interface.
• Keep your sentences short and provide graphical cues to guide non-literate users and people with cognitive disabilities.
• Avoid complex hierarchical structures, such as menus, tabs, or drop downs, as users are more likely to get lost; plus, those who access your app with a screen reader might need a long time to find what they are looking for.
• Minimize the need to type or text search. Whenever possible, allow voice input, autocomplete text fields, and present browseable interfaces.

Empower your users when it comes to privacy, safety, and security

Online harassment based on disability, along with gender, religion or class is another common pain point. As a result, people with disabilities are especially hesitant to share personal information like phone numbers or pictures, which can make online participation even harder.

• Help users become aware of their privacy options and controls. Make these controls easy to discover and access.
• Clearly explain security and data handling of personal information. Let users adjust their privacy settings and provide maximum transparency about how third parties or others can access their data.
• Allow users who share the same device to easily discover controls to remove private content like search queries or recommendations, switch accounts easily, and learn about private modes.
• Allow users to report abuse or takedown sensitive or harmful content easily, and show immediate results.
• Enable people to backup or export information from your app in case their phone gets lost or stolen.

Build great user experiences for modest devices

• Test your layout and rendering on 480 x 800 px and screen sizes smaller than 4 inches.
• Reduce the download size of your app or offer a “light” version.
• Provide controls and visibility into the device storage and allow users the easy deletion of content.
• Control long-running or high latency processes to minimize battery usage for your app.

Ensure that your app functions seamlessly in intermittent networks — and when offline

• Make your app’s content available offline.
• Provide progress indicators and other status changes with meaningful alternative text for those who access phones through screen readers. User experience is crucial over poor connectivity, including for those who use assistive technologies.
• Support local caching of form inputs to avoid losing data — and user frustration.
• Render content progressively and pre-cache frequently-used content.
• Test your app in airplane mode to simulate a lack of connectivity.

Keep usage costs low

• Minimize high-bandwidth consumption, including videos, rich graphics, and auto refresh.
• Provide transparency and control into data-heavy applications.
• Keep updates minimal and relevant. Explain the value of each update in straightforward language.
• Allow users to try your app or service for free.

Treat accessibility settings as critical, not just as a checklist

• Familiarize yourself with the accessibility settings of the operating systems that you build on.
• Keep assistive technologies in reach while building and testing new features to ensure that things work seamlessly for all users.
• Simulate the most important use cases and user journeys with accessibility settings enabled.
• Test with real users in various countries as often as possible to track app performance, and insights into how to improve the user experience.

Consider environmental contrasts like sun and shade

• Make your app high-contrast by default — including all text and interaction design elements.
• Sufficient contrast is defined as having contrast ratio of 4.5:1 or higher for normal text, and 3:1 for large text greater than 18px.
• Test your application with a dimmed screen, in bright sunshine, and through the perspective of people who have low vision (by using vision simulation tools).

Color has meaning — use it wisely

• Include design elements to ensure that everyone who uses your app receives the same amount of information, regardless of ability to see or interpret colors.
• Use multiple visual cues to communicate important states of your app.
• Utilize strokes, indicators, patterns, texture, or haptics to describe actions and content.
• Always pair visuals and icons with text, especially on navigation and call-to-action buttons, to ensure robust access.

Design for various screen conditions and input abilities

• Always ensure that your designs work in both portrait and landscape mode. This ensures full functionality for people who need to mount their devices horizontally (eg. in front of their wheelchair) as well as those with broken screens with dead pixels.
• Your app should render text, dates, times, addresses, and phone numbers in the local format without cutting or overlapping text.
• Check your visual designs through the lens of magnification and zoom, as designs often break when magnified by up to 200%.

Go big

• Remember minimum size standards for touch targets. 48x48px (or 48x48dp on Android) is the minimum recommended touch target size that helps those with limited dexterity or low vision as well as those with damaged screens.
• Ensure that your interface scales down to 4” and up to 7"+ screens.
• Make text and typography elements large by default.

Inclusive design and accessible applications open the door for people across the globe to overcome barriers that prevent them from full participation with the tech that surrounds them. Indeed, thoughtful apps might empower them towards leading more fully independent lives. It is upon us as user experience designers and developers to make intentional design decisions that serve emerging internet users with disabilities in all contexts, and in all countries. Access to technology should be a global concern, and available to all.

Principles of accessibility

• Clear: Help users navigate by designing clear layouts with distinct calls to action.
• Robust: Design your app to accommodate a variety of users.
• Specific: Support assistive technologies specific to your platform, just as you support the input methods of touch, keyboard, and mouse.

A screen reader is a software program that uses a braille display or reads text aloud.

Navigation with a screen reader

• Explore by touch: Touch interface screen readers allow users to run their finger over the screen to hear what is directly underneath.
• Linear navigation: Users may also move focus by swiping backwards or forwards on a screen to read pages in a linear fashion, from top to bottom.

Navigation by landmark

Some assistive technologies allow users to navigate between page landmarks, such as headings, when these landmarks use the appropriate semantic markup.

Directional controllers

Hardware or software directional controllers (such as a D-pad, trackball, or keyboard) allow users to jump from selection to selection in a linear fashion.

Types of feedback

• Visual feedback (such as labels, colors, and icons)
• Touch feedback shows users what is available in the UI.

Focus control, or the ability to control keyboard and reading focus, can be implemented for frequently used tasks.

You can simplify how your UI is understood by using:

• Clearly visible elements
• Sufficient contrast and size
• A clear hierarchy of importance
• Key information that is discernable at a glance

To convey an item’s relative level of importance:

• Place important actions at the top or bottom of the screen (reachable with shortcuts)
• Place related items of a similar hierarchy next to each other

Visual hierarchy

While CSS determines the layout and appearance of a page, screen readers rely on the top-down structure of HTML on any platform (mobile or web). This structure creates a map for the screen reader to follow when reading the content.

Focus order

Input focus that follows the order of the visual layout usually flows from the top to the bottom of the screen. It can traverse from the most important to the least important item.

• The order in which elements receive focus
• The way in which elements are grouped
• Where focus moves when the element in focus disappears

Grouping

Items can be grouped under headings that communicate what the groupings are. These groups organize content spatially.

More accessible color

Color can help communicate mood, tone, and critical information. Primary, secondary, and accent colors can be selected to support usability. Sufficient color contrast between elements can help users with low vision see and use your app.

Contrast ratios represent how different one color is from another color, commonly written as 1:1 or 21:1. The contrast ratio between a color and its background ranges from 1–21 based on its luminance (the intensity of light emitted)

Logos and decorative elements

Decorative elements (such as logos or illustrations) might not meet contrast ratios, but if they serve an important function (like linking to a website) it helps to make them distinguishable.

Other visual cues

Multiple visual cues help communicate important states. Elements such as strokes, indicators, patterns, texture, or text can describe actions and content.

Touch targets

For most platforms, consider making touch targets at least 48 x 48 dp. A touch target of this size results in a physical size of about 9mm, regardless of screen size. The recommended target size for touchscreen elements is 7–10mm. Note that on iOS, 44 x 44 pt is the recommended touch target.

Pointer targets are similar to touch targets, but apply to the use of motion-tracking pointer devices such as a mouse or a stylus. Consider making pointer targets at least 44 x 44 dp.

Touch target spacing In most cases, touch targets separated by 8dp of space or more promote balanced information density and usability.

Font Mobile devices and browsers include features to allow users to adjust their font size system-wide. To enable system font size in an Android app, mark text and their associated containers to be measured in scalable pixels (sp).

Accessibility text refers to text that is used by screen reader accessibility software, such as Google’s TalkBack on Android, Apple’s VoiceOver on iOS, and Freedom Scientific’s JAWS on desktop. Accessibility text includes both visible text (including labels for UI elements, text on buttons, links, and forms) and nonvisible descriptions that don’t appear on screen (such as alternative text for images).

Alt text is a short label (up to 125 characters) in the code that describes an image for users who are unable to see them. As alt text is only for images, there is no need to add “image of” or “picture of” to the alt text. Include targeted keywords to help inform the user about the image. Use alt text to convey what the image is showing in an informative, short phrase. Write short, concise alt text that can be read quickly by a screen reader and give the user context. Lengthy descriptions in alt text may get truncated. Most screen readers do not read more than 125 characters of text. Placing keywords into the alt text simply for the purpose of improving SEO may confuse screen reader users.

Captions are the text that appear below an asset. They explain an asset’s contextual information–the who, what, when, and where. Both sighted and screen reader users rely on captions for descriptions of assets. For long descriptions, use captions instead of alt text since they are available to all users and alt text is limited to 125 characters. If alt text and captions repeat the same content, screen reader users may be slowed down. Use captions for long descriptions.

Alt text and captions contain different information. Alt text is only useful when the adjacent text and caption do not explain characteristics of the image that are important to understand for those who cannot see the image, such as descriptions of the colors, sizes, and location of an object.

Adjacent text or body text is the text next to the image that can explain the image within a narrative. If the adjacent text explains the asset, then alt text may not be needed and the alt tag can be left empty (alt=””). If leaving the alt tag empty, remove the imagery file name if it appears.

Embedded text in images Screen readers are unable to read text that is embedded in imagery. If there is essential information embedded as text in the image, include the essential information in the alt text. Take caution when embedding essential information as text in an image and repeating it as alt text.

Write clear and short accessibility text. Consider rewriting long and less concise accessibility text.

Control types and states

Screen readers may automatically announce a control’s type or state by either speaking the control name or making a sound. Usually the control type should not be stated because the ARIA label will announce the control type for screen reader users, making the extra label redundant. Consider not including the current state, in this case, that Wi-Fi is “selected.”

If the control type or state isn’t being read correctly, the control’s accessibility role may be a custom control or improperly set.

• Accessibility role association: Each element can be associated with an accessibility role on a website or can be coded to be communicated correctly. This means setting a button as a button, and a checkbox as a checkbox.
• Native elements: If you extend or inherit from a native UI element, you will probably find the correct role. Otherwise, to override accessibility information for each platform, see ARIA for the web and AccessibilityNodeInfo for Android.

Action verbs indicate what an element or link does if tapped, rather than what an element looks like. This describes what an element does without relying on visual acuity. The description read aloud indicates the action represented by the icon. Describing what the icon looks like may not explain what the action does. Accessibility text for a navigation menu could be “Show navigation menu” and “Hide navigation menu” (preferred) or “Show main menu” and “Hide main menu” (acceptable). Consider revising accessibility text that doesn’t indicate what action will occur, such as “Side drawer.”

Elements with state changes

For icons that toggle between values or states, announce the icon according to how it is presented to the user. For example, if a star icon represents the action of adding something to a wishlist, the app could verbalize “Add to wishlist” or “Remove from wishlist.”

• If the icon is a property of an item, screen readers will verbalize the current state (such as “on” or “off”) if coded as a checkbox.
• If the icon is an action and is selected, the text label can specify the action that occurs, such as “Add to wishlist.”

Control interactions

Users might navigate with a keyboard or other device, not with their fingers or a mouse, which should be considered when describing for users how to interact with a control. Accessibility software will describe the correct interaction for the user.

The command “voice search” describes the user task (search) paired with the input method (voice). Consider revising commands that don’t fully express how to activate a control. This voice command says “tap,” even though it could be selected via a keyboard press, switch device, or braille display. Because this is a task to perform a search, the action could be mentioned instead of “speak.”

Hint speech provides extra information for actions that aren’t clear. For example, Android’s “double-tap to select” feature prompts the user to tap twice. Android TalkBack will also announce any custom actions associated with an element.

Types of images

To find out if an image needs to meet color contrast guidelines and would benefit from a caption, determine if your image is decorative or informative.

1. Decorative images don’t add information to the content of a page. Decorative images:

• Don’t need captions
• Don’t have to meet color contrast guidelines
• Don’t need alt text
• Should have a null (empty) tag (alt=””) in the image label so screen readers skip them

2. Informative images convey a concept in a short, digestible manner. Informative images:

• Relay accurate information that is relevant to the adjacent text
• Need captions
• Need alt text if the caption or adjacent text does not explain the image
• Have to meet color contrast guidelines for essential items
• Informative images have essential and non-essential elements. Essential information should have a 3:1 color contrast ratio for large text and 4.5:1 for small text.

3. Functional images are logos, icons, images within a button, and images that are actionable, such as a link. The alt text for functional images differs from alt text for other types of imagery because functional imagery alt text depicts the image’s function — not its content or what it looks like. When the icon or image within a button has a specific function, add an alt tag to it explaining its function with an action verb, not the icon name.

• Logos may benefit from an alt tag describing their function, but they are a unique kind of functional image because they:
• Might not meet color contrast ratios
• Might not meet text size requirements
• However, when a logo is part of a text link and is only decorative without any functionality, add a null value alt tag (alt=” ”).

The alt text indicates that clicking on the logo will direct the user to the Google Search home website.

Using decorative images, such as a bicycle or an ice cream cone, to show a location may not be useful to screen reader users because it doesn’t provide additional information.

Screen readers can be difficult to use when:

• Sound plays over a screen reader, such as background music that autoplays (you can provide controls for users to pause or stop these sounds)
• Extra sounds are added to native elements (screen readers will be able to interpret native elements correctly)

Alternatives to sound: Visual alternatives can be given to sound or other critical audio elements and alerts, such as closed captions or a transcript.

Material Design uses motion to guide focus between screens. Surfaces transform into focal points for the user to follow and unimportant elements are removed. To allow users with motion and vision sensitivities to use interfaces comfortably, Material Design provides motion guidance,

• Enable content that moves, scrolls, or blinks automatically to be paused, stopped, or hidden if it lasts more than five seconds
• Limit flashing content to three times in a one-second period to meet flash and red flash thresholds
• Avoid flashing large central regions of the screen

High-priority controls

Controls that perform high-priority functions can be missed by users if timers cause them to disappear too quickly. For example, TalkBack reads controls out loud if they are focused on. Placing them on timers can prevent the controls from completing their task.

Implementing accessibility

You can test your design with the platform accessibility settings turned on (both during and after implementation.)

• Use native elements, such as the standard platform dialog. Be wary of using non-standard elements, such as a non-standard platform dialog to perform a standard dialog task. It requires extra testing to work well with assistive technology.
• Scalable text and a spacious layout accommodate users who may have large text, color correction, magnification, or other assistive settings turned on.
• Keyboard and mouse interfaces can have every task and all hover information available through keyboard-only input.
• Touch interfaces can allow screen readers and other assistive technology devices to read all parts of your interface.

Label UI elements

To let screen reader users know which UI elements are tappable, enable screen readers to read the names of components out loud. The contentDescription attribute can be added to components (such as buttons, icons, and tabs) that contain icons without visible text. For web apps, add an aria-label.

Testing and research

• Test your app for full task completion, beginning to end, with various assistive technologies turned on. For example, turn on Explore by Touch in TalkBack and change the speed at which text is spoken out loud.
• Have users with impairments test your app.
• Consider how individual elements can be made more accessible while also fitting together in a coherent user flow.
• Make the primary tasks in an app as usable as possible for a wide range of users.

Talk to your users, particularly those who use assistive technology, to learn about their needs, what they want out of your app, which tools they use, and how they use them. Become familiar with these tools so that you can give them the best experience.

Equity-focused design means thinking through all the aspects of a designed product and making sure the product is both accessible and fair to all genders, races, and abilities. Plus, the designs need to specifically consider underrepresented and excluded groups.

Gender nonconforming means having a gender identity that doesn’t conform to a society’s gender norms.

Nonbinary means having a gender identity that’s neither entirely male or entirely female.

Providing closed captioning and an interpreter during an online presentation is an example of equitable thinking at work. Not all who attend a presentation have impeccable hearing or sight, especially if there are attending guests who are Deaf, hard-of-hearing, or have difficulties with vision.