Accessibility as Innovation - Life on mars #a11ymtl

[ Music ] >> Just like space exploration triggers innovation within the scientific community, accessibility can trigger innovation within the design community. And as we've seen already today that it has the power to transform your ideas and make you a more creative thinker when it comes to solving problems. I'm still trying to get my orientation right. But just like accessibility, space travel is hard work. We landed on the moon in 1969, and then since then, we've made steady, slow progress towards missions to Mars. But two-thirds of all of the mars missions end in failure. And so this year, we landed the Curiosity Rover on Mars successfully. And the real question is, what did it take to get us there, right? This is-- I don't know how many of you guys have heard of the YouTube video called 7 Minutes of Terror? Yeah. It's a fantastic video. It's really well done. I highly recommend you viewing it. It talks about all of the steps that were needed that the entire team had to go through in order to be able to successfully land the curioster-- I mean, Curiosity Rover on Mars. It's called 7 Minutes of Terror because there is a point in the landing process where they have a total blackout, and they have no control over what happens to this vehicle. And so they have all of these preparations that they've done, and then they cross their fingers, and they wait, and they hope and they're silenced for 7 minutes. There are six vehicle configurations that they have to go through in order to be able to land the rover, 76 pyrotechnic events, and over 500,000 lines of source code just to land it. Not to do anything past that, but just to land it. And there's zero margin of error. So, that's, you know, like a lot of the web projects that we work on, right? [Laughter] So to understand exactly a little bit better about what goes into a typical web project, I thought I would bring out Maslow's Hierarchy of Needs because I think it really models what web projects go through. But because we're all a bunch of geeks, we wouldn't be here if we weren't, I thought robot needs would make a lot more sense. So, at the bottom level of Maslow's Hierarchy of Robot Needs would be those physical needs. So for robots, it's eat robot food, whatever that might be. And it's just basic survival skills that people that are really looking at on that lowest base level. And then one step up, you're looking at your needs for safety. So the robot updates its antivirus software. And then one more level up, if you-- you've been able to succeed at those, then you look for your sense of belonging. So, for the robot, it would be vacuuming the living room. And if you're a little bit more skilled and you've worked a lot longer and harder, then you're able to aspire and get to this level of becoming self-aware as a robot, and it's really the self-esteem level from Maslow's Hierarchy of Needs. And then, of course, the tiny top level after you've succeeded all of these is what we would say self-actualization. And, of course, for robots, it's destroy humans, as we are all aware. And looking at that, you have to ask yourself how many robots have destroyed humans, so far, to date, none. And we acknowledge that this is a really aspirational goal, right? So this self-actualization, this idea of being at the top level of all of your needs is something that people aspire to but they rarely actually ever achieve. So if we look at this in the context of a web project, most of the time when you're looking at something and you look at your project plan for what you have to create, the goal is to create a web page, right? At the end of the day, your product owners, the project managers, if you're a UX or accessibility professional, or even a web developer, you're not measured by the quality of your work in big business, in large institutions, and in really rapid development cycles. You're measured by the fact that you actually lunched it, right? Did you actually get something out the door? So that's your survival level of most web projects. Then a smaller group of people are skilled enough, they've been able to accomplish this basic stuff, like, I have a 14-year-old daughter, she can launch a web page. So we know we can get that level. Then a smaller more skilled group of people are able to create a responsive, personalized experience. They think in terms of device independence. They think in terms of tablet. They think in terms of mobile. And so, then, at the higher level than that, you're looking at something that a few people actually ever achieve, a world class user experience, something that people find a pleasure to use, even a smaller group of people get to that level. And then if we take this again with the Maslow's Hierarchy of Needs, we're looking at this aspirational, self-actualized web page, right, which is a universally accessible experience. It's something that every single person can use, that it's a pleasure to use, that it's independent of all devices. And like Maslow's Hierarchy of Robot Needs, this rarely ever happens. It takes a small-- a really, really refined skill set in order to be able to accomplish this. And most web projects go the way of this in a chronology as well. So that by the time you get to the point when you're looking at those really, really finite skills, and someone would say, "You're gilding the lily," I don't know if that phrase translates, but you're gilding the lily, people are exhausted, they're out of time, they're out of budget. And so they rarely even look to the point of whether or not they can make something accessible. So when we were working on this really, really enormous project this year, we were taking 60 web page-- 60 websites, and consolidating them into a single website, in a year and a half. And we were going to be building a Fortune 100 company, E-commerce experience, a member portal, landing pages, multiple product offerings, as well as anything else that might actually a user would use in order to be able to find health insurance products or dental products or specialty benefits. And in doing that, we knew that we have this enormous mountain to climb, and it does actually look kind of like-- Adam presented about the mountains earlier, and it really does kind of look like a mountain to climb. So, we decided what if we flip it? What if we decide that an accessible user experience is the foundational element? It is the survival level. It is the absolute beginning to this web page process build. And so looking at that, we started with an accessible user experience. And we researched and got a highly skilled team, we jokingly call them Ninjas, and we brought them in to be able to really focus on creating the absolute most accessible experience we could. Then it became, we found relatively easier to create a responsive personalized experience of this device-independent, because when you put accessibility at the beginning of that, then the idea of something that's, you know, able to be on a tablet, or able to be responsive and you look at it on different devices, it's actually easier to do. We also recognized that if we had done those two things, it really lent itself towards a world class user experience. It was much easier even then to think in those terms because by the time you've created something that's universally accessible, and it's responsive, you're moving towards that idea of a world class user experience. So then, at the very end, the fundamental goal of every web project, right, is to launch those web pages. We were able to build awesome web pages. And because this was also the chronology of how we approach the web project, by the time when everyone was exhausted, and time was really a factor, then we were looking at building awesome web pages, and not trying to create something that's a foundational paradigm shift in how people viewed what that website should look like. So it was largely very successful. But it required that paradigm shift. So my question to you is this. This is a Lamborghini. When you think about Lamborghinis, and people think about that as sort of like an iconic, beautiful, beautiful car, is it the design of the car, because, honestly, this is not something I thought of when I'm Googling images to try and find a Lamborghini because I had my mind set on some other previous design of the car, some other model. Is it the design of the car or is it actually the engine inside the car that makes that car so iconic to people? And I would argue that it's really the engine inside the car that makes people think about a beautiful, fantastic piece of workmanship for a car. That the-- let me see if I can go back. The design of the car on the outside is really something that continues to bring it to that higher level. So when you're looking at it, this is our accessible user experience for a web page. And that when you get to the point when you are building, you know, an awesome web page, this is what you're actually doing. And so what we did was we challenged people to close their eyes, put down their mouse, and experience a well-designed web page. And it really, for a UX team, which is where we were focusing a lot of our efforts, it requires a really fundamental shift in how they view what they considered to be a world class user experience. And so we had to continually talk to them about the engine inside of the race car. And that, you know, my father owned an MG sports car when I was a child, and that thing was beautiful in the garage for 10 years growing up. It was beautiful. It could not run. He worked on it constantly. And was that something that I would make a point to go out and purchase as an adult? Absolutely not, because it didn't meet the actual foundational need of what you're using that vehicle for. So most of us know in the accessibility industry and when you're working in a corporation or organization in accessibility that it really is accessibility integrated into strategy, into design, into development, and into testing. The way to be successful in any web project is you must have it on all four of those levels otherwise something is going to fall through. So, the purposes of what we are talking about right now, this is primarily focused on the design elements. But we could break it down even further and say that you have to integrate accessibility into each step of that design process. So when you're discussing information architecture and you're thinking about the structure of your navigation and you're imagining how people have their mental models and you're doing card sorting exercises, you need to pull accessibility into that conversation, as not just a stakeholder but a driver for those decisions. Because of that, you won't probably then be as likely to have 18 layers of navigation that don't necessarily communicate with one another, and that later you find that they are, you know, really unsustainable because they become these mammoth beasts of difficult, you know, navigational levels. Usability testing has often been a challenge for people to bring in people with disabilities. And yet, if you start thinking in terms of Low-Fidelity Usability Testing and bringing in those users who our low vision, and cognitive disabilities, and senior citizens are great for being able to pull that in, then you can start at the very beginning of the usability testing process and be able to really think in terms of what all users need from that particular set of web pages. Again, interaction design, that's very-- I mean, that was probably the heart of what we worked with, was trying to explain to people how-- that they needed to define the design intent. So if you're going to have something shift visibly on the page because of something a user has interacted with, that that, too, needs to be something that's communicated in a non-visual way and in multiple ways all over the page. Content strategy was another piece of that. We really aimed high to try and deal with people who have cognitive disabilities, and especially given the aging population in the United States, okay? I don't know if you guys are familiar with the term that's called Silver Tsunami. It just basically means there is a wave of senior citizens that are going to be hitting our digital spaces. And that group of senior citizens, they're completely different in personality types than those that we, you know, serve today. Today, my mother would say, "Well, you know, this particular web page experience is bad. It must be my fault. I must not know how to use my device," right? Because she's relatively new to technology. But this Silver Tsunami is a group of baby boomers who have a sense of entitlement and they expect these web pages to work for them. They expect things to be the same way that they would have experienced it 10 years before. So if they age into disabilities, then it's our fault that we haven't accommodated that. And so recognizing that in a content strategy way, in an interaction design way, visual design, usability testing and really accounting for that is a big piece of, I think, a really good motivator for design teams to consider. So I'm going to show three different examples of ways that we incorporated accessibility, and it actually changed our design patterns. I have to catch up on my other one. There we go. So what I have on the screen is an example of error messaging. And I think that this is a really foundational element of providing an accessible experience to people. A usable experience to people is how they recover from making mistakes on your website. That's obviously pretty foundational. So, our goal-- our fundamental goal was to meet the user's need at that time of need, right? And looking at that, we have-- you can't see it on this because it's just a screenshot. The page title, when a user creates an error on this page, the page title actually changes to, say, "Error." There's a lot of assistive technology that really relies on that page title. It gives someone a grounded sense of where they are and what's happened on the page. Another thing is, and this is pretty basic, that we have really solid heading structures so that someone is able to navigate looking at the headings on the page. We also have judicious and sparing use of field sets and legends, and that's mostly because we had a lot of different web development teams and we needed to know that whatever recommendation we made was something that could be globally applied without a lot of hand holding for teams to sit there and be able to, you know, make judgment calls because then it would kind of splinter. We have consistent interactions. Consistency is a big piece within usability. It's, I would say, probably, a critical piece within error messaging and recovery from error messaging. So looking at this page, you'll see that there is a summary bucket up at the top. And what it does is we have an icon as an image, and shows the following, and it has a number, "Three items require your attention," and that's a heading. And then underneath that, we have a bulleted list with the list of errors that were-- that occurred on the page. And then something that made-- that's pretty common. That's not that uncommon, but something that's a little bit unique to this particular experience is that all of these things that are errors were actually on page hyperlinks that will take the user directly to that error to be able to correct the mistake. And then, again, we have another item that says, "Skip to the next item using this down arrow icon." And we were trying to be really sensitive to people who struggle with a lot of tab navigation. Keyboard users who have to get from one side of an, you know, of a form that they've created an error on all the way down to another side of that form where they've had their next error. So this allows them multiple ways to be able to navigate really easily and have those errors get corrected at their own measure. So by creating a method for displaying errors, it takes into account memory-related issues. This is something that really-- we talked about consistent user experience. We reduced the frustration and confusion for all users. This tested really well on our usability testing. We had a group of low-vision users and a group of seniors and a group of non-native English speakers. And so to us, that's kind of like the trifecta of knowing that you've really hit the mark when it comes to something that's understandable for users, when they've never seen and experienced before and they're able to really understand where they're on the page, what they need to do in order to be able to move forward for the next piece of what they're doing. So Derek referenced this earlier. This is something-- I think it's a very cool, exciting thing because at Humana we had a flash map which, I know, you can boo all you like. We had a map that we knew was really outdated for being able to support iOS devices, and just in general, we knew that it wasn't really responsive. Our goal was to create as many responsive web experiences as possible. And so we looked to the team and we said, "What can we do that's not just a client-side image map or, you know, different ways to be able to accomplish this? What can we do that really pushes the bar forward for even just web technology?" And so they created this SVG map, and some of the beautiful things about this, one is that at the top of the source order in this area is that you have this drop down menu. So you have something automatically available to users should they not want to experience and navigate through with the largely visual experience. It allows them, too, if they don't have a device that supports SVG, then this goes away and they have that drop down menu. And so it's a very simple interface for those who don't have devices that support SVG. Then the other thing that was really wonderful I think about this particular map is that-- and this is not something I thought about because, normally, I'm thinking about when you select your state in the United States, it's in alphabetical listing. So it didn't occur to me, and this is why we have the ninjas on our team, it didn't occur to me that that might actually not translate as far as tab stops when you get to a visual map. People don't think in terms of listing their states when they're looking at a map of the United States in an alphabetical manner. They're thinking about it geographically into chunks of where they are on that page. So if you tab through the actual map, you're going to be tabbing from like west coast states, midwest states, east coast states. And then if you see, we have a lot of really tiny states up on the northeast. And for people who are trying to use a mouse and it's really difficult for them, they might have tremors, it's really difficult to be able to split apart all of those and create a large enough hit target for people to be able to get to that. And so we have these squares on the side that light up as well whenever someone tabs over these smaller states as a confirmation as to what states they're on but also these are also something-- these little squares are big enough for someone to be able to click on to select their state. So this can be used without a mouse. It's an easy used tool and it's badass web development. It's very cool because it's future forward, and it shows and it positions accessibility squarely in the middle of saying that we are the ones who are creating innovative solutions because it really debunks that myth that accessibility makes a broken or simplistic user experience. It does quite the opposite. It challenges design teams to move forward on their thinking by telling them that you need to think about all the users and not just some users. And so it actually, as we know, it's an advanced level of user experience, and this was one of those examples that we were able to provide. So then the last one that I'm going to talk about is something that relates to these "skip to main content," skip nav links. So how many of you guys are familiar with the Section 508 Compliance in the United States but also AODA that you have to skip repetitive links on a web page. So this concept came out several years ago obviously, and it was meant to solve the need that users had when they would go to a web page and they would see repetitive layers of navigational links. And so if you're a screen-reader user, or even a sighted-keyboard user, what you want to do is you don't want to have to go through all of those different links every time you're navigating through a website. You should really only you have to experience it one time, right? The problem is, the way it's been implemented pretty commonly is a "skip to main content" link. So if you go to the top of a page-- and this is a successful implementation, don't get me wrong, but the problem-- the problem is it's not a consistent implementation and it doesn't really solve all of the needs out there. So if you go to the top of a web page and you will either see it visible on page load or if you tab into it, you'll see "skip to main content." And that link will take you to the body of the page and it'll bypass all of those repetitive links. But where does it really take you? There's no consistent place that anyone really has confidence that it will land them maybe on the navigation that's the side navigation. Maybe it will take them to the heading one element, maybe not. Additionally, people often implement it incorrectly or they rely on JavaScript to be able to do that, and so it doesn't degrade well. There's lots of problems with this one link, but the biggest problem with it is it really doesn't skip repetitive links, it skips one set of repetitive links, just that one top, main navigational menu. So when we were looking at this, we were trying to figure out a way that we could skip all repetitive links, and then we thought about how many skipped links there would be on a page then. For really a large company website, that could be as many as 10 on a page, and it's really a cluttered kind of experience. It's also not really scalable, something you can maintain if you have a dynamic website that has "display this at, you know, runtime," and it's very modular in how it puts things together. And so looking at that, we drew a picture of rolling the dice. I don't know if you guys have used that Urbanspoon mobile app, but you shake it and it makes kind of that dice roll, and that's what we're giving the user. Skip to good luck, you know? And then it was like a roulette game for people, and we're like "Okay, well, that doesn't solve the problem." And so we thought, "What if what we did was something that was actually much simpler and met the needs of all users?" So, basically, what VoiceSaver has done is, when you tab into it, you see table of contents. Instead of the "skip to main" content link, you see table of contents. And what that's doing is it's dynamically pulling all of the headings from that page and putting them into a very easy to understand list of what the content sections are on that page. So if you do your content strategy and your information architecture correctly, you should have headings on your page. They should accurately represent the content that's below it. And in doing that, it allows the user to have what screen-reader users typically already have which is a headings list. And yet, sighted keyboard users are able to benefit from this as well because then they are able to see, here are the sections on the page. We've made the headings tab focusable, and in doing that, somebody is able to then-- [Inaudible Remark] I'm just going to let it play. And so you can scroll down, you choose a selection, and then it takes you to that heading. And so the benefit of that again is that really thinks about all users in a much more universal context, but nobody is really using this very much, and that was what was surprising to us. So by listing these content sections at the beginning of each page, it's a quick a review for anyone. It also helps with anyone who just really wants to get a snapshot of what the page list for them. And it's an easy to use mechanism, and it does things more than just the simple compliance oriented fix that we typically look at sometimes in accessibility. So the benefit of this, too, is that all of this time we've been talking about things that allow a user to have an easy and pleasurable experience with web pages, but that's just the beginning, right? We've just really been primarily talking about access, and so the real question that I'm kind of posing to you guys today is, if we get to this place where we can be innovative in a way that people can access our websites, then what next? What do we want them to engage with? How do we want users to interact with our content and to get the most out of our content beyond just getting them there, right? So we landed the Curiosity Rover on Mars, now what? There's a lot left to do. That was just the one, hard step to get there, and that's not actually the final mission. There's a whole lot more in that that you can do. So, that's all I have for you today and I really appreciate your time, and I know that I was running up against lunch, so I was trying to be cognizant of that. Here's all of my information, all my-- all my stuff. Thanks very much. I appreciate it. [Applause] [ Music ]