Create Inclusive, Accessible Products

Lori Neff at UXDX Community: USA East. Video: https://youtu.be/Rcp_weVyDLg

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

How I ended up in accessibility

[00:00:00] All right, welcome. Today we're going to talk about creating inclusive, accessible products. My name is Lori Neff. I'm a white female with short blonde hair and red glasses. My pronouns are she, her and hers. A little about me: I'm a principal accessibility engineer with Optum, with a long background in UX design and over 20 years experience in healthcare. I'm all about planting seeds of change. My favorite saying is that accessibility is an opportunity, not an obstacle.

[00:00:38] A little bit of backstory. Five years ago I was a UX designer leading a design system at Optum. My co-worker Thomas said you should come over to accessibility, and I resisted. I thought I knew enough about accessibility as a designer. I thought it would be boring guidelines and testing. No more design, and I like design. I like helping make things easier for my users.

[00:01:00] Finally I decided, I'll try it. I'll learn some things and then go back to UX and be a super pegasus-unicorn. But to my surprise it wasn't boring. In fact, it's the best job I've ever had. I didn't leave design behind, I learned that accessibility is an extension of design. So I've stayed. Now I coach teams every day on accessibility, and in my experience I've come across a lot of misconceptions. So I'm here today to share something to help you get started on a fundamental shift in how you approach inclusive, accessible design.

[00:01:44] Here's our agenda. It looks like there's not a lot, but there are actually so many things that we're going to cover today, so I'm going to talk fast. But thank goodness for captions. First, some fundamental tips on how to shift your mental model. This is what I want you to walk away with today if you get nothing else out of this talk. Next, I'll talk about four things to incorporate into your designs. Believe it or not, these four things address the majority of accessibility issues, and I promise they're easy to remember. And lastly, I've got some examples of how to communicate accessible design: tools, annotations, deliverables.

Learn about accessibility the way you learn about any user

[00:02:26] All right. Designers are so good at learning. We do it on every project. Maybe you're working with someone in a different field, a different process, a different mindset, different goals, so you put in the time to learn. For example, I was working on a tool for registered nurses who do home visits. I've never been a healthcare professional. I still don't know what blood pressure numbers mean. But I did a ton of preparation to understand and inform my designs: research, interviews, ride-alongs, journey maps. And we came up with something they loved.

[00:03:06] So I want you to treat accessibility in the same way. Learn about it. As a designer, I didn't take the time. I assumed that people with disabilities were edge cases. I thought I knew enough to make the design work, but by not taking the time to learn this, I was unwittingly creating barriers in my designs.

[00:03:28] So often when we address accessibility we come away with other benefits. Here are some examples. I had a complex infographic with embedded text that could not be read by screen readers, so when we took the text out of the image and put it on the page, not only was it better for screen reader users but we also ended up with improved search engine optimization.

[00:03:51] I had an order status page and I used color to indicate the status, which was problematic for the blind and colorblind and others who have difficulty processing visually. So I kept the color and added text to communicate the status, which meant that it was now easy to know the status even when there was a glare on the screen. Or when you're sharing in a Zoom call.

[00:04:17] We had a video that auto played on the homepage. It frustrated users who have difficulty with motion, and when we added a pause button it helped them, but it also helped when there were issues with low bandwidth. I wanted to share these examples to illustrate that making designs accessible didn't compromise the design. It enhanced it.

[00:04:36] So how do you start to get to understanding? One thing we as designers like a lot are simulators. These try to demonstrate certain types of color blindness, glaucoma, dyslexia and so on. Try these things out, definitely, but keep in mind that it's not going to be an accurate experience. It's like trying to simulate being a Formula 1 car driver by playing Mario Kart, the car racing video game. It can be fun, but that small experience is not the same as being an experienced driver in the Indianapolis 500.

[00:05:19] Remember, you're not the expert here. So what do you need to do? The same thing you always do: learn, talk to people, leverage their knowledge and experience. Watch someone with chronic pain or mobility issues navigate a site or an app with just a keyboard and no mouse. Observe someone with dyslexia or who's colorblind and note how they use tools like browser extensions to focus on text or adjust fonts and colors. Work with someone who has low vision, check out how they magnify a web page and enlarge text on a mobile app. Talk to someone who is neurodiverse or hearing impaired and have them tell you how they use automated transcription in meetings.

Page structure: containers and tab order

[00:06:05] Now that we've talked a little bit about adjusting our mindset, I'd like to give you four things to consider in your designs. This is something Thomas Van Volkenberg and I worked on together during our time at Optum, so I want to make sure I give him credit even though he's not here today.

[00:06:22] We're going to talk about page structure. Specifically, there are several aspects to page structure, and one thing is containers. Containers are sections of the page such as the header, navigation, main content, footer. It might be an aside. You are probably already able to find these things in your mind, and maybe even subconsciously, so just take the next step and document these. If you document them, then the developer can implement them in the HTML, and when the containers are implemented, then a person who uses a screen reader or other assistive technology is going to understand the structure of the content and can navigate using shortcuts.

[00:07:07] Another helpful bit of documentation in terms of the structure is tab order. Tab order is the expected order that will be followed by keyboard users and screen reader users. The tab order should follow the logical reading order, which is usually left to right, but it depends on the location. It's important to meet the user's expectations. The reading order should match for sighted users and for those with low vision, or screen reader users, or people who have difficulty processing visually. So taking the time to document this is helpful. Also as you're thinking about reflow for responsive design.

Headings, lists, tables and reflow

[00:07:52] The next part of structure is headings. We use headings to communicate the structure of the page. This can be done visually by formatting the text with size, color and weight, but you can also do this in code. For example, you can use HTML tags of H1, H2 and so on. That's how the developer is hopefully implementing it. So you've got this visual, you've got this code, and those should match. If it looks like the primary heading for the page because it's larger text, bold and a different color, then it should have an appropriate HTML tag that matches as well, like Heading One. Also headings should go in a logical order, starting with 1, following with 2, then 3. Don't skip levels, because if you go from H1 to H4, I'm going to wonder if I've missed something.

[00:08:51] All right. We talked about sections of the page, the order of the page, organizing with headings, but some content has its own structure, like lists and bulleted lists and tables. If the content is in rows and columns of information, it deserves to be a table, and if something is a collection of related items, it deserves to be a list. So take the time to call these out so that the developer will be sure to implement them appropriately.

[00:09:22] Also take the time to consider how different views will impact the layout. The page should adjust to different screen resolutions, it should adjust when the browser window is resized, or when you change orientation or magnify, providing optimal viewing across a range of devices. Your content should reflow appropriately so that it is still understandable and you can still get to all the information. So make sure you take the time to document this, so you're not surprised. If you want to go mobile first, or otherwise, whatever the approach is, as long as you've taken the time to consider that flow.

Color: contrast, context and focus indicators

[00:10:04] All right, so we talked about structure. Now we're going to talk about color. In terms of color there are some important principles to keep in mind. You can still use color, just don't use color alone to communicate meaning. Make sure you're meeting color contrast requirements, and this practice is good for everyone, not just users with vision issues.

[00:10:25] We've talked about this before, but consider how your designs are going to look over Zoom, or maybe they're going to be printed in black and white. If you have a status page or something, or in bright light such as outside on a mobile phone. Oftentimes a big part of this is when we need to be compliant with brand guidelines, design systems and so on. So if there are color combinations that aren't quite conformant to the standards, then use workarounds: add a border, a drop shadow.

[00:11:02] And when you're choosing colors, remember it's best to go beyond contrast minimums. We've got a contrast minimum of 4.5 to 1 for text, so I would suggest going 4.8 or 5.0 to 1 at least. Elements on the screen are more easily perceived when you've also got that little extra, if you want to go beyond that. You don't have to worry as much if you switch to a different background color or something. Anyway, it's finding the balance between beautiful and purposeful, which is not always easy to do but always benefits our users.

[00:11:44] To continue, it's really important to show examples. The design phase is that optimal time to identify gaps between brand marketing and potential accessibility issues. By creating a mock-up that shows the colors in an actual situation, we can show how it might look with accessible colors that support all users' needs and still support the brand, and now you can get buy-in much easier.

[00:12:07] Take the time to design a unique and highly visible focus indicator. Actually, when I was first designing for accessibility I was like, what is this border around things, this actionable item? And there are ways to make it attractive, so if you need to incorporate it you need to be mindful of it, but also you can make it really not only purposeful but also attractive. And remember to define what they should look like for all focusable controls on all backgrounds. A good focus indicator benefits all users. It's necessary for keyboard only users, but it's also helpful if you're a multi-tasker, to help you identify your place when coming back from an interruption.

Images: meaning, emotion and decoration

[00:13:01] Okay, number three: images. This is a really huge topic, so we're just touching on this briefly. Today you need to call out how each image will be described, and the level of description is going to vary based upon the type of image.

[00:13:21] Generally, you can put all images somewhere on this scale. There are those that convey meaning, which absolutely need to be described. Those that convey emotion, and these may or may not need alternative text, but I would err on the side of including text. And there are those that are decorative. They should not have alt text. So we're going to talk about those in detail.

[00:13:46] The first one is an image that conveys meaning. Honestly, this is the easier scenario, because if an image has meaning then the meaning definitely needs to be communicated. But often we encounter or create more complex images that are conveying multiple ideas and using visual elements to communicate the relationship between those ideas. For example, here's a diagram of a benefits strategy, linking current strategy, culture, population health needs and overall objectives.

[00:14:16] For a complex image like this one, instead of communicating it in the alt text, because that would make the alt text too lengthy and you can't pause alt text, the meaning can be communicated on the same page in adjacent text. That's what I'm showing here: there's the data visualization and then the descriptive text following it. Alternatively you can have a link to another page for a full description of the image, if it's really complex. But wherever possible, try not to embed any text in your images.

[00:15:00] Next there are insight or emotional images, and there's some debate about whether they should have alt text. But you probably went through a lot of effort picking this image, so reasonably you should put in the same amount of effort choosing the alt text as choosing the image. If you're not sure of the power of this, I have a blind teammate who used the alternative text on images to choose which cruise to take. So don't underestimate how powerful and effective alt text can be.

[00:15:36] What I also want to say is that there are really cool insights that you can provide with this alt text. I've got an image on this slide and the alt text is "the hands of an older man trying to open pain medication". But with word choices you can evoke different emotions. I could say "struggling to open medication" or "independently opening medication", and there are different emotions that have been evoked with those different statements.

[00:16:07] All right, decorative images. There are actually very few cases that are easily slam dunk, definitely decorative. A spacer, a rounded corner — we don't use those hardly ever any more, but those are images that would be decorative. And you want to document when you find a decorative image. On this slide there are a couple of examples. I've got a picture of a save button and there's a little disk icon in there. It would be redundant for the icon to have alt text, so basically you can ignore it, and I've got an annotation for that.

[00:16:52] Also, if it's truly just a filler image, fluff, then it's also most likely decorative and it should have an empty alt attribute. For example, I just chose this Florida image, I needed some sort of filler. It has no emotion or meaning, so I chose to consider this as decorative here.

Tips for writing alt text

[00:17:15] There is a whole art to writing alt text. We don't have time to cover that, unfortunately. There are lots of good resources, but here are some tips for right now. Avoid text as an image. If you've got something you want to look like a button, you want it to look really pixel perfect, I would highly recommend not embedding a cancel button. It shouldn't be an image with the word cancel in it.

[00:17:43] Also avoid including the word image in your alt text, because the screen reader already announces that it's an image. Describe the action, not the image. For example, "the next page" is much more meaningful than "the right arrow". Don't let the artificial intelligence that's available in a lot of mobile devices and so on choose the alt text for you, because it's often inaccurate. It's just not good enough yet. And don't have the developer do it, the developer doesn't want to have to do it. And lastly, I would say, include people with disabilities in your decision making process, because they can give you a lot of insights there.

Meet people's expectations

[00:18:35] All right, the fourth item: meet people's expectations. This is the good stuff. This is where you can really see the overlap of UX and accessibility. As you're creating designs, we need to make sure that people understand and confidently know what's going to happen when you use it.

[00:18:52] So there are three aspects of a thing: how it looks, how it acts, and what it says it is. There's this saying, "if it looks like a duck, swims like a duck and talks like a duck, then it's probably a duck", and these three things must all align. If it looks and acts like a duck but you call it a ukulele, then there's confusion and often frustration.

[00:19:20] Here's an example of this. On this slide is a picture of a Phoenix penlight. My friend Thomas told me a story about when he was on a cruise and the bill had come at the table next to him. There's a woman, she's digging around her purse to sign the check, she pulls out this thing that looks like a pen, but it turns out it's not a pen, it's actually a flashlight. So after trying and failing to write with it, she says "so dumb!" It looks like a pen, it rolls around in the bottom of your purse like a pen, it's even named like a pen — penlight — but this definitely did not meet her expectations, and not surprisingly she's frustrated.

[00:19:59] So you need to think about these three things. Perception: you're already thinking about this and already doing this when you make mockups. Just make sure you're mindful of color contrast and you include all states — focus indicators, error states, selected states — and behavior.

[00:20:15] Be very clear when you're describing the behavior of a component. Cover all important scenarios and user expectations. If you've got a search field, do results populate dynamically as you type, or do you have to press enter? What happens if the page refreshes? If a dialog opens and is cancelled, where does focus go? If a filter is chosen from a select list, is there a button to apply the filter or does it dynamically apply?

[00:20:46] I've got an example on the screen. There's "what email should we choose", with a radio button to select saved options or enter a new one. Is the email text field always visible, or is it only shown when you select new email? So I put in an annotation to clarify that it's going to be shown or hidden. And speaking of which, if you are using a progressive disclosure like this, then consider tab order. Don't throw focus into that new email text field when the radio button is selected, because that's going to throw you off. Maybe I chose new email, maybe I didn't mean to choose that.

[00:21:37] All right, so now I have more questions here than requirements that I've brought up for you, but as a designer, that's because you still determine the user experience. I just want to prompt you to consider these types of questions and build clarity into your mock-up. Honestly, having the conversation is the win here.

[00:21:56] So take the time to give controls a meaningful name. Here is a select list with a label of "reason for call". It's a good idea to specify the role as well. This includes that assistive technologies can provide context to users.

[00:22:21] There's another example: there's a prompt on a site, you can either subscribe or you can sort of skip that subscription. So I have an annotation that that skip button, well, it's actually a link, and will take you back to the home page. And the cool thing is that it looks like a link, it acts like a link because it's navigating you back to the homepage, and it has a role of link. So those three aspects of a thing have all aligned. So that's the ideal.

Documenting accessibility: annotations, kits and color references

[00:22:56] Okay, so we've gone through the four things. We've gone through structure, color, images and meeting users' expectations. And now a couple more tips on documentation.

[00:23:10] Version control can be a nightmare if you document everything for every page, so I would suggest leveraging template style guides and design systems. A lot of design software has add-ins or options for annotation badges. Figma has some good kits. I've created my own just because, well, thank goodness, nothing uses purple in our designs yet.

[00:23:38] But try not to show all annotations at once. You don't want to overwhelm whoever is consuming the document, so you could either choose to do it as a layer or as separate pieces. That's what I've done in this mock-up here: I've got the three pieces with the heading structure and the tab order and the containers, all on that single page, but they're side by side.

[00:24:07] And don't forget to take into consideration who's consuming this document, especially as you hopefully include people with disabilities in the design process. I personally use a keyboard almost exclusively, so I love it when I can navigate a mock-up with my keyboard. Sadly, design software just isn't there yet. It's not able to create accessible mock-ups, meaning that if I use assistive technology like a keyboard or a screen reader, I can't navigate that. So instead of that, in the meantime maybe put screenshots in a Word document along with a description of the mock-up in text. Maybe you can leverage some accessible code snippets. But basically, be mindful and considerate of your teammates.

[00:25:02] Colors, back to that. I would highly recommend WebAIM's color contrast checker as an accurate, reliable tool. And as long as you're checking color combinations, take the time to document them in your style guide. You might even indicate which combinations are preferred. Some work better in supporting your brand than others. This reference will save time, especially when you need a quick decision. I found that this reference ends up being used by almost everyone in the process at some point: stakeholders, brand designers, developers, content editors.

[00:25:45] All right, so, wow, we actually got through everything. Here's a quick summary. Build upon the mindset that you have as a designer, and learn about accessibility the same way you learn about other users, and try to address accessibility in design rather than waiting until development. So it's this phrase, shift left. And reviewing the design four, we've got structure, color, images and meeting users' expectations. Hopefully this helps you shift a little bit to the left and incorporate accessibility earlier on and make your designs more inclusive. Thanks so much for joining today.