In the not too distant future, accessibility design will no longer be a nice-to-have in UX design job postings. It will be a standard requirement. An expectation. If you are a UX designer with only a cursory understanding of accessibility design techniques, you should improve on that as soon as possible. Soon, accessibility design principles will be as well known and commonly practiced as the famous Nielsen Norman Group heuristics. User empathy is rapidly becoming common practice within product companies and accessibility is gaining traction as a cardinal facet of empathy-driven design.
Designing for diverse users—that is, children, seniors, and people with physical, cognitive, visual, or hearing impairments—requires that we pay special attention to their unique needs.
With this in mind, I have been journaling some of the accessibility considerations that are top of mind in my own practice of UX design. While the accessibility design principles I’ll present in this column certainly do not represent an exhaustive list, they do provide a great starting point—or refresher—of accessibility considerations to keep in mind as you create your next digital experience. If you design digital experiences—or work with someone who does—think about where you could have applied these principles on past projects and, more importantly, start mapping out how you might leverage them on your current or upcoming projects.
Champion Advertisement
Continue Reading…
Remember the Limits of the User’s Memory
It is all too easy to design something that inadvertently relies on the need for recall. Because UX designers try to minimize elements and save space, one common pattern is using placeholder text within input fields to indicate their proper use. However, an issue with this approach is that placeholder text disappears as soon as the user begins typing, risking the user’s forgetting the exact requirements for the field midway through filling it in. One example is a sign-up form with specific input requirements for things such as date formats or passwords. Should the user enter the date as 04/13/1990, 04-13-1990, or even 04-13-90? Does a password need to include a special character and a number or just a number?
Emphasize recognition over recall.
Be sensitive to the fact some users have shorter memories than others. In the example, the space-efficient design is not the most accessible design.
Make sure items that may rely on recall are readily available throughout any interaction that depends on their use. This isn’t better just for those with memory challenges. It’s better for all users.
Manage the Flow of Page Elements for Keyboard-Only Users
Accommodate keyboard-only users by intentionally designing the order in which tabbing selects page elements.
One useful exercise is to simply start tabbing through a site that you’ve designed, asking yourself what would happen if you tabbed through the whole site. Would it flow as intended? Are some elements selectable only depending on your currently selected item? Map out the exact flow and order of tabbing through elements on the screen and demonstrate this order to your developers.
One good example is ensuring that, when the user tabs, the selection moves from a text-search field to any additional required search inputs—or even a brief list of suggested inputs—for instance, radio buttons for New and Used. Keyboard users must take action on these inputs before tabbing to the Search button. If keyboard-only users who rely on a screen reader were to select the Search button before the other search-related input fields, they would never discover the New or Used filters before submitting their search. This would be detrimental to their experience.
Consider Information Architecture, Proximity, and Grouping
When users tab through a digital experience, they form a mental model of where they can find related items according to which items are next to each other in the tab flow. For example, if they are tabbing through the top-level category Clothing and do not find Boots there, once they get to the next top-level category House supplies, they’ll assume the Web site does not have any boots for sale. Perhaps a top-level category presented much later on in the menu structure such as Outdoors contains the boots they were looking for, but it is unlikely that they’ll discover them.
Ensure that the information architecture matches the mental model of the user. This is even more critical than usual in accessibility design.
Use proximity to show a close relationship between elements on the screen. Proximity is a vital design consideration for users with low vision. These users may depend on a magnifying glass that enlarges specific portions of the screen, forcing other content off the screen as real estate begins to thin. This can lead to confusion or frustration. Whitespace is great and allowing your design elements to breathe is ideal, but you must also consider the criticality of the user’s viewing certain items together in a group and make sure they appear together under common magnification levels.
Operating systems have provided two solutions to this problem:
A split-screen mode in which one screen area shows the magnified part of the content and another shows the content at its normal size.
A picture-in-picture mode in which the user can control a magnifying glass, moving it around the screen to magnify specific areas of content while still seeing the content at its normal size outside the bounds of the magnifying glass.
However, there are still many users who do not use either of these tools, so we must support the use case of a standard magnification interaction in which the entire screen simply becomes larger.
Set Clear Expectations
Users benefit from designers’ clearly conveying what they should expect to see on a page or do with a user interface.
Create content that confirms the user is in the right place. For users who cannot synthesize such visual cues to indicate a change in an element’s state to frame the user’s current location, ensure that the page’s content explicitly does so. For example, if the user is in the Rackets category on a sporting goods Web site and tabs from Tennis to Racquetball, the page title and the heading within the body of the new page state should explicitly indicate what type of rackets are in the list of items for sale on that page. Purely aesthetic wayfinding mechanisms such as increased font size, bold text, depth, or a change in color to indicate that a tab is selected will not suffice alone. Explicit content to help users orient themselves must support purely visual navigation cues.
Ensure that the bulk of the content the user consumes naturally provides additional waypoints by being as descriptive as possible. This not only helps those with vision-related challenges, it also improves your search-engine results. This is yet another example where designing for diverse users benefits all users—and businesses as well.
Maximize the Relevance of Content, Reducing Users’ Need to Scan
It is important to present only information that is relevant to your users.
Know your users well. Understanding what they need and how to appeal them is critical—no matter who you are designing for. But the importance of understanding your users becomes magnified in accessibility design. Although your users’ needs depend on their specific disability, most users with disabilities cannot scan through a sea of content to find what they are looking for—particularly if they are using a screen reader to read everything to them. Therefore, creating maximally relevant content is even more critical than usual.
Present exactly what users are looking for.
Communicate information concisely, in a way that appeals to users, helping them to enjoy their experience. Scanning through large blocks of text or other forms of content is painful for everyone. Doing it with accessibility tools such as a screen reader compounds the issue. Of course, creating more accessible content also enhances every user’s experience, regardless of their ability—a theme you’ll see repeat itself throughout these principles.
Define an Explicit Content Hierarchy Using Semantic HTML
By properly using semantic HTML, you can create Web pages whose structure facilitates the use of accessibility tools such as screen readers.
Help users to build an accurate mental model of a Web page by conveying its structure clearly. While diverse users may interact with a digital experience differently from typical users, that doesn’t mean they have a very different mental model they’ll use to evaluate the content of a Web site or application.
Enable users to assess the value of a page’s content quickly. Most people, regardless of their physical or mental abilities, want to evaluate unknown content easily and determine whether engaging with it is worth their time and effort. They often do this by skimming section headings in the content that summarize or represent the content on a page.
Write semantic HTML—particularly for headings—to allow users with screen readers to gain an understanding of the content on the screen without taking the time to absorb all of it. We all want the Cliff Notes version first. Our time is precious no matter who we are. Make sure that your code is semantically correct. When you’re using visual tactics to represent a page’s hierarchy—whether section headings and their corresponding body paragraphs or a list of related concepts in an infographic—you must clearly demonstrate their hierarchy or other relationship through semantic code.
Polish Form Validation and Error Messaging
Even for people without disabilities, forms are a pain to fill out. Their painpoints are compounded for users who either rely on screen readers or screen magnification that focuses on a small portion of a Web page.
One common design pattern for forms is to display error states in a group at the top or bottom of a page. However, this is not an accessible approach.
Display error messages and helpful suggestions in close proximity to the fields to which they apply—in addition to displaying error messages at the top or bottom of a page. This makes error recovery possible for diverse users and makes error recovery more efficient for all users.
Define Context-Sensitive Keyboard Modes for Input Fields
An on-screen keyboard’s input type should not always be set to text. There are specific on-screen keyboards for several specific types of input.
Make sure the on-screen keyboard is relevant to the context. This reduces the inevitable frustration that is associated with filling out a form on a touchscreen device—whether a registration form or just a login form.
Set the keyboard type to email when the user is providing an email address.
Set the keyboard type to URL when the user is entering a Web address.
Use keyboards that are for numbers and telephone-number fields, too.
Supporting keyboard input types is incredibly important for users with dexterity challenges. It will no longer be necessary for people with shaky hands to toggle between keyboard states manually. This is even a thoughtful consideration for those with memory challenges because the keyboard type provides context for the action that needs to take place.
This is good for all other users as well, because it makes the process of inputting information more efficient. This is an important consideration for designers, who can offset the pain of filling out forms.
Couple Gesture Interactions with Non-gesture Alternatives
A lot of screen-reading software for blind or low-vision users responds to swipe gestures. But, while swiping can be an easy, efficient gesture in some cases—particularly with mobile and wearable devices, but also for devices with larger screens such as kiosks—a swipe cannot be the only gesture for completing any given action. You don’t have to stop using gesture interactions, but make sure that you also offer an accessibility-friendly alternative to initiating those interactions. For example, if an app requires users to swipe right to save a cooking recipe to their profile, perhaps you might also add an explicit Save Recipe button. This will help not only users with vision or dexterity challenges, but all users. Explicitly informing users about available actions reduces the chance of confusion.
Develop an Edit / Update Workflow That Also Enables Editing of Accessible Content Sources
For a small business that offers products and services at various prices, even if you did a great job of creating proper alt-text descriptions for images relating to your products and services, particularly those communicating pricing, prices change. If you update the price in an image, you must update the alt text as well. This becomes especially important when price changes or other content modifications occur frequently.
Build a multistep edit / update process into your workflow. You don’t want to end up with an image that reads $50 while the alt text still communicates the older price of $75 to screen readers. This would be bad for users and, consequently, your business as well.
Create Text-based Equivalents for All Nondecorative Images
Any imagery that is not purely decorative should have a text-based equivalent.
Provide a text-based equivalent for any visual content that you intend users to consume. Alt-text descriptions are sometimes enough to satisfy this requirement, as in the case of describing an image. However, sometimes simple alt-text descriptions of the content are not enough. Alt text typically describes what the content is. However, it is not always possible to convey the real value of content just by offering descriptive text. While alt text might be sufficient for describing an image, it certainly wouldn’t do a lengthy, informational video much justice. For example, consider a video lecture for a class. Describing the topic of the video in alt text just isn’t enough. Even though users would know what the video is basically about, they would miss the actual value of the content in the video. Therefore, if you are teaching a course through video lectures, you should also offer a text-based transcript of the course. Many educational organizations still miss the mark on this one.
Make sure you don’t limit the way you communicate content to mediums that are potentially inaccessible.
Don’t make the mistake of thinking that descriptive text is a replacement for core content text.
Use text-based equivalents to allow better on-page actions and navigation—in addition to providing the obvious value of enabling diverse users to consume content successfully.
Use text-based equivalents for image-based buttons to enable users to leverage efficient voice commands. While assistive technology is capable of receiving voice commands such as “Click Buy Now,” it also needs to be able to target a Buy Now button accurately. If there were no text-based equivalent for an image button, the user would not be able to use voice commands and would be forced to resort to an assistive function called the Mouse Grid—assuming the user decides to stay on your page at all.
Although using the Mouse Grid is a rather slow and inefficient method of clicking elements on the screen, it is certainly useful if there is no other alternative. By drawing a 3x3 grid on the screen and asking the user to indicate from which number in the grid to draw the next, smaller grid, the Mouse Grid eventually provides a small enough target on which to execute a final click. Do everything you can to enable more efficient methods of allowing diverse users to take action within your digital experience.
Conclusion
Accessibility design is a deep practice that goes beyond the principles I’ve discussed in this column. But, as a practicing UX designer, I’ve found the principles I’ve outlined here to be some of the most critical accessibility design considerations to keep in mind.
Think about some of the digital experiences you’ve designed—or even digital experiences you’ve used. Do they implement these principles? Where might there be room for improvement? If you think critically about some of these accessibility design principles within the context of the apps and Web sites you care about today, you will be more likely to implement them in the future. Let’s evolve the culture and appreciation of accessibility design together.
Dash designs usable, enjoyable digital experiences that are driven by research and guided by the needs and desires of internal and external stakeholders. In his work, he draws upon his past experience in startups, UX consulting, internships, and freelancing, as well as the wealth of UX knowledge he gained through his journey to earn an MS in HCI. From concept to launch, Dash incorporates Lean and full-cycle UX tools and methods. He is always excited by future opportunities to play his part in delivering innovative digital solutions. Read More