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 I'm going to run JAWS at the speed I listen to it. So I'm going to run JAWS at the speed I listen to it. So I'm going to run JAWS at the speed I listen to it. So I'm going to run JAWS at the speed I listen to it. So I'm going to run JAWS at the speed I listen to it. So I'm going to run JAWS at the speed I listen to it. So I'm going to run JAWS at the speed I listen to it. So I'm going to run JAWS at the speed I listen to it. So I'm going to run JAWS at the speed I listen to it. So I'm going to run JAWS at the speed I listen to it. So I'm going to run JAWS at the speed I listen to it. So I'm going to run JAWS at the speed I listen to it. So I'm going to run JAWS at the speed I listen to it. So I'm going to run JAWS at the speed I listen to it. So I'm going to run JAWS at the speed I listen to it. So I'm going to run JAWS at the speed I listen to it. So I'm going to run JAWS at the speed I listen to it. So I'm going to run JAWS at the speed I listen to it. So I'm going to run JAWS at the speed I listen to it. So I'm going to run JAWS at the speed I listen to it. So I'm going to run JAWS at the speed I listen to it. And then now I'm going to expand some of the data on what's available in the table. So when we ended up sharing this, in for videos 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 to compensate for some of those accessibility issues and just reading information required a lot of steps. So by the time this design was was ready for Randy to engage with it was 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 bottom 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 also 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 inefficient 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 tenets 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 is 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 this of our products and then continue that loop to keep iterating and improving on our products. And 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 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 InVision 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 hot spots 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 and is the one who essentially takes those visions and ideas and puts them into code and builds 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's you know doesn't doesn't fall apart at the you know a 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 and working on the the flow before it goes into its final state which is where the development team and the designers all feel that it's 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 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 he in this case he notices some issues with it but 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 and most you know 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 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 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 wire front 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 wanted to try and find tools that maybe we as designers could 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 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 that you know maybe a chrome plugin or something like that 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 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 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 he can 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 another tool a whole another 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 raised 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 sorry 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 and that's necessary for them to do their job on a day-to-day basis so we have that same mode enable users to iterate quickly in a tactile accessible medium and so we went to 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 uh we started out with a had a place like michael's and we walked pretty much through those aisles and felt and touched different materials to see what what about them was easy to differentiate what about them could we tell you know 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 um and this is a picture of that uh raised line drawing kit you can see how we put a design under it and and then put and then you could draw over it and he 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 shape tape were all really easy for him to understand and to use on a larger scale page and 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 for doing things on the fly but also for doing more precise you know pixel perfect interactions and so our next step uh was how can we make these things reusable how can we make them faster uh as we found that the materials themselves were good and this is where i'm actually going to hand it off to uh our next guest janelle oh so i'll carry it carry on with our second phase of our process of creating a pattern library um 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 language and understanding so this brought us to carbon um 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 we're us looking to build on top of carbon with a tactile design system um we wanted to utilize um their design system to create a shared vocabulary and common tactile components and tactile guidelines so this image here um this was one of our first iterations of the legend which represented that pattern library um as you can see uh the legend guided us to help keep consistency among our designs while putting together full tactile wireframe pages and as we build the legend we focused on trying to match similar texture material for similar components so like the text input and the select drop down those were more of the same rough texture and to contrast it for the navigation we used a softer felt texture um 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 um use of cascading actions to scale and then also patterns that exist within models or within pages and data table inline edits um so we really wanted to put it to a test and um we tested the pattern library with randy to see how he identified the components amongst each other here um we sat with him this is picture of jenny uh sharing one of the tactile wireframe designs and uh verbalized as he felt his fingers across the page what he was feeling and the different components um so the takeaways from this round of creating a pattern library uh it made us it made it easier for us to quickly create the components um since there's a shared understanding between three of us as designers and likewise that helped randy to better consume um the pages as he felt because there was a shared language the next steps following this phase was to create um 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 um next slide that's good we wanted to focus on making this kit more scalable so this image uh this image was actually from the previous phase and just to call out um from the tactile wireframe here you can see that we have pieces glued on with hot glue glue gun um on 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 quickly more quickly uh 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 um we tested out different types of magnets uh for its strength and different shapes um and one of the good things about using this material was that we had whiteboards readily accessible within our design studio um 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 um so here's what our kit mostly looks like today it's still definitely a work in progress and we're um the team is continuing to add materials as uh they're as a kit grows and we find further needs um we also built out um a legend for uh randy our visually impaired dev manager to um also follow along with the kits and uh understand through the use of braille um so to test our newest kit we applied it again to our complex tables and at this point we had a new design pattern um the use of a side panel to replace um some of those complex inline editing um so one of the designers michelle yang on the team she was working on that new side panel and she used the kit um to quickly in tandem to share the designs with randy a dev manager and also shared the digital designs with two other sightseeing devs in the room um and so how we had the room set up uh michelle shared the designs digitally with the sightseeing devs and also on the spot built out um the tactile wireframe the same designs with randy on the and as for reference you can see that the whiteboard already has uh it's already been used um but something that was just available within the room and michelle was able to easily put together uh these designs in i'd say less than a minute really um a few seconds uh to walk through the designs with randy so he was able to follow along um and randy was really excited to be able to follow along with this design review to the greater dev team uh his he gave a quote of i feel like i'm finally able to give useful feedback and that is um our goal that we wanted from day one we wanted to make sure to include randy's feedback earlier in the process so we could address it um earlier rather than later and randy was a stakeholder someone whose feedback we cherish greatly um as accessibility expertise expert and also um as a dev manager on our team so we're really it's really good to see here uh that comment from randy um so to call it some of the feedback from the table session um is really just to identify accessibility comments um along with layout of the pages or general design um patterns from his technical perspective um we also tested out um another set of designs that looked at um two options of enabling or disabling a major call to action button for an order summary and this design pattern um allowed the ability you can skip to the next this design pattern allow the ability uh to create um a new uh component for a kit of a disabled or enabled state um but a large takeaway from this feedback session with randy was uh we learned as designers that screen readers tend to skip over disabled buttons and so that really impacted um the accessibility of our designs through uh the feedback from randy who is our accessibility expert um so the large takeaways from this phase of um using a reusable kit was or just generally the entire process and the kit itself was allowed randy to feel empowered to provide feedback earlier in the process again our entire goal of this entire project um the kit itself uh was more sustainable um quicker to eat to put together in the fly and on the fly within i'd say about 10 seconds or so um and the whiteboard was the material that we had readily accessible within the office so um that leads to where do we go from here um if you go to the next slide so i'd say there's two parts to this question uh the first part um pre-covid um we we've shared this talk uh multiple places multiple conferences design and accessibility conferences um so we're trying to spread the word with other companies um help make other teams more accessible within their own designs um we've had other teams within ibm take the kit and bring accessibility to their products um and we've had an accessibility team with ibm really interested in this project and scaling it out to the greater company um additionally uh we are covered right now which makes um having the kit in person really tough um and during this difficult time of being socially distanced with one another um so we are still looking for ideas of making this more readily available for um virtual um interactions or making it digital so so one of the challenges that we face right now during covid okay well i think that is our time slot um thanks everyone for watching and talk to you later