Designing for Accessibility with Accessibility in Mind

All right. Hi everybody. My name is Jenny Lanier and we've got Stephen Raden and Janelle Arita on the line. We work together at IBM and now Stephen is part of the Cloudflare team. But before he joined the team, we worked together on this project for about a year and we're very excited to share with you this story. So this is the idea of designing for accessibility with accessibility in mind. Next slide. So that was a very brief photo of the three of us during our time at IBM. We were fortunate enough to work on the same team. And now we've been able to continue to work together to share this story as we've kind of gone our separate paths. Next slide. So this is a pretty complicated table. It's something that appears often in IBM products, particularly infrastructure management pages, which is the team that Stephen, Janelle and I worked on. These tables have a lot of really intricate data. And at the time that we created these designs, the component for editing tables was to use inline or the pattern for editing in tables was to use inline editing. And the tricky part about that was each input has a series of dependent inputs to determine what appears in this table. Now, if you think that sounds kind of complicated, it is. And imagine what it's like when the only way you can navigate this information is through sound. So next slide. So this is an example of what those tables look like in that editing interaction. And it's quite a bit of information to navigate visually and even more overwhelming to navigate just with verbal cues. Next slide. So people who have vision impairments use something called JAWS to engage with websites, web applications, software, all sorts of things on the computer. And it stands for job access with speech. So it's basically a program that reads out what we see on the screen. This is an example of what engaging with JAWS sounds like. This is a coworker, Randy, who gave us a little demo so we could understand what it's like to use JAWS on a daily basis. This is a standard Windows laptop. To my right is a Braille display here. And I'm going to first run JAWS at the speed I listen to it, which you won't be able to understand, but it's just a demonstration. So JAWS, options, choices, suggestions. So the entire exchange was what you're seeing on the screen now. Just a series of eight Slack messages back and forth. Now imagine using that high speed voice that's very robotic to read incredibly detailed information to you that you have to internalize and digest on the spot. That wouldn't be very pleasant for a lot of us. And we were pretty impressed that that's what Randy uses on a daily basis. And as you noticed in the video, he slowed it down to 30% of its actual speed. So it's pretty overwhelming. Now, again, take what you just heard for that very simple Slack exchange and imagine what it's like to have that voice read out all of this information to you, not only just to understand what the table is showing, but to actually edit what's in the table. So when we ended up sharing these designs with Randy, we were able to uncover some accessibility issues. Editing tables using inline editing actually presents several accessibility concerns. We needed to use a lot of ARIA tags to compensate for some of those accessibility issues and just reading information required a lot of steps. So by the time this design was ready for Randy to engage with, we were understanding that there were some accessibility problems that it was almost too late to address because JAWS has to have your designs coded in order to engage with them. So by the time these designs were coded and Randy was pointing out these issues to us, it was almost too late to make a difference or to make a market difference. Now, let's back it up a little bit and talk about what does it exactly mean to be accessible. Accessibility, as we're defining it, is the ability of everyone, regardless of disability or impairment, to have access to something. And that's not just technical access, but equal access. And accessibility is really important to not just IBM, but most software companies and it should be important to every software company. To be accessible means that you can save your company time and money by solving these issues before development team puts designs into code. You can also provide for a better user experience for those who live with vision impairments and that can target current users or it can be an attraction point for potential users. Also, for IBM at least, it helps us secure a lot of government contracts because they require a certain level of accessibility compliance. So there are very business bottom line reasons to be accessible, but also very human reasons to be accessible. So we've talked a little bit about Randy and I wanted to go in a little bit more to discuss who Randy is and what his relationship is to our team. So he's a development manager and he happens to have a vision impairment. But accessibility isn't his primary concern at work. It's just something that is part of his life. Now he's taken on accessibility to help affect change in our products, but that's kind of an added bonus for his passions at work. So as I discussed earlier, by the time Randy was able to give us feedback on our designs, it was too late because, or it was almost too late because our products needed to be coded for him to use JAWS. And then by the time they were coded, there was this huge investment in work that presented a barrier to overcome in terms of making changes because our dev teams were thinking, we worked so hard on doing this and now we need to change it completely. And that can present kind of a paradox or a conundrum for making sure your designs are accessible and also being an efficient or utilizing your development resources efficiently. So this is just to refresh. This was the design that we wanted to work on to make more accessible. And in order to do that, we realized we needed to address the issue of kind of what comes first, design or coding to check accessibility. So in order to do this, we utilized some of our training in IBM design thinking and we could speak at length about what design thinking is, but we will consolidate it and its tenants onto one slide for the purpose of this presentation. Basically, design thinking says you need to focus on users and their needs. Everything should be treated as a prototype. Nothing is finished. Everything's iterative and you're always improving based on what customers and users are saying about your products. It also encourages co-creating with diverse teams. So not designing in an echo chamber or in a silo, but understanding other people's viewpoints and experiences. We use this loop to help guide and anchor our design processes. So we start by observing problems and then we reflect on what our observations are telling us and then make design decisions to address both observations and reflections. And after we make something, we go back and reflect on what we've made, reflect on people's reactions or uses of our products, and then continue that loop to keep iterating and improving on our products. So through design thinking, we created this problem statement. How can we better incorporate accessibility into the design process so we can enable teammates with visual impairments to provide actionable feedback earlier in the process? And this was part of our observe part of the loop. All right, now I'll pass it on to Stephen, who's going to talk to you about who we're designing for. Hey everyone. Yeah, so in order to kind of continue and make sure that we're observing and working with the correct people, we generated some personas. The first off, which is actually based on Randy, is Martin, the developer manager. For clarity, he's got a development background and he works with a team of developers for a company that we're calling Cloudland, which is a cloud computing company. He lives with a visual impairment and has for most of his life, and is ultimately assisted by a guide dog day to day. His primary roles are to be a developer manager. He is not hired for the benefits, you know, he can bring a company as an accessibility advocate. So it's not as primary responsibility as anything he does is, you know, regarding that as extra. But then he also uses screen readers to be able to work with his team and to work with design teams and iterate. That's his primary, at least when working with computers, interaction point. Then there's Desi, the designer. So she is a user experience designer at Cloudland, works with Randy, and her primary kind of means of building is through creating wireframes or using tools like Envision to create prototypes and explain the interactions and flow that we want our users to have. And the thing is that those prototypes are often kind of images with hotspots on them, and so they're not able to really be read by a screen reader. And then there's Tanya. She's a front-end developer at Cloudland. She works closely with Desi, the designer, and is the one who essentially takes those visions and ideas and puts them into code and builds them and makes them real. And, you know, her primary concerns are to be building this to the best of her ability, make sure it's accurate to designs, make sure it doesn't fall apart at the stick wind. So from there, and now that we know the kind of personas that we have, we worked with those to create an as-is. And so this is a bit of the flow that at least we had at IBM. The project comes along and Desi, the designer, iterates on some designs and collaborates with this kind of design team or development team that is actually implementing them. And they go back and forth a few times, implementing and updating and working on the flow before it goes into its final state. Which is where the development team and the designers all feel that it's good enough and that this is where we want to go, so let's actually put the effort into building it. At this point, you know, a few weeks to months may have gone by depending on the difficulty and complexity of the project. And it's at this point that they take this project in a, as real estate as it is, to Martin. And he, now that it's built and coded, is able to see it as he sees things on the Internet via screen reader. And in this case, he notices some issues with it. The issue with that is months have already gone by, work's already done, things have to be shipped. So it is actually missed. And so you can see some pain points here. First of all, the biggest and most forefront in our minds is that Martin, as someone who has valuable feedback, especially around accessibility, cannot give that feedback until later stages of development. Meaning his input often goes unaddressed or gets put in the backlog for post-release. Desi, the designer, you know, she's wanting to build a product that is as best as it can possibly be, but ultimately in the medium that they work, that she works in, cannot get Martin's feedback on accessibility very well without a significant amount of verbose just explaining what's on, you know, what's the image on the screen. And realizes that she has to have designs coded before, you know, he can use his medium of interaction to understand them. And then the development team, they have to spend a significant amount of time refactoring designs and refactoring the development and the code after the fact. Because, you know, they were happy to solve things and it would have been much easier solving things up front had they known it was an issue, but they just weren't able to know because of the interactions between Desi and Martin. And so our goal, again, to reiterate, is just engage, we want to enable people with particularly visual impairments and other impairments to be able to engage with their wireframes before they ever become live code. And so we started down the journey of research and we looked at other competitors and a few other kind of areas of research and we want to try and find tools that maybe we as designers can work in that would enable us to be able to get someone like Martin's feedback early on. And so we looked at coding, you know, could we use our component library to really quickly and easily do this. And, you know, it would have taken a lot of extra time, we would have been doing a lot of development and it was a very, very difficult task that would have eaten up most of our workload. And then there are also tools online that, you know, maybe a Chrome plugin or something like that, that allows us to at least see some things, but a lot of accessibility related things are just around contrast and colorblind simulations and, you know, labeling images with alt text. And again, there's a lot of resources out there as well that help describe what you should do and how, but, you know, we follow these to the best of our ability, but when it comes to a multi -level, multi-step flow, those don't always work super well or don't help, you know, explain how to handle those. And then for design tools, which is what we're familiar with, there are plugins, but again, those are often limited to contrast and color checkers. So we started looking as the software kind of route failed us a little bit, we started looking at a physical space. We looked at three printers and embossers and we're wondering, can these things do our designs in a physical medium that someone like Martin can interact with? And there were complications, one being expense, two being time. You know, this is going to be using a whole other tool, a whole other layer, and it takes time to even print these things out, and so they didn't seem super viable. One thing we did find, though, was the Raise Line Drawing Kit, and this was a tool that actually allows for someone to essentially draw in a 3D or more tactile way, and we'll tell you how this comes into play later. So essentially, again, back to our statement, is enable users to iterate quickly. Another aspect of this is that we want to make sure that one of our personas, the designer, is enabled to work quickly with this, and that's necessary for them to do their job on a day-to-day basis. So we have that statement of enable users to iterate quickly in a tactile, accessible medium. And so we went into kind of material exploration as we determined that we're going this physical route. And as any good kind of crafts or physical medium project is, we started out with a place like Michael's, and we walked pretty much through those aisles and felt and touched different materials to see what about them was easy to differentiate, what about them could we tell apart. And we collected a bunch of material, from foam to tapes to rubber material to hot glue. And we put those together, we diverged at this point, which is part of the process, and tested those in different ways. You know, design representations that are simplified versus things that were more exact versus actually using some Braille tape to label things on the page. And we got Randy's feedback. And this is a picture of that raised line drawing kit. You can see how we put a design under it, and then you could draw over it, and Randy was actually able to tell these small plastic raises and bumps as different parts of the page. This is him, you can see him using it here. And overall, our takeaways from that is that foam shapes, hot glue, felt, texture tape were all really easy for him to understand and to use on a larger scale page, and they could communicate interactions if you put multiple of them together and layer them. And then the raised line drawing pad was actually really great for doing things on the fly, but also for doing more precise, you know, pixel perfect interactions. And so our next step was, how can we make these things reusable? How can we make them faster? As we found that the materials themselves were good, and this is where I'm actually going to hand it off to our next guest, Janelle. So I'll carry on with our second phase of our process of creating a pattern library. So after testing the various materials from the first phase, we ended up with many diverging tactile patterns between the three of us. So the next step that we wanted to focus on was to converge our designs and find a way to have the same language and understanding. So this brought us to Carbon. Carbon is our design system within IBM. And we weren't looking to reinvent a design system, but instead wanting to build upon an existing system that worked successfully within our teams. So think of Carbon as our digital design system, and us looking to build on top of Carbon with a tactile design system. We wanted to utilize their design system to create a shared vocabulary and common tactile components and tactile guidelines. So this image here, this was one of our first iterations of the legend, which represented that pattern library. As you can see, the legend guided us to help keep consistency among our designs while putting together full tactile wireframe pages. And as we built the legend, we focused on trying to match similar texture material for similar components. So like the text input and the slight drop down, those were more of the same rough texture. And to contrast it for the navigation, we used a softer felt texture. So bringing it back to our complex tables within our infrastructure products, we wanted to also keep in mind the complexities when applying our pattern library. And just to glance over some of the complexities within our products, we had to think of things of add, edit, delete patterns, use of cascading actions to scale. And then also patterns that exist within models or within pages and data table inline edits. So we really wanted to put it to the test, and we tested the pattern library with Randy to see how he identified the components amongst each other. Here, we sat with him. This is a picture of Jenny sharing one of the tactile wireframe designs and verbalized as he felt his fingers across the page what he was feeling and the different components. So the takeaways from this round of creating a pattern library, it made it easier for us to quickly create the components. Since there's a shared understanding between three of us as designers, and likewise that helped Randy to better consume the pages as he felt because there was a shared language. The next steps following this phase was to create this kit to be reusable and also to test out the designs with the further development team. So looking at phase three of using the kit. Next slide. We wanted to focus on making this kit more scalable. So this image, this image was actually from the previous phase and just to call out from the tactile wireframe here you can see that we have pieces glued on with hot glue gun also taped on. So this made it really a one time use of the wireframe. And in order to scale, we wanted to find ways to make it reusable to help make it more quickly in terms of time and money to build. So the first thing we had to do was look at a new material to replace the glue and the tape. And we looked at Velcro as an exploration and eventually ended up with magnets. We tested out different types of magnets for its strength and different shapes. And one of the good things about using this material is that we have whiteboards readily accessible within our design studio. After finding a good type of magnet strength and shape, we then applied our different textures that were successful from the previous rounds and built together a new kit. So here's what our kit mostly looks like today. It's still definitely a work in progress and where the team is continuing to add materials as a kit grows and we find further needs. We also built out a legend for Randy, our visually impaired dev manager to also follow along with the kits and understand through the use of Braille. So to test our newest kit, we applied it again to our complex tables. And at this point, we had a new design pattern, the use of a side panel to replace some of those complex inline editing. So one of the designers, Michelle Yang, on the team, she was working on that new side panel and she used the kit to quickly, in tandem, to share the designs with Randy, a dev manager, and also share the digital designs with two other sightseeing devs in the room. And so how we had the room set up, Michelle shared the designs digitally with the sightseeing devs and also on the spot built out the tactile wireframe, the same designs, with Randy on the whiteboard. And as for reference, you can see that the whiteboard already has, it's already been used, but something that was just available within the room and Michelle was able to easily put together these designs in, I'd say, less than a minute, really, a few seconds to walk through the designs with Randy, so he was able to follow along. And Randy was really excited to be able to follow along with this design review to the greater dev team. He gave a quote of, I feel like I'm finally able to give useful feedback. And that is our goal that we wanted from day one. We wanted to make sure to include Randy's feedback early in the process so we could address it earlier rather than later. And Randy was a stakeholder, someone whose feedback we cherish greatly as an accessibility expert and also as a dev manager on our team. So it was really good to see here that comment from Randy. So to call out some of the feedback from the table session is really just to identify accessibility comments, along with layout of the pages or general design patterns from his technical perspective. We also tested out another set of designs that looked at two options of enabling or disabling a major call to action button for an order summary and this design pattern allow the ability, you can skip to the next, this design pattern allow the ability to create a new component for a kit of a disabled or enabled state. But a large takeaway from this feedback session with Randy was we learned as designers that screen readers tend to skip over disabled buttons and so that really impacted the accessibility of our designs through the feedback from Randy, who is our accessibility expert. So the large takeaways from this phase of using a reusable kit was, or just generally the entire process and the kit itself was allowing Randy to feel empowered to provide feedback earlier in the process. Again, our entire goal of this entire project. The kit itself was more sustainable and quicker to put together on the fly within, I'd say about 10 seconds or so. And the whiteboard was material that we had readily accessible within the office. So that leads to where do we go from here. If you go to the next slide. So I'd say there's two parts to this question. The first part, pre-COVID, we've shared this talk at multiple conferences, design and accessibility conferences. So we're trying to spread the word with other companies, help make other teams more accessible within their own designs. We've had other teams within IBM take the kit and bring accessibility to their products. And we've had an accessibility team with IBM really interested in this project and scaling it out to the greater company. Additionally, we are COVID right now, which makes having the kit in person really tough. And during this difficult time of being socially distanced with one another. So we are still looking for ideas of making this more readily available for virtual interactions or making it digital. So, so one of the challenges that we face right now during COVID. Well, I think that is our time slot. Thanks everyone for watching and talk to you later.