Universal Design

Digital inclusion has its roots in universal design, a movement that began in the late 1960s and led to many commonplace accessibility improvements we see around us today. Architect and designer Ronald Mace coined the phrase universal design. He used it to describe the concept of designing usable products and the built environment for the most people possible, while crucially remaining aesthetically pleasing.

Fellow architect Selwyn Goldsmith, himself a wheelchair user, progressed the concept of universal design by championing the now ubiquitous dropped curb or curb cut (Figure 2-1). The curb cut allows wheelchair users or those with mobility issues to be able to cross the street more comfortably than with a standard raised curb. The dropped curb is also a prime example of how universal design helps as many people as possible. While initially intended to improve mobility for wheelchair users, it also allows parents with pushchairs and travelers with rolling cases.

I have summarized very briefly what each of these principles cover here. I’ve also given a quick outline of how each principle might apply to mobile. Some of the concepts here might be new, but we’ll cover all of them in later chapters.

Equitable Use

Make the design appealing to all users. The design should be useful and marketable to people with diverse abilities. Avoid segregating or stigmatizing any users. Provide an identical experience for all users wherever possible. If you have to provide an alternative experience, make this equivalent. Consider privacy, security, and safety for all of your customers.

In a mobile setting, this might mean avoiding using colors that don’t pass the WCAG 2.1 (Chapter 3) contrast ratio guidelines of 4.5:1.² Also, ensure your app works seamlessly with assistive technologies such as TalkBack and VoiceOver (Figure 2-2).

Flexibility in Use

Your design accommodates a wide range of individual preferences and abilities. Provide choice, facilitate the user, and adapt to them.

Examples of this in mobile would include supporting varying text sizes. Allow multiple methods of input for text such as on-screen keyboard, dictation (Figure 2-3), or external keyboard. Both platforms offer your customer various customization settings; respect these as much as you can.

Perceptible Information

Your design should communicate necessary information effectively to your user, regardless of ambient conditions or the user’s sensory abilities. Use different modes (pictorial, verbal, tactile) for redundant presentation of essential information. Provide adequate contrast between foreground and background – we cover this more in chapter 3. Provide compatibility with a variety of techniques or devices used by people with sensory limitations.

To meet this principle in mobile, we must ensure all content is accessible to the device’s screen reader or any other assistive technology available on the device. chapter 4 on the Android accessibility model and Chapter 6 on the iOS accessibility model will give you the tools to do this. Present your content in multiple means. Use a combination of color, shape, images text, and layout together to make your content meaningful (Figure 2-4). Your customer’s screen reader will turn text content into audio content, but it can’t do the same with text you provide as an image. For valuable content, consider offering this in an alternative means, such as a video.

Low Physical Effort

Ensure customers can use your design efficiently and comfortably and with a minimum of fatigue. Minimize repetitive actions and sustained effort.

All the buttons on your interface should be within easy reach (Figure 2-5), especially on large-screen devices. Provide shortcuts to common areas of your app, and support Google Assistant or Siri Shortcuts where possible.

Size and Space for Approach and Use

The final principle is mostly appropriate for physical items. The principle states you should provide proper size and space for approach, reach, manipulation, and use regardless of user’s body size, posture, or mobility. Make reach to all components comfortable, and accommodate variations in hand and grip size.

We can meet this guideline by making our interfaces adaptable to different screen sizes and text sizes. Ensure your app works with Switch Control and Switch Access, as well as allowing keyboard navigation; also, Voice Control and Voice Access (figure 2-6), allowing your customers to control your app with virtually no movement whatsoever. Any interactive elements should be at least 44px square so as not to insist on fine motor control.

These universal design principles have led to the creation of many items we would consider to be every day. We may not think of many of these products as “accessibility” features. Consider audiobooks, automatic doors, high-contrast signage, and flexible drinking straws. All of these products were created following universal design guidelines. They serve many people with different abilities but are improvements for everyone else as well. This is what we should be striving for in our apps. Our ideal aim is to create an experience that includes everyone.

Universal design considers disability and considers what you can achieve in modifying the design to help people experiencing that disability, thereby reducing the barriers for the use of the product. Reducing barriers widens the market for potential users. However, as universal design was developed in an era before digital, the approach has been tailored to physical products.

Inclusive Design

Inclusive design extends on the gains made by universal design. It is generally more tailored to digital interactions. While universal design considers disability, inclusive design considers individuals and tends towards a more accessible-first approach. Inclusive design takes a big step forward in recognizing that disability is not a permanent, binary state but a spectrum. Inequalities in people’s abilities are typical and vary as a function of time or situation. Inclusive design does this by considering people’s needs as permanent, temporary, situational, or changing. By improving an experience for people with specific needs and considering these needs in the first instance, we can extend this benefit to work for a broader population, therefore improving the experience for everyone at some point in their life.

I have outlined the principles and how they apply to mobile in the following.

Provide Comparable Experience

Ensure your interface provides a comparable experience for all. Allow people to accomplish tasks in a way that suits their needs without undermining the quality of the content. You can provide audio descriptions or a transcript of a video in your app. These would make your original content accessible. But does this alternative capture the essence and tone of the original? Mobile interactions have an exceptional quality to surprise and delight their users. You should make sure all of your users get such a rich experience, even if they are using an assistive technology.

An example provided by inclusivedesignprinciples.org is that of Android live regions (Figure 2-7). Live regions are an area of the screen that automatically reports to assistive technologies when the content changes. TalkBack will read this content without the user having to navigate focus to this content. iOS doesn’t have a live region feature, but you can create the same yourself using accessibility notifications. We cover these in Chapter 8.

Consider Situation

People use your interface in different situations. Make sure your interface delivers a valuable experience to people regardless of their circumstances.

Consider using your phone in bright sunlight, audio, and haptic feedback along with high-contrast colors which will help in this situation. Providing subtitles or closed captions (Figure 2-8) on your video content allows parents to watch videos with the sound down without disturbing their sleeping children.

Give Control

Ensure that people are in control. Your customers should be able to access and interact with content in their preferred way. Do not suppress or disable the ability to change standard platform settings such as orientation or font size (Figure 2-9). Additionally, avoid content changes that have not been initiated by your user unless there is a way to control it.

There are ways as a developer to disable some assistive features. For example, you can create an app that doesn’t support scaling text sizes. This might mean you get a pixel-perfect design, but it will significantly affect your user’s ability to use your app comfortably.

Offer Choice

Consider providing different ways for people to complete tasks, especially tasks that are complex or nonstandard. There is often more than one way to complete a task. You cannot assume what someone’s preferred method might be. By providing alternatives for layout and task completion, you offer people choices that suit them and their circumstances at the time.

A great example of this is deleting an email in iOS’ Mail app. I can do this with a tap (Figure 2-10), a swipe (Figure 2-12), or a long press (Figure 2-11). This lets me, as a user, pick the option that is fastest for how I use the app.

Add Value

Consider the value of features and how they improve the experience for different users. Consider device features such as voice, geolocation, camera, and vibration APIs and how integration with connected devices or a second screen could provide choice.

This is the area of inclusive design where mobile stands head and shoulders above other platforms. Mobile devices are full of sensors and feedback modes. External devices such as smart home, screens, or external controllers can be connected wirelessly. Picker controls on both platforms use haptics to provide tactile feedback to users when something has changed (Figure 2-13). While also being a satisfying experience, this is an essential feedback mode for customers with visual impairments, helping them determine when they have made a change.

Persona Spectrum

One of the greatest proponents of inclusive design in software is Microsoft.⁵ Microsoft has introduced a tool they call the Persona Spectrum (Figure 2-14).⁶ The Persona Spectrum helps us to consider what inclusive design means to the people who use our software.

Consider, as inclusive design does, that we class disability as permanent, temporary, or situational. An example of a permanent disability may be the loss of an upper extremity. Losing an arm would make many everyday interactions difficult, and some may be even impossible. For this person, improving your app might mean ensuring all your buttons are within easy reach of the thumb of the hand that is holding the phone. Or even better, add voice control features. In doing this, you would also help to make your app more usable for people who have recently experienced an arm injury and are using a sling. Arm injuries are a temporary impairment – we would hope at least. Our customer with a broken arm will regain full use of their limb in a month or so. With this improvement, you would also be helping new parents. New parents may spend much of their time with the use of one hand, while they use the other to hold or feed their infant, control a pushchair, or hold a hand. In this example, our new parent has a situational impairment. The use of their second limb is restored once their child falls asleep or is handed to another family member.

9

These examples provided by Microsoft also show examples of visual, auditory, and verbal persona spectra. A blind user would appreciate you considering how they would use your app without vision. This would also benefit someone who had recently had an eye operation, or someone who is currently driving and can’t look at their device’s screen.

Considering how your app functions for deaf people will help people with an ear infection or people who work in a noisy environment. A person who uses nonverbal communication would benefit from the same considerations as would help a temporary condition like laryngitis, or a situation like communicating with someone with a heavy accent.

Digital Inclusion

Making software in an agile organization consists of more than implementing a screen as a designer has prescribed. There is much we can take from the design approach to inclusion. But not all of it is relevant to those of us who aren’t designers, and much doesn’t directly apply to the modern digital world.

We need a digital-first approach to inclusion, one that constitutes for a more rounded, high-level set of convictions. A strategy that recognizes everyone within the organization has a role to play in ensuring the service created is suitable for the highest number of people possible. Developers, with their advanced platform knowledge, constitute a significant part of this process. An essential part of digital inclusion is realizing that people with disabilities, while important, are not the only minority who want to use our service. Other factors such as age, gender, education, social grouping, income, and sexual orientation can all have an effect on how we experience technology. I have summarized my suggestions on what would make up the principles of digital inclusion in the following.

Individuals

I don’t believe there is anything inherently wrong in using the word users; in fact, I do use the term throughout this book. The problem is that this word can often hide who we’re really making software for – individuals. Each and every one of your users is an individual, each one with their own individual wants, needs, abilities, experiences, and requirements for your software.

Employing the word “users” can result in falling into the trap of thinking of users as one group – an amalgamation of people who are out there somewhere in the world using your app, a group of people that you’ll never meet and never know. This form of “group think” leads to creating a “one-size-fits-all” solution that, like everything claiming to be “one size fits all,” in reality fits no one.

The great thing about you is that no one else is you. No one else has your skills and experiences. In the same way, you have never met a “normal” person, because nobody is normal. Everybody sees and experiences the world differently because they have seen and done things differently. Remember that time you had a bizarre bug in your app that happened because one person was using your app in a way you could have never envisaged? We’ve all had that experience. People do unpredictable things precisely because they think and act differently. What may have been an inconceivable combination of actions to you may seem entirely reasonable to someone using your app. Conversely, things which may appear obvious to you are going to be incomprehensible to some of the people using your app.

It is entirely natural when creating anything to be consumed by others to build it for people based on our own experiences. The problem with doing this is that you, or any of the other people in your office, won’t be the main consumers of the product you are creating. While everyone is different, everyone working in a tech company office is, most likely, less different in some crucial ways than almost everyone else. There’s a good chance if you’re working in tech that you know tech pretty well and you’ve probably used quite a lot of it. Maybe you even enjoy using it; this is not the experience of a good many people.

Your Experiences

Think about your group of friends and your colleagues, and think about your family. All of these groups you, hopefully, get on with, but there are subtle differences.

Your friends are likely to be similar to you because you’ve chosen to hang out with them, and because they’re your friends, I can already tell they’re going to be awesome. Perhaps they don’t work in tech, but there’s a good chance that because you do, they will have a pretty high level of digital literacy. They will usually be a similar age to you, come from a similar background, and crucially enjoy many of the same things you do.

Your work colleagues are likely to be more varied, but there will still be things you have in common that are not representative of most people. You’re all of working age and able to work. You all earn a similar amount of money (comparable to the general population). And you’ll all have experience and interest in the industry in which you’re working. Compare this to your family. Most of us will be able to think of at least one family member who doesn’t use the Internet, maybe a family member who has a disability or for whom English is not their first language. Your family will make up a much more varied group than your friends and probably even your colleagues.

The best way to fix this is to speak to real people. We discuss user testing in Chapter 11. Hopefully, your organization will already be doing some form of user testing. Don’t write this off as an activity for design or product. Engineering can learn a lot too.

Empathy As a Motivation

So, you’re empathetic. You want to make a difference. You want to fix things for people with disabilities. This is a noble aim, but is it helping people with disabilities, or is it making you feel better? By saying you want to fix things for someone with a disability, consider what you are implying. Disability is not wrong and doesn’t need to be fixed.

People with disabilities want to have an equivalent experience. They want to be able to use your app just as anyone else does. Accessibility is not a gesture to make you feel better or to gain your brand influence. Accessibility is a tool to achieve inclusion within your software.

Bias

Unconscious bias is something we all have. It is an entirely natural part of being human that we have evolved as a survival mechanism. As such, to fight against unconscious biases can be counterproductive. Research on unconscious bias training shows that if anything, this makes biases worse and encourages stereotyping.¹⁷

The best option is to acknowledge and accept that we all have biases, and use them to help guide you. Ensure your team is as diverse as possible. This will help your team empathize with as many people as possible by using each other’s personal knowledge and experience in the form of your own biases. In this way, you can build up a broader base to examine the consequences of the decisions made in your software.

Move Fast and Break Things

Overall, I would like us to finally put to bed the philosophy that has caused a whole lot of bad in software – “Move fast and break things.” Even Mark Zuckerberg¹⁸ himself seems to now be realizing this is not a legitimate way of operating anything, let alone a consumer-focused business. I want to propose a new philosophy we can use to make software, one where we work in a considered and empathetic manner to progressively improve the experience for as many people as possible.