How can we provide an accessible user experience for keyboard-only and assistive technology users without affecting the experience for any other users? We’ve kindly asked Aaron Pearlman, Principal UX Designer at Deque Systems, to share some practical tools and techniques to ensure that we’re all providing an inclusive and accessible experience for our users.

As a part of our Smashing Membership, we run Smashing TV, a series of live webinars, every week. No fluff — just practical, actionable webinars with a live Q&A, run by well-respected practitioners from the industry. Indeed, the Smashing TV schedule looks pretty dense already, and it’s free for Smashing Members, along with recordings — obviously.

We hope you’ll enjoy the webinar as much as we did!

Aaron Pearlman: You should be able to see my screen. Okay, right now, let me just… There we go, very good. Well, hello everybody. Like I said, I am Aaron Pearlman, the Principal User Experience Designer for Deque. And I think— Uh, let me move— Zoom tends to put a bit of UI in the way, so I apologize if I look like I’m frantically moving and mouse hopefully it’s not showing up. And so, today we’re going to talk about the types of optimizations that you can make for Keyboard-Only and Assistive Technology users. As I mentioned a moment ago, these type of optimizations, these type of things aren’t going to preclude anyone else from using your… they’re not going to be unutilized by other people as well. They just tend to be things that are going to be more advantageous to users that dominantly use a system with keyboard Only User Assistive Technology.

Aaron Pearlman: For those who aren’t familiar with what that means, what a Keyboard-Only User Assistive Technology is— a keyboard only user would be somebody who just typically uses your keyboard to traverse a system. So they’re going to be using tab and Shift tab a lot and the arrow keys to traverse your system, so focus is quite important to them. You might find this one individual may have motor skill issues, may have vision deficiencies as well, the keyboard-only users, and then assistive technology users also use a keyboard to traverse your system, they may use other assistive technologies as well such as screen meters like VoiceOver or a braille reader or something like that.

Aaron Pearlman: So, that’s kind of what we’re focusing on — our users of that nature because a good portion of individuals who have disabilities tend to fall into this camp. That doesn’t mean everybody. Certainly, there are a myriad of different disabilities and gradiations in between, but for the purpose of this, this is what we’re going focus on today.

Aaron Pearlman: So, a little bit of an overview of what we’re going to cover: we’re going to talk a little bit of design process with plenty of maybe doing a little bit of an exercise type-of-thing that we might go into, maybe not, before we go to the skip links. And then skip links are going to be one of the features that we’re going to cover, ways to optimize your modal, and how to handle focus. So, these are going to be the three big categories that we’re going to cover and then we’ll have time for questions when we’re all done.

Aaron Pearlman: To start, I thought we could do a little bit of UX design process overview. I was in different workshops and stuff, I find that there a myriad of different individuals that are there from lots of different disciplines, not everybody is a user experience designer, so they may not be as familiar with the process that many UX designers employ. So for this, I thought we would just briefly go over it, we’re not going to spend a tremendous amount of time on it, but I find it merits going over just briefly. Also because it’s going to tie into designing accessibly as well. So, most UX design tends to go through a process called discovery, it’s not always called discovery, sometimes it’s called rapid ideation, rapid iteration. A lot of people have different names for it, but the point is that it’s the part of the design process where a lot of the fabrication happens.

Aaron Pearlman: It’s a lot of the time where we have also different ideas and requirements gathering, it’s one where a lot of research and synthesizing that with your organizational goals and filtering that with all of that information, and what comes out of it are typically artifacts that allow us to be able to build the system that we’re going to be making or the features that we’re making. Those tend to be — they’re not always — but they tend to be things like prototypes, sometimes you’ll see mental models that will come out of them as well. But a prototype in some level of fidelity that is a reflection of how your target user is going to achieve their goals. The TLDR is that reiterate design and we test with users and reiterate, test with users, reiterate, test with users, and then in the end, it ends up going to be built.

Aaron Pearlman: You think that’s important, is the considerations for accessibility are that we want to be thinking about and doing accessibility throughout that design process. And different levels of fidelity can merit, thinking about different types of things, it really depends. Won’t go into a lot of that, but just in general, we want to incorporate those heuristics and methods, and we’re going to as designers grow our powers of accessibility over time, just as we grow our powers of being a good user experience designer over time. There’s not an expectation in the beginning that you’re going to go and read WCAG 2.1, then you’re going to read the ARIA spec, and then you’re going to be done and you’re not going make any more mistakes, or you’re not going to miss anything when it comes to your designs and designing accessibly. That’s not necessarily reasonable by any stretch of the imagination.

Aaron Pearlman: Just know that you’re going to be learning over time. Certainly I still mistakes in accessibility, and everything that I work on and it’s just all about getting better. So, [inaudible] because I’m always designing accessibly. So one small plug though it’s relevant to what we’re going to be working on today is called Trane. It’s our fully accessible pattern library at Deque, we use it to build our own products. It’s an HTML, CSS and JavaScript front end framework, it quite similar to Bootstrap, if you’ve ever used anything like that. We also have a react library that’s sister library too as well. Our team develops in react. But we’re going to be looking at a few of the things in here today as examples. But this is open source, it’s available, there will be a link to it at the end of this deck, which I’ll make available to everybody.

Aaron Pearlman: And it’s free for you to use and get on get branches and use it to your heart’s content or contribute to it, we’d love to see a contribution to it as well. So just a small plug, but we will be referring to it as we go through. So for the first thing that we’re going to look at are skip links. And for those who may not be familiar with what a skip link is, skip links are little links that will tend to show up as the very first tab stop in a web application or website. And what they allow you to do is they allow you to bypass parts of the website. Why would you want to do that?

Aaron Pearlman: Well, if you have a website that has really rich menu, that may be a big billboard menu or just has a lot of stuffs to it, if you’re a Keyboard Only or Assistive Technology User, when you get to that site and your VoiceOver begins to read off of it, or even not, even, maybe you are a sighted user, you just use your keyboard only, you’re going to have to tab cycle through all of those different items to get down to the contents or to the workspace that you want to begin whatever your activity that you’re doing there is. And so, what a skip link allows you to do is to bypass typically, typically navigation to get to the workspace area of that application.

Aaron Pearlman: There can be multiple links sometimes and typically only see one, but we have some examples. I’ll show you an example of where you can use multiple skip links as well. So I thought we could look at a couple different types of Skip links or a few different types of skip links, and then we’ll look at another page that doesn’t have a skip link, and maybe talk a little bit about where one might be useful there. The first one we’re going to look at, hopefully you can see my screen. The first one we’re going to look at is this skip link that we use on deque.com and what it is, is what I would call a displacement element in that it displaces the page. So when I tab into here, I can see the skip link is there and it will tell me to skip to content.

Aaron Pearlman: And when I select that, it will send me to the content below, and I call it displacement because it literally inserts and hides itself and inserts itself into there and displaces it. This was the skip link that we chose to use for our content, but it’s one that’s very common. You’ll see it insert itself at the top of a website or web application. The next one we’re going to look at is one at a site that I’m sure that many of you have used or used quite frequently. It’s Amazon, we’ll look at their skip link. When I tab in there, if you look in the upper left corner there, you’ll see it overlaid, this is an overlay style, this is very, very common where it’ll overlay the content, and so it will often skip whatever’s behind it to show you the skip to main content there.

Aaron Pearlman: The pros and cons between displacing versus overlaying are negligible. If you find that your content is something that you never want to obfuscate, then you may want to insert something and just use it, displacement one, vice versa, it doesn’t matter, that’s fine as well. If you’re designing content that reads from right to left, like Arabic content, you may put your skip link in the upper right corner, it may merit that. It really comes down to what’s appropriate. But ultimately, that discretion will be to the designer in their team. So, this is an example of two skip links that were a single skip link, and I thought I would show you one where there are multiple options inside the skip link.

Aaron Pearlman: I’m going to pull up that example, this is from our pattern library. Now for this particular example, I wouldn’t actually design something that had multiple skip links for it because it doesn’t really merit it, but we just did it for the purpose of demonstrating it. So I’m going to tab in and in the upper left corner, we use an overlay that shows you two skip links right here. And these are tab stops inside of here, so if I hit tab again, we’re going to tab into the next one and if I tab away, it’s going to go. If I tab again, it’s going to leave and it’s going to go into the header at the top there. I’m going to shift tab back, shift tab back so that we can see that we can move in and out of here.

Aaron Pearlman: And then I will go ahead and enter one of these just so that you can see it. And what happens at this point when I select it, it sends me into the workspace area and it actually focuses that workspace area. What you’ll see for a lot of web applications is they don’t actually show the focus itself, we wanted to show that in our applications, this isn’t a focus of elements so to speak, but it is something that can take focus. And then from here, we’re going to focus and then we can go to the different items inside of there that are the focus of all elements that are inside of there, the [inaudible 00:12:28] elements. So, those are examples of a few different ways that you can do skip links.

Aaron Pearlman: Like I said, there’s an example inside the pattern library, you’re welcome to use it, we also have a version of it as well, I believe here that has errors. We have a single skip link example as well, and you can just use that as well. So we have a couple of different examples here. But those are examples of common ways that you can use skip links. And they are primarily beneficial to individuals that only use their keyboard to traverse the system when they use a system technology as a result of that.

Aaron Pearlman: But at sometimes, there can be other instances where that a skip link potentially could be beneficial. I’ve seen it can be potentially beneficial. You could imagine an instance where the big workspace of your site maybe it’s a bunch of search results and it does a lazy score where you’ll scroll to the bottom and then it’ll load more results, and scroll to the bottom and it’ll load more results, you scroll to the bottom, and it will load more results.

Aaron Pearlman: Well, how do you get to the footer? And I’ve had this trouble actually before, where I’ve gone to search engines and I was never able to get to the footer. And what would’ve been nice is the skip link that actually let me skip to the footer, because I was looking for information down in the footer. So there’s ways that skip links can be beneficial to that. It’s not the only way that you can solve that problem. Certainly, you can use hard keys or shortcut menus as well. There are lots of different techniques to accomplish these goals, but that’s the one that skip links tend to be very good at [inaudible 00:14:13]. Some things to keep in mind when designing a skip link is that, typically it’s going to be the very first tab stop on your website web application.

Aaron Pearlman: And that’s commonly where it’s found, and so if I’m screaming or a keyboard only user, I can get to it immediately. It’s the very first thing I can do when I enter in. So if it’s something that a web app that I use frequently, I can get right to what I’m trying to do. It should also be visually depicted where it is supposed to be in the information, in the AI basically, so you can put skip links and other parts of your application as well, like I could put one here if I wanted to, find a long scrolling stack site and I wanted to do that, and I wanted to have a skip link within something. I’m fairly sure that you can anchor into different things like that, but it should visually be represented where it should be, inside of the application.

Aaron Pearlman: In general, that’s extremely uncommon. Most skip links are always in the very first tab stops. In general, don’t do that. I think you technically can, but I would say don’t. And then the final thing is it is an interactive element and it’s the past color contrast, so make sure that it does, if you decide to use like an image or something in it, I would, but if you did, it needs to have the proper accessible name along with it as well. In general, most people use texts and links, so it’s going to be marked up as a link. Just make sure that it is passing color contrast so that it [inaudible 00:16:07]. Very good. So that’s kind of all we have for skip links.

Aaron Pearlman: It’s a fairly succinct but very common pattern that you see everywhere and it’s something that you can add fairly, it’s a fairly straight forward to add to your web application, but it can make a big difference for individuals who use their keyboard or system technology. So let me go ahead and close this and let’s move on to modal optimizations. Chose to do this because modals are very, very, very, very common amongst most web apps and they come in a lot of different forums, a lot of different ways that modals are shaped and created.

Aaron Pearlman: But some common things that I see that show up in more of the things that we can correct, until there’s some optimizations that we can do to make it a better experience for keyboard-Only and Assistive Technology users. And in general, I think your modal are much better one. One thing I thought I would show here really quickly is, one important thing that a Modal needs to do is it needs to be able to trap focus inside of it. I wanted to show an example of … it’s right here. I love dribble by the way, so this is not a dig against them. This is probably just a small oversight here. I used them all of the time as a delightful site and has wonderful stuff on it.

Aaron Pearlman: So if I were to hit the sign in, oops, I’m sorry, the sign up. Here’s a modal here and something that can happen sometimes. If you notice carefully, I’m hitting tab, tab, tab, tab, tab. As you can see behind the screen, it’s a little bit difficult to see. You can see focus hasn’t quite been trapped inside the Modal and this can happen sometimes. So if I was a user who’s using Assistive technology or a Keyboard-Only, it would be very difficult for me to get back to this.

Aaron Pearlman: It’s something that happens very, very, very, very commonly, and it certainly can happen when you’re inserting different interesting things into Modal. So something we want to make sure of, and the reason I’m bringing that up, the reason that’s actually very, very important is when a modal is evoked, it needs to sort of announce itself to the individual that evoked it, know what they basically just opened, but they actually opened the correct thing.

Aaron Pearlman: And so, the way that it can announce itself is that, either the body of the modal needs to be focused or potentially the header of the modal can be focused so that we can tell the individual that’s evoking the modal, that it is what’s happening. So if they have voice, they’re using for example, VoiceOver on it, it’ll tell them what they’re looking at. So I thought I’d give a couple examples of ways that the body can be focused and then an example of how model can focus the header instead and then what we can do with that.

Aaron Pearlman: I’m going to open up this really quick here. Very good. And so the modal that they have for this, I think it’s a clothing site right here. And what happened is it focused the body and I can show that best by… I’m going to turn on VoiceOver really quick. I’m going to pull it up.

VoiceOver: VoiceOver on Chrome.] Bonobos, [inaudible 00:20:10]-

Aaron Pearlman: And you won’t be able to hear it-

VoiceOver: Google Chrome, Aaron.pearlman@deque.com-

Aaron Pearlman: But you’ll be able to see it.

VoiceOver: Close the card, your card is empty, group has keyboard focus. You’re currently on the group in opening your card, close the card, your card is empty group. You’re currently on the group inside of web content, VoiceOver off.

Aaron Pearlman: So right there when I focused it, it read out a bit of everything that was going on your card closed and your card is empty because of the buying was focused at that point. And that’s perfectly valid. That’s a perfectly valid way of focusing your modals. It’s not a problem at all. And then from there you can tab cycle through everything that’s inside of it. Another common way of when a modal is evoked is to focus the header.

Aaron Pearlman: And that’s what we do in on the modals that we use for our applications is we focus the header. So I’m going to evoke the modal, and as you can see right here, focus is right here where it says modal with form, focus is right there on the header. We actually, rather than indicating that as like an index, we programmatically focus that. And the reason that we programmatically focus that as I tab cycle through here, it’s now going to the close button, also in the header, then to the first interactive element, which is field to the next field, to the next field, to the next fields, tabbing again to the save, tabbing again to the cancel.

Aaron Pearlman: And from here when I hit tab, if that header was a tab stop, it would go there, but we chose not to do that. Instead, we go to the close and the reason that we do that is just if somebody was using Voice Over as you may have seen some of what was being written and was going into my ears at the same time, it was actually very a bit distracting because it speaks very quickly, it’s a bit chattery. And so one of the optimizations that we wanted to make for the experience here was to make it a little less chattery. So yes, we announce it, it goes, we programmatically focus modal with form when they first get there, so that it lets them know that the modal that they evoked is in fact it’s what they’re currently focused on.

Aaron Pearlman: But we don’t need to announce it again and again and again if they were to cycle through this shifts cycling through this modal. So it’s a small optimization likely would be completely invisible to the majority of your cited mouse only users. But that small optimization, you can imagine if I used modals a lot for filling out forms frequently and I was a user that used Keyboard-Only or Assistive Technology that optimization would add up over time. So, little teeny user experience things that we can do, that can make a significant difference overall in the care that we can put into our designs, so that they’re the most often experience that we can provide.

Aaron Pearlman: Speaking of handling focus, the last one that we are going to go into is focus handling itself. And we saw one example of it, what can happen if focus can get lost in certain types of handling? But rather than being just something that can be a significant issue, the way that you handle focus can change significantly the experience that an individual would have. Really the rule about handling focus, especially with the two instances that we’re going to look at right now, which are, removing and adding elements to your work space or whatever you’re working in is that … It can definitely change how somebody interacts with it. And so we want to make it follow the expected experience that you would have for somebody who is a Mouse-Only user or a sighted user, a Mouse-Only user I should say.

Aaron Pearlman: In this instance we’re going to look at … for here we’re going to look at … Okay, let me drag it over. Hold on one second. I’m going to have to take this out of here temporarily. There we go. So you shouldn’t be able to see an example of a modal that I’ve designed, it’s actually a single modal, we have two kind of images of it and just one is just showing what’s below the fold there rather than making one really, really wrong or I just split it up so you could see what was below in fold. And on the right side, if you look, there’s a trashcan icon that is currently being focused. And so when we click on that trash can icon, assuming that there isn’t a dialogue that says, “Are you sure you want to delete it?”

Aaron Pearlman: Let’s just assume that that’s not the case. The real question then goes, what happens with focus there? Because when that trash can icon is hit or is selected, it is going to remove instructions that are in right here, and it’s also going to remove itself. So where does focus go? So we as designers, we want to choose where focus goes because otherwise the browsers going to choose for focus goes if you’re making a web application inside of a web application and we don’t want the browser to choose where focus goes because it tends to throw things to the body. So in this case, where we really want focus to go is we want focus to go to the next focusible element, not necessarily the … what I would call the analog to that, which will be focusing the next trash can, the trash can for instructions to instead we focus instructions to itself.

Aaron Pearlman: And the reason we would want to do that, is you can imagine if somebody accidentally hit, using their keyboard only they hit return, then they hit return again. It would have just deleted two sets of instructions instead of one. And we would want to, we prevent that for a mouse only user by literally having those things physically far apart. But we want to also be able to prevent that because focus is what they’re using to traverse this. So I thought I’d show another example of what do we do when we’re deleting the last item in entire section here.

Aaron Pearlman: Now we’ve got cooking instructions, the final instruction for instruction one, where does focus goes here? Now for this particular one, it’s going to follow suit with what the previous one was, which is it’s going to go actually up to the next focus but filled again, which is ingredient one for the same reason that we wouldn’t want to throw it to the trashcan again because then if somebody again hit select again or hit return again, we would be … They’d accidentally delete two things that they unintended, didn’t want to.

Aaron Pearlman: For the same reason, we wouldn’t necessarily want to throw that to one of these links here because we would have the opposite problem where they’d be accidentally adding things as well. And we don’t necessarily want it to go to the body, because we go to the body and your Voice Over user, your Assistant Technology user, is just going to start chattering about the modal again or rather than letting you continue to interact and do what you intended to do.

Aaron Pearlman: And then finally, the final example that I have here is what do we do when we’re going to remove the last item in this case, in the modal here, there’s nothing left. Where would I send it? And this is definitely up to the discretion of the designers to where it should go. There’s no, it’s not going to be inaccessible if you choose to send it to the clothes or send to focus maybe to the cancel. It doesn’t necessarily make it inaccessible, it’s just that, it really comes down to what would you expect? What information would you want to convey? What narrative do you want to convey to that user and where we choose to send it as we choose to send it back to the header to let the user know that they’re still on the modal, they’re still there, we haven’t closed it on them, for example there.

Aaron Pearlman: And so that’s actually a programmatic shift because like I said, it’s not terrible voice. It’s not as terrible focusible element like that. So we programmatically shift focus to that in this particular example. So those are some nice examples of what to do maybe with focus when you’re removing items. So I thought you could … I would show an example of what you do when you’re adding an item. So I’ve got example of that real quick here for focus retention.

Aaron Pearlman: And right here, we’re going to hit this add another … you can just focus here, add another ingredient and focus then shifts to the actual ingredient in this case, the field that you added for two reasons, one, because the assumption is by adding that next field that we wanted to interact with it and that would be the expected behavior if I was a Mouse-Only user, I’d be adding that presumably so that I could actually begin to type text into it.

Aaron Pearlman: And then again, we wouldn’t necessarily want to keep focus on another ingredient for the same reason that if they hit return again, we wouldn’t want to add two ingredients instead of one. It should be opposite problem of the previous example. And the final, the final example I wanted to show, because I think it might be worthwhile showing is … actually I have that example, I may pull that up in a little bit. But I can describe it pretty, pretty aptly in that, if you have what do you do when you evoke a modal? For example, you saved something, the modal goes away, where does focus now go and what we tend to do, but the rule of thumb on that is that you want to send it back to whatever element [inaudible 00:31:03] gets.

Aaron Pearlman: So if you imagine if you had a little edit pencil and you select it, opens up the modal, you fill out that modal, you hit save, you’d want to send focus back to that interactive element that tends to be … or we do. There may be instances where you want to send it somewhere else. If it’s a wizard and it goes somewhere else after that, again to the discretion of the designer, to what the narrative that you’re trying to tell us to where to go. But for things that are like the one … instance that I just described, which is very common. You evoke a modal, or you do something with it and it gets dismissed as a result of that and the context doesn’t necessarily change.

Aaron Pearlman: And you don’t want to send that focus back to where it was. And the reason for doing that is so that, a Keyboard-Only or Assistive Technology user can pick back up with where they are. Because remember they’re in that space and that space is somewhat linear as to how they traverse and especially when you’re using town to get through everything. So, I think we’re just about at 40 minutes, we just about at time for all the examples and things that I had. So I’m going to pass it back over to Scott.

Scott: Thanks Aaron. That was pretty awesome, and we do have a lot of questions from the attendee as well as a few from individually who couldn’t make it today because he’s traveling. So Poan who’s a regular attendee of our webinars asks, “When you’re removing items, shouldn’t we have an acknowledgement of the action and move the focus there and then move to the next element?”

Aaron Pearlman: when removing an item, should you have an … are you referring to like a notice like a toast or are you saying should you have a live region that is letting you know what’s happening? If you’re shifting focus to remove an item, like the ones that I just showed in that particular instance the evocation of that delete for example, should be adequate enough to let them know that they in fact deleted.

Aaron Pearlman: It should be gone. Also, if they’re using Voice Over, it’s going to pick that up as well. If you’re interacting with something and it’s making changes somewhere else, for example, like you did something and then it changed some metrics somewhere for example, you’re probably going to want to use a live region that does something politely to let them know that that’s happened. That’s something that’s sort of out of the purview of where you’re working in specifically. I hope that answers your question. It might be diving into something that’s a little bit more technical. I may need to follow up a little bit more with some of it, if we’re going to get into deep technical implementation stuff.

Scott: Perfect.

Aaron Pearlman: My developer, so they don’t steer you arrive but in general that tends to be the case. The example that I showed should be adequate. If you want it to because it’s a delete, you could have an interim part where you throw an alert and say, “Are you sure you want him to delete this?” Which case you’re just reinforcing it further what happening.

Scott: Great. So, yeah, try and keep the questions user experience focused. So from a user experience standpoint, how would you manage focus for notification messages?

Aaron Pearlman: Focus for a notification? I can show you one if you’d like to see.

Scott: Sure.

Aaron Pearlman: We can pick back random because we happen to have toasts, which are notifications. So I’m going to open up toasts here. So this is actually being focused right now. This toast is evoked and it is being focused right now and you can actually, as you can see, you can tab into the clause right here. So, it depends. So, if I finished something and I wanted to notify them that it’s been finished and I toasted it, then I want to focus it so that they can see that it’s been … that I’m communicating that information to them. So you want to shift focus to it.

Scott: Melanie is asking, “Do you have any tips for tips or resources for navigating slideshows?”

Aaron Pearlman: For navigating slideshows?

Scott: [crosstalk 00:36:00]. Very specific.

Aaron Pearlman: Yes. So navigating slideshows. We don’t use them very often, so I’m going to answer this as best as I can. So one slideshows especially ones that are like carousels, they need to have a control so that you can stop them. I think that’s an accessibility need, is that they have to have some control and a mechanism so that they can be stopped. Anything that’s an animation wise can’t animate for more than five seconds at a time and then the animation has to stop.

Aaron Pearlman: That may not be relevant to what you’re doing, but it is moving. And those controls then need to be focusable most carousels have … A lot of fancy new ones. we’ll have menus that can come up when they get hovered over or focused on, just consider that all those controls need to be traversable, and then their very image heavy. A lot of carousels and slideshows need to be, so that you’re going to need to have proper alternative texts on them. Just the things that you would expect.

Aaron Pearlman: Off the top of my head, I don’t know of any fully accessible carousel that I can think of. But let me see if I can find a better example and I will try and pass it along through smashing and have that available if I can find it. It’s a great question because they come up a lot. I ended up tending to solve that problem in a slightly different way because I think they’re tricky, but that doesn’t mean that they can’t be done.

Scott: Rebecca is asking, “Can you give a use case for skip links?” And then similar early related, Patricia’s asking, “Do you know how to solve the issue with skip links in Safari plus the VoiceOver?” [crosstalk 00:38:18]. Again, maybe more technical than user experience related.

Aaron Pearlman: Yes. The second one, I’m not entirely sure what actually is going on that, that there may be an issue there. Again, I can try and see if that’s something that our developers have encountered before and how they’ve gotten around it. So we’ll make a note of that and I’ll try and circle back. But for the first one what’s a use case for Skip links? I want to avoid giant banner menus and I want to get straight to a sale that I heard that there is today and I don’t want to have to do that.

Aaron Pearlman: If I was a sighted a mouse only user, I would just visually ignore it and then go move my mouse over and just click on the sale item. If I’m a keyboard only ora assisted technology user, I would have to tab through all of that menu, potentially bunch of banner items as well before I could finally get to the workspace. that has maybe the sale items. So that would be a great use for a Skip link to get right to the content. Skip to main content is a phrase you see very, very common. Skip to main content.

Scott: Okay. That’s a good, good point. And I think in terms of all the user related questions from the attendees that covers them. We do have some general questions that we like to ask. So, low hanging fruit for people that are trying to build an accessible website. If somebody wants to put together a site in a few hours and make sure it’s accessible, what are some the easy things that just they can check off the list right away.

Aaron Pearlman: Sure. So some things that you can do immediately with any site or application that you’re working on, you can review your font choices for things like color contrast, there are plenty of color, if you put in color contrast, selector, picker or something like that, you’ll get it and you’ll just put it in the Hex value or the RGB value of what your font is and then what the background, whatever element the background color is sitting on and make sure that it’s meeting at 4.5 to one.

Aaron Pearlman: So that’s one that you can do immediately. Check your color Palette, you want to do color contrast where I see that color contrast fails a lot is when people use the endless shades of gray to have various levels of first class, second class, third class elements and things like that. Just make sure that if it’s an interactive element that it’s a passing color contrast.

Aaron Pearlman: Another thing, check your the images that are important, that are non decorative images. Make sure that they have all texts. Just one that you can add immediately. And then check your review, your heading structure, make sure that your h1 tags, h2 tags, h3 tags, h4 tags and so on. They all make sense with the structure of it and make sure that the content is properly paired with those heading tags.

Aaron Pearlman: That’s things that you can do immediately. And then also you can just, this is a small blog but you can download AX, that’s our accessibility engine. It’s totally free. It’s a little extension for chrome and Firefox and just hit the run button and see what you find. It’s a lot of things that you can help alleviate immediately or change immediately. You can also turn on VoiceOver, for example, if you’re on a Mac and start to go through your site and see what it sounds like for somebody who uses just a technology. It’s a great thing that we can do immediately.

Scott: Okay. Janat, has a question here. So what is it about accessibility that interests you and how did you know you’ve been doing design and UX for so long, but you’ve only been doing accessibility for smaller period of time, so that catch your attention?

Aaron Pearlman: It had been something that had been on the purview of some of the design that I had done in a later part of my design career till I got here. In my design career, I’ve always wanted to work on things that I felt in some way tried to make the world a slightly better place and I felt that working. And accessibility was one way to make … Very much believe in the core value of universal design or more importantly adapted design. Design that adapts itself to two different types of individuals to provide what we call GQ like digital equality. We want everyone to be able to use everything as best as we can possibly provide that universal experience that we can have. I don’t know as a person that very much appeals to me. And so it was just a good fit to learn design. That’s really cool.

Aaron Pearlman: Designing accessibly is a one way street. Like once you start to design accessible, you never don’t not design accessible anymore. It’s like UX designers don’t design unless you’re being tongue in cheek, you’re not going to design something to have a really poor user experience. It’s going to be part of your vernacular from that point forward. And once you begin to design accessibly, it never goes away. I can’t like not think about accessibility as I do designing and that’s a really, really cool thing.

Aaron Pearlman: It also affords you to start to think about things that you didn’t think you had access to. Like, did you know that your focus on your page, you can design focus to look differently for different elements on the page? That blew my mind when I found that out and I thought that was so cool that gave me a little bit more control, I knew you could create really cool Hover States, but I didn’t know focus was a state that you had full control over as well.

Scott: Our industry there’s always a new trend that’s just kind of how it goes, that’s the web. Are there any design trends right now that you know that are inhibiting accessibility? And if so, is there any recommendations you can make to avoid that?

Aaron Pearlman: I don’t know if there’s anything that’s super trendy right now when I look at different sites and web applications that couldn’t be designed excessively. I think there are pitfalls that that we’ve been falling into longer than any one trend as existed or at least has existed for some time. I just mentioned one, what I call the endless shades of gray. That’s one. In general, just being mindful of the contrast for your text. It is rampant.

Aaron Pearlman: It is by an order of magnitude, the most accessibility issues, if you were to like run an engine against it, like AX, it’ll be color contrast almost always. So just being really, really, really mindful of that regardless of where your text is on the page. Again, I mentioned it again, just being careful with your images. If you have an image that’s conveying important information to a sited user, that information needs to be conveyed to the user. That is user as well.

Aaron Pearlman: And what I mean by information that’s conveyed is if what’s being conveyed is that the person is doing something that’s, you wouldn’t necessarily describe it as a man standing. It could be that they’re playing baseball. Maybe that’s the important part. So make sure that the, that the, the alternative text matches with the intended information that’s trying to be conveyed, received out a lot too. Even when all texts is there, it just doesn’t accurately describe what is trying to be portrayed.

Aaron Pearlman: And then the other one too is progressive disclosure menus, many times you see on Hover Menus and stuff like that. They don’t do a great job of being evoked on focus as well. And they don’t always do a good job of … So that is a trend I do see. I do see a lot of menus coming up on Hover, when you hover over something you get the secondary menu that was hidden before that now finds itself to the front.

Aaron Pearlman: Also making that be able to Hover or a mechanism that allows you to evoke it and that will properly capture focus inside there so that you can use it. Those are a few things off the top of my head that I can say I would see a lot.

Aaron Pearlman: So as a graphic designer, you obviously work with development teams and a lot of the times when we’re doing wireframes and design of the onset of the project, they’re inherently not inaccessible. It doesn’t really become an issue, it seems until it comes to the development stage and people start taking that design and turning it into code. So how do you work with developers to make sure that the design that is being made from the start is going to be accessible when they’re done with it. Do you do audits throughout the process, at the end of the process? Like what’s the workflow with developers?

Aaron Pearlman: Sure. So the workflow for our development team is going to be, I think somewhat similar to a lot of other organizations. We work in scrum, so we work in sprints and scrum and I’ll go through a discovery process. They’re going to be privy to that, they’re not going to see it when the design is fully finished.

Aaron Pearlman: They’re going to see it throughout the design. I’ll have opportunities to talk with them a little bit about what the intent of the design is. They will probably set in on some of the user research that I’ve done, some of these ability testing that I’ve done. So, hopefully at that point nothing’s really new to them that I’m not going to get any 11th hour that we can’t even do this thing. I still have to deal with all the other things outside of accessibility that every other designer has to deal with, like is this feasible? Is it valuable? Is it all of those things that we have to deal with.

Aaron Pearlman: With regards specifically to accessibility, sometimes I will annotate the designs in a particular way that will indicate where tab focus should go. At the end of the slide deck that I have, there’s a great resource that one of the designers from Adobe put together. I know there’s like a pdf, there may be. There’s like a sketch file as well in there, there may be an XD file as well.

Aaron Pearlman: I don’t think, maybe just sketch. But it shows you like all of these different ways that you can annotate things like, accessible names, tab order and basically are little objects that you can place on your design to indicate some of those things as you go through. It’s a really, really wonderful resource. It’s all included in here as well. That’s a great way of saying, “Here’s part of my prototype and here’s the expected tab, order for it.” So that you have that as part of your artifact as part of the digital documentation or annotation that goes along with it.

Aaron Pearlman: So that’s one thing that we do is I annotate my designs pretty heavily. Everything from the size of how certain things are supposed to be to the Hex codes or RGBA values for what’s supposed to look like and feel like. But then also, there are accessibility annotations that you can add to it too.

Aaron Pearlman: And then just communicating, looking through the builds as they go through, making sure things like if you made any custom focuses that those custom focuses, look great, check the color contrast, make sure that it’s coming through, that the font choices that you’ve had there are some fonts that when their weight is higher and they’re bigger. Their color contrast it doesn’t have to be a 4.5. It can actually be a little bit lower, but you just going to want to just keep an eye on those things. Just as you would keep an eye on the experience stuff as well. You’re going to want to keep an eye on that stuff that you’ve been mindful for and annotated in your designs.

Scott: So we have a couple minutes left here. So I’ll ask one more question. Some people feel accessibility can stifle creativity throughout the design process. Is that something that you’ve come across? How do you think creativity fits into accessible design?

Aaron Pearlman: Sure. That was one of my initial reactions to having to design accessibly, was that somebody basically put the handcuffs on me and says, “There’s a much smaller box you have to be able to work in.” It’s true that designing accessibly means that there can be some more challenges because there’s more rules that you have to follow. But in the end, I found that the experience ends up being better and I haven’t … Once I removed that misnomer and began to do more and more accessible designs that were WCAG 2.0 AA accessible, I noticed that I can pretty much do everything that I wanted to do.

Aaron Pearlman: I would just need to sometimes express or solve problems in a slightly different way than I did before. I think a lot of people when they think about designing accessibly … I’ll give you a very specific example. When they think about designing accessibility they think, “Oh, well, I can’t do all of these fancy visualizations, for example. I’m not going to be able to do all of those things because they’re not going to be accessible, because if an individual can’t see them, I’m not going to be able to do that.”

Aaron Pearlman: I was designing a visualization that was just basic, just sort of line graph and under those, there was a line graph, on the x axis there was I think it was time and on the y axis it was usage or something like that. And there was this nice little gradient that went down from it and there was sort of these light lines that went behind it to delineate the months and time. And when I talked with one of my subject matter experts about making it accessible, it turned out I was sure he was just going to be like, “Nope.” But he said that there was actually just a few things that I needed to do to make this really nice looking graph accessible. One, that line at the top it need to pass color contrast because that’s actually what’s conveying the information of the trend over time.

Aaron Pearlman: The gradiated stuff underneath it’s just decoration and as long as it’s not interrupting the passing of color contrast of that and the y and x axis lines and ended up being okay. Those lines behind it were okay, but I ended up adding tick marks at the bottom there to indicate that. And then when I hovered and focused over, because sometimes you can hover over and it’ll add a dot to part of the line graph, just making sure that the dot itself would pass color. contrast. I did that by doing the sort of donut thing where you put a white dot with another dot or I should say has it like a large stroke on the outside of it as well.

Aaron Pearlman: And then I added a little bit of treatment in there that would bring the those lines that were faded back forward. And it all pass color contrast and ended up being fine. It was really pretty visualizations that passed. Now granted, I’m not getting into all of the accessible name stuff and being able to do that. Many libraries are on that. Put that aside, at least we call a contrast because is where I think a lot of designers struggle with. You can do it.

Aaron Pearlman: It’s just about being really mindful about those types of things, and getting more examples and just trying and trying different things, and having other people that you can pitch those ideas with and bounce them back and forth and checking again, just really do that. I don’t think it really inhibits anything. It just makes you have to think a little bit more clearer about how you’re going to do it and making sure that you’re looking through the lens of how an individual engaged with this if they had low vision, or if they couldn’t see it at all or couldn’t hear if you’re building a media application.

Scott: One more question, but I think we should’ve touched upon it. What stage in your process do you start thinking about accessibility? I’m going to assume throughout the whole process.

Aaron Pearlman: Yeah, it is throughout the whole process. I’ll be a little bit more rather than … I know who I say that and it sounds a little flippant. So, early on when you’re doing things like low fidelity prototyping, you’re going to be thinking about things like some tab order stuff. You’re going to be thinking about maybe headings and structure, things like that. Those are the type of accessibility stuff that you think about. Later on as it gets higher in fidelity, you’re going to be thinking about things more like, colors and your pallets that you’ve chosen, maybe accessible names, alternative text for anything that may merit that, you may be thinking about, if you’re doing any custom focuses, for example, that’s probably where you’re going to start to think about that.

Aaron Pearlman: It doesn’t mean that you couldn’t think about it when you’re doing low fidelity just means in general, when I go through my process those things tend to fall into those categories. You’re thinking about accessibility the whole time, but you’re not always thinking about everything with it as you’re in lower fidelity stuff, and you’re ideating, and you’re just thinking about ideas, and you’re just working through ideas, let that creative stuff go through as you become more attuned to accessibility, it will just sort of intrinsically make its way in and there’ll be less of a conscious thing.

Scott: Yeah. Fair enough. Well, on that note, we’ve run out of time, Aaron. Thank you very much for your time and—

Aaron Pearlman: That was great. I’ve had a wonderful time.

Scott: You’re going to be at the next couple of Smashing conferences, I think.

Aaron Pearlman: I will be at the one in New York. I’ll be at the one in New York.

Scott: Okay. And are you guys doing a workshop there?

Aaron Pearlman: Yes, we’re.

Scott: Okay. Awesome. Well thank you again for your time and just to let see the members that are still watching, we’ve two webinars next week. The first one is the Power of Digital People, with Kristina Podnar. And then we have a number three in our series with Andrew Clarke, Inspired Designs Decisions, number three inspired by Ernest Joural. Thank you very much everybody for attending today. And again, this recording will be available in dispatching membership panel once we’re done editing it and we hope to see you all next week. So thanks again Erin.

That’s A Wrap!

We kindly thank Smashing Members from the very bottom of our hearts for their continuous and kind support — and we can’t wait to host more webinars in the future.

We couldn’t be happier to welcome Aaron to our upcoming SmashingConf New York (October 15-16) — we’d love to see you there as well!

Please do let us know if you find this series of interviews useful, and whom you’d love us to interview, or what topics you’d like us to cover and we’ll get right to it.

(il)