![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
amazonvAccessibility Libraries: How Design Can Start the A11y Conversation Early
Type: Breakout
Track: Design
Often accessibility is overlooked till the last minute, requiring more effort and time to find, report, and remediate problems. By creating a shared library of accessibility specs, designers can avoid creating inaccessible products from the start and build awareness of accessibility within UX and their broader organization. This talk will cover why you should use an accessibility library, what teams at Indeed are using, and how it’s impacted conversations about accessibility across the company.
CART provider is standing by.
>> If you require captions, they are below the video. If they are distracting to you for any reason, use scrolling to manage whether they are in your view or not. The session will be recorded. And the accessible PDF version of the presentation is on a session page just below the video and the captions content near Stephanie's profile. I'm going to turn off my camera. All yours, Stephanie.
>> Me? Awesome. Thank you, Travis. Hi, everyone. Thank you so much for staying through the past two days. I promise you'll get through this and then separate. It's been so awesome to be a part of Axe Con. I was watching Steven's last talk on gaming. I loved that. I'm really excited to talk to you about accessibility libraries and essentially how designers can start talking about accessibility and inclusion earlier in the process and why that's a good thing. A little bit about myself. My name is Stephanie Hagadorn. I'm a certified accessibility activist. Shout out to Texas. A lot of people repping Texas. I have two dogs that you might hear. A warning if they pipe up. They are out there. I love all things like movies, TVs, video games, and so when I'm not watching Star Trek or leading an Animal Crossing, you might have heard of Indeed. We're at the world's leading job site. We have a motto. We help people get jobs. Got it on my shirt here. It is really a core tenant of Indeed's ethos and baked into all that we do. It is one of the reasons that I love my job. Jobs can literally be life changing. I get to help people find work that brings them meaning and makes them want to get out of bed in the morning. You might think I'm over exaggerating, but it really is part of everything that we do at Indeed. Whether it is across every piece of merchandise and it is always leading the crowd of Indeedians at Pride parades across the globe. You'll see it on all of our signs at career fairs and hiring events that Indeed holds. We also have pictured here is the little orange chairs. In every conference room in Indeed when people went into the office we had physical orange chair. Now we have work from home friendly desk-sized orange chairs. That's a visual reminder that the job seeker has a literal seat at the table. We take thinking about our users super seriously here. And if you are not familiar with indeed, it is seen a lot of change over at the years. In the past we were focused on all of the jobs. The Google for jobs. We optimized the site through thousands of AB tests, user research, monitoring, metrics, data, analyzing data, and you have the Indeed that you see here today on the right. Part of had my hand in a little bit of that. While we always put the job seeker first we haven't always considered all of the different kind of job seekers out there and the unique challenges and barriers they face when trying to use indeed. With the unfortunately record unemployment right now, it's been more important than ever to focus on the job seeker needs. That's especially true for people with disabilities who experience joblessness at higher rates than the general population. For the past year Indeed has made accessibility one of the top priorities. We had a mandate and this mandate was supported by senior leadership and champion and managed by our amazing diversity inclusion and belonging team and this mandate really allowed our teams across Indeed to be able to dedicate more time and effort to addressing these accessibility issues. But now that we have kind of the permission or availability for the work the big question was how do we do it? How does a company like Indeed with massive amounts of content and pages begin to tackle accessibility? It is a good question, Stephanie. Well, we started like many companies do. We started running audits both internally and with awesome vendors like Deque. We conducted site-wide audits with the flow across the site and common actions that user takes applying for jobs, creating accounts, uploading resumés, and captured all of the violations and potential barriers and issues that users would face using our product. Those issues that we share back with Teams. They were across marketing and UX, product engineering, and over the year we remediated over 5,000 issues. We've added transcripts, captions, and audio descriptions to almost 400 video and updated 500 templates. Indeed sends a lot of e-mails. You probably have some in your inbox. Sorry. Being the data driven company that we are, we looked at all of the violations across the site and tried to figure out where they were happening and what was causing the violations and a lot of them came down to really simple things. Not meeting color contrast and really visual interaction-related bugs that could have been addressed or caught earlier in the design phase. So missing these easy fixes early meant costly remediations and 5,000 issues and time spend down the line documenting and fixing those issues. In fact, IBM did a report about estimating the price of addressing violations after release can actually be 30 times more expensive than if you just fix them in the design phase. That's a little money. And so while these issues can be easily fixed, we realize that we needed to address the accessibility fluency to help avoid making the same mistakes other and over and over. To put it in UX, how might we help designers better understand the accessibility requirements and start designing more inclusively. So to tackle the gap in knowledge we drafted our own version of WCAG guidelines. If you, I think many people here are extremely familiar with WCAG. And are very familiar with the cryptic, verbose, intentionally vague wording. And so we set out to really translate those declines into easier to understand checklists for designers and developers. We then -- so you can see the example on the right here of where we've taken the 1.1.1 nontext content rule and wrote it to help our designers and developers better understand it. So we created a web site internally and actually put together a big training webinar for the whole company. I know we gave the training to over 2,000 people at company. We were able to share the new guidelines, examples, and really frequently asked questions in the training sessions. That really helped to establish a base-line level of understanding and shared language. Our designers and developmenters were very receptive and eager to learn more about WCAG and accessibility. When we asked for feedback on the training and guidelines, we kept hearing a sort of similar sensement. That was, okay, cool. I'm really glad I have this information. How do I do it? The guidelines and training sessions built more awareness of accessibility, but it didn't really give them a clear way of applying accessibility concepts to the work. They knew what to do, but not how to do that. So designer, architect, and all around super smart dude said if you want to teach people a new way of thinking, don't bother trying to teach them. Give them a tool, the use of which will lead to new ways of thinking. Or sometimes more commonly I refer to a lot as praxis or learning through doing. By doing something and using the tool we can actually learn more about a concept or idea. So by providing designers with tools to engage in accessibility practices, we're helping them apply their knowledge and develop a greater understanding of accessibility. It is kind of like teaching a small army to fish by giving them really awesome fishing poles. So at Indeed, we primarily use Figma and libraries and plug ins to streamline the work and maintain consistently across products. For those in the chat or watching who might be unfamiliar with Figma libraries or components, they are little reusable pieces of design that you can easily drag and drop into a file and reuse and modify over and over. The example to the right is a small animation gif explaining how designers might use these components.
>> Hey, Stephanie. Can I jump in and bug you for just a second? Can you move back and recenter yourself just a little bit the way we were before? .
>> Am I off screen?
>> I'm so excited. I'm sorry.
>> That's cool. Sorry to interrupt. Go for it.
>> All good. So meanwhile with the WCAG2.1AAA mandate they are being asked to make sure the design meet the requirements beforehanding them off. Why not make a Figma library that makes the handoff -- there's my dogs -- that makes my handoff easier.
[dogs barking]
>> And simultaneously helps build an understanding of WCAG. So we did exactly that. We created an accessibility red line library with a variety of components and callouts to help designers highlight key parts of the page to developers. If you are unfamiliar with bread lines they are design files to make sure designs are made according to specification. They are called red lines. They refer to the red lines they use to communicate the specks. But in this case accessibility considerations. As opposed to WCAG, the library's is organized by different elements or content types. If you are familiar with WCAG, it is organized by perceivable, operable, understandable, and robust, or pour. It is more focused on the end users of WCAG. Which are users with disabilities or barriers when using products. Instead we reframed the guidelines to be focused on the people using them. For designers and developmenters. Things are grouped by headings, images, and video, things like that. To make it easier to know what distinctions or call outs to make in the file. For example, if I have an image on my page, you can go and grab my image. I need to include the alt label here so my developer knows what the image should be. That doesn't leave the developer to say what should this be? I don't know. I'm going to call it screen shot. It is not helpful for anyone.
All of the components are free filled with the protect CSS or HTML elements. Designers don't have to remember things like autocomplete values. I know for one the street field you don't have to remember just grab it. And landmark for footer is content information. I need to grab the footer and it ensures they are using the right value and as well as not having to guess where landmarks fall on the page.
[dogs barking]
>> Sorry. I can mute for a sec. Or what the intent of the page or pattern should be. We also included this part gets me really excited. But these little labels for indicating different types of styling whether it is for states of elements or any keyboard mapping for custom elements. Using the magic of Figma and auto layout and things like that, you can quickly make the table for what the right keyboard mapping should be for the custom component. I'm a big Figma nerd. I love that. Along with the library we also included a handy walk through of all of the components. How to use them and linked to the relevant WCAG guidelines. If you are wondering how you should use the image tag or how you could use the auto complete labels, you could look through the guidance and better understand the components. We also offered step by step examples of how to go about redlining the design with the accessibility library components. Here an example of a success screen after you submit the application on Indeed. Now we can label the heading elements and for complicated components like the rating we can say where things might need labels and where other labels might be part of the design and should really get to the Aria label. How additional operations. Then we share the library with designers across Indeed. It wasn't a requirement to use the tool. Just out there for designers to use it as another tool in their design tool belt. It took off really quickly. It is exciting and flattering. We soon started seeing more and more designers coming to our ally office hours or coming to the slack channel with questions about how to resolve problems with reading order or considerations for custom UI patterns. Things that designers aren't really come to us with questions about. It made us think maybe they weren't thinking about before the library. So one team working on the carousel pattern realized they needed to think through the focus order to make it more accessible for screen reader users. This lead them to reference for carousel and create a pattern more consistent with accessible carousel functions across the web. So many teams started making changes not just to new projects or features but as a way to see their existing product through a new lens. And another team, our messages team, used it to rethink the heading structure of the entire messages experience and that lead them to create a more semantic and easier to navigate page for keyboard users. The library was also a refresher. Seeing the guidelines made it click really well for me. The idea of being able to practice and have the tools to be accessible and think inclusively helped them develop the guidelines. It shapes how we approach the design practice altogether. They are thinking more intentionally about how their work impacts persons with disabilities and tools like the library have enabled them to reevaluate work flows to be more inclusive from the start. For example the design manager said accessible by design initiative to have new ideas from indeed that are accessible from the start. I'm sorry. When someone says that it makes my heart jump and so happy. Each quarter we'll continue to strive for accessibility and keeping at the speed that the engineering partners value. It really just driving home the point of how building these tools can shift people's mental model. It is really interesting. Right. While having tools like the red line library is helpful in speeding things along, creating tools, practices, and processes with the accessibility first mindset has a far reaching impact beyond just getting the product to market. The more we think about accessibility the more we are helping the designers think about it earlier and the more we are making it normal part of the practice. More important from the benefit, it is the affect that it has on the job seekers and employers on Indeed. In accessible in Indeed means more jobs for more people. That's my talk. Super short. Excited to answers questions. I'm also -- Travis if we have time, I can always show a deep dive of the library for people to get a glimpse.
>> I think we have a ton of time. Thank you so much. There's a lot of curiosity around the library itself just like we talked about before we went live. There's a bunch of people asking if you are ever considering making that available in the Figma community or otherwise. I hinted that you were working that out internally with legal. If you want to speak to that and maybe dive in a little bit more. That would be great. I think we have plenty of time.
>> Yeah. This talk kind of coincided with an article we wrote on Indeed and released on the median blog. We're working right now in order to publish. We have to get legal to approve. It is an intellectual property question. It becomes creative commons for everyone. We're hoping to get and needing to check all of the legal boxes. When that's available I'm definitely going to be tweeting it out. If you follow me at Steph underscore Hagadorn on Twitter or follow the Indeed design blog on medium or follow anyone on LinkedIn you'll see it there as well. I can share some of the things that we have here.
>> There's a lot of consensus of deep dive into the library, if you would like.
>> Cool. Cool. Cool. Cool. From my friend and other folks.
>> I think it is easy to talk about. You can see what the tools are. I just updated to support variants. I'm excited about that as well. We -- I do have a couple of intro slides. If you've ever used any of the other kind of Figma-community files, you can just -- they will be set up like a slide show presentation. You can press the end key and it will flip between the slides. What is the library for and how to use it. Accessibility is everyone's job. 100% agree. Yeah. Just how to use the kits if you are not familiar with how to use the components in Figma. We kind of just go element by element on what is the element and how to use it. We also include a link to the WCAG guidelines. That's all of the knowledge that you could have for the guidelines. Here we have made a simple title callout. At Indeed we have a special one that includes -- we've sort of default set it to end in hyphen Indeed.com. When you have a title page, they can remain consistent. They are build with auto layout. I'll back out to show. Maybe I can just drop one of these in real fast. You can see my asset panel here on the left. I can just grab my little headings chip. Beep. I can say actually in the component properties to the right. This is an H4. Really it needs to point down. Then I can just, you know, boop. Pop that little boy there. They are all built to point all of the different directions that you need. I also added a lot of arrows. For communicating things like labels where you want something to be problematic associated. I like to use the dash because it is an implied relationship as opposed to -- thanks, Google. Someone is adding me. Sorry that it popped up. You can use the different arrows here. I can drop one in. It needs to be an S bend or just a square or any kind of thing. If you are used to using wire framing or annotation libraries on Figma, right now this is similar. Depending on maybe the different color of label that you are using. There's a different color arrow. You can choose solid or dashed. That's really convenient. For things like labels, a lot of times we might have not a visual label but we rely on the Aria label on whether the form is icon or location maker or things like that. It might be a complicated -- this is an example in your resumé or Indeed profile when you have to say how long you worked at the company. We want to make sure the to and from labels and specifically the month and date are all problematically associated. As you are navigating through tabbing through as a keyboard user, you can still get the context that's kind of displayed visually here. We would hear month from time period. Whatever voice that you chose for your screen reader. Mine is an Australian lady. She's delightful. Here's an example of auto complete. You can grab your label. You can set is that an auto complete label. Yup. It is. It becomes an auto complete. Then I can choose is it a city, company, country, current password, new password, job title, user name. I'm always really bad at trying to remember all of the different auto completes that there are. But this is a nice kind of helpful list. It includes the correct attribute name for the developers. You should indicate all of the information on the left before you could read something like save this job or dislike this job. That came at the end of the card. Even though visually it looks like it might appear after something like the title or company name.
>> There are quite a few questions, not maybe specifically about the library. But there's a few that are pretty popular. If you want to field some of those.
>> Sure.
>> Would you recommend other organizations look into creating their own version of the web content accessibility guideline documentation as Indeed did to help your developers better understand the success criteria required to make an accessible web site.
>> Yeah. I didn't share some of the examples, but by creating our own, we were able to demonstrate the different guidelines. If it was about a lot of times forms. Forms are super big in the apply product and resumé products. We could use examples from there. Which I think really helped the developers see how these guidelines applied to their work when we were literally showing their work with. And I think it was just an interesting process even for the accessibility team to better understand some of the nuances in WCAG and I know people myself that worked together to create the documentation. I thought the guideline meant this and that. I had a lot of interested discussions. It could be redundant. In a way to help others process, creates a new understanding on its own.
>> Great. Let's see. Here's one that came up a little while ago. I know this person is up very late at night. Can you talk about the e-mail templates?
>> We have a lot of e-mails at Indeed. Different kinds of content. If you are a user, you might be familiar with job alert e-mails. You'll get a list of jobs in your e-mails. You might get e-mails directly from employers. We have templates for employers to put I saw you on Indeed. Apply to my job please. That's just the job seeker side. We have the employer audience for small and medium businesses as well as larger enterprise clients. There's lots of marketing e-mails that go out to the business side of the house as well as just e-mails that go around internally. We have lots of templates. How that looks is not dissimilar from how you might mock up a web site. Very similar looking. Just limited HTML CSS capabilities in e-mail.
>> Great. I'm going to break my uploading rule for a second. This one came in and it dove tailed into one of the other responses. Did y'all share your written accessibility guidelines meaning can we use yours?
>> Not publicly yet. I know we looked at a lot of the other companies who had done similar things. Expedia has a public version of accessibility guidelines. My former company IBM has a lot of documentation on accessibility. We don't have them public yet. Mostly just I think we've been so focused on serving our internal audiences. I think now that we're at a better place accessibility-wise, we want to be more advocates.
>> Not yet. There are others out there that have shared.
>> Yeah. I would recommend just off of the top of my head the Expedia one and I would look at IBM and -- I think even just the U.S..com. Their branding has a lot of -- design system has -- is all accessibility.
>> There were -- there's been a couple of different questions about sketch and alternatives for Figma and can you talk about that for people who might not have the budget? Is there -- I believe there's a freish version of Figma, if I'm not mistaken. Can you talk about different budgets and how they might be able to achieve some of this?
>> Figma has versions, I think, where you can send the file to anyone. So they can view it. I think even if they don't have a true account. They will still get things like the inspect panel which will have CSS for certain attributes or for each part of the design. That can be helpful. If you use sketch, sketch has components. You can do the same thing. They have -- I haven't used sketch in a few years. I don't know if they have the same capabilities that Figma has recently come out with, a variants. I know the plug-in community and sketch product have a lot of design components. Even in the Adobe landscape you have symbols. It might be more cumbersome or not flexible. I think you could also -- this is a great challenge. I think I might take this on. I bet you could do something in Google slides or PowerPoint. Just like you make the templates for your company to use, you could make grouped objects that you could easily demarcate parts of your work in. I think ideas or pieces of this you can take and apply in ways that work. Almost like reusable, like a little sticker sheet to just grab even just PNGs.
>> Great for sketch. I've seen them annotate the designs.
>> Even acrobat or PDF and you don't have the luxury of all of the components built. Designers are taking more ownership in screen reader navigation and I think we need to start thinking about that part as accessibility as usability. We should be more thoughtful and intentional there.
>> Very cool. Let's see. I'm going to cherry pick this one. Do you provide the developers code or does each team create their own code based on the design speck?
>> We have an awesome design system team. A lot of these designs that you see here are made up with the design system components. We have a huge library. The team has worked to create parody between Figma and the design -- coded design system. So they also work closely with a lot of the accessibility advocates at the company to make sure that when those designs are coded, they are accessible. A lot of maybe keyboard functionality is already baked into those components and part of the library.
>> All right. Let's see. Where is that question? Here we go. This one is pretty popular as well. How do you approach revisions to the components in the library and how do you update the designers and developers on what was updated or change? Version and change management question.
>> Sure. If you are familiar with publishing libraries and Figma here you can see all of the versions of the components they are put into variants like I mentioned here. And I recently just updated this. They were just kind of nested components. Any time you make a change to the variants or symbol in Figma there's the library icon tool. All you do is hit publish. You can see we're hard core library users. There's hundreds to choose from. You can public that. When you publish it, it will automatically update the files that other people are using the same library. Their components will automatically be updated. We also are big slack users at Indeed. For things like the design system or when I announced I made them variants. I just posted in are you S channel and ally channel and to say there was an update. We kind of -- it is like ad hoc broadcasting. But the way Figma manages library in Teams is chef kiss. Really nice. They will automatically update in your file. Occasionally that breaks it and we try to be really cognizant of breaking changes and especially announce that to people. Probably before we publish.
>> Great. Okay. Here's a really popular question. I'm curious about this one as well. How did you get funding for this project and how long did it take you to complete the entire project? Complete. I'm sure it is ongoing.
>> This is one of my personal pet projects. This is something I wished I had. So I was like I think I'll go make it. I mean Indeed is just a really wonderful company to work with. If you think something should be made, we have a lot of hack-a-thons, and even project teams are kind of in charge of deciding what they should do on their product or what the team should be doing. So as someone interested in accessibility and designer of the company, I just wanted to create the tools and kind of free time and my availability put this together. Oh my gosh. I'm sure Christine is listening. She will keep me honest. I would say from initial conception and documentation probably -- because we already had a lot of the guidelines rewritten, I would say two or three weeks. Then it is just ongoing maintenance. Adding in components for list elements and tables. That wasn't something that we discussed before. We can add that in as time allows. So we're sort of a do things go fast get permission later as I'm sharing this and it is not like legally publishly available yet. Yeah. That's kind of how we roll at Indeed and also another perk and benefit of.
>> Very goo cool. I think my CEO might be listening too. We do that as well. Here's a question that has come up a couple of times. And I -- I know a little bit about this. I don't think I'm allowed to speak to it. Maybe you can. And that's -- accessibility of Figma itself. Do you have a read on that or can you talk at all about that?
>> Yeah. That's a really good point. I don't -- I do a lot of screen reader testing and just try things out. I don't think I've ever tried to do Figma screen reader and I mean I think unfortunately just historically design tools have probably been geared to -- you know, just not catering to probably specific audience like audiences like people who might have visual disabilities or impairments, things like that. So I can't personally speak to Figma's accessibility. That's a really good question.
>> Yeah. We'll say I know they care and are looking at it. I can't say much else.
>> Yeah.
>> It is definitely something on their awareness radar for sure. So that was a great question. Another fun one based on your library, how much time in your day is spend in Figma?
>> The design system team would laugh at you. I'm going to Zoom in so you can check out the keyboard tables. They are really fun.
>> This ties into some chatter in the chat as well.
>> Cool. How much? This depends. I'm a UX design lead at Indeed. I would say my day is split between Google making presentations in G slides, being in Figma, and sitting in a million Zoom meetings. It is probably broken up like that. All of the awesome user sessions that I get to watch.
>> Very cool. Yeah. That's certainly important. This is all great. You got to see people interact with it.
>> 100%.
>> This is a good one. Did you encounter any pushback with the rollout of thaccessibility guidelines or the library?
>> The library, no. Accessibility, we tried to make it a thing at indeed. Ultimately the company is like OKR metric driven. Until that mandate from leadership and making accessibility part of our quarterly, okay, our goals and things like that. Until it was part of that product management process and kind of how things work at company. Teams wanted to be accessible, but just they couldn't balance the workload of being accessible and trying to meet the goals that were set. Until accessibility was prioritized as a goal through the awesome work of the diversity inclusion and belonging team. That is how -- that was the kind of pushback that we got. People wanted to do it. People understand why being accessible and inclusive was important. No one wants to be the bad guy that says you can't use my web site. Especially because we care a lot about our job seekers. It wasn't prioritizes. Getting buy-in from leadership and having leadership understand why accessibility is important and why you have to do it immediately or yesterday. A lot of it comes down to no one wants to be sued. No one wants the bad press that comes with being sued for the lawsuits. As well as it is just, like, the right thing to do. It is going to save you money in the long run as well. When it comes down to the business brass tax. It is the right thing to do. When leadership says to do it, people are incentivized to do it.
>> Okay. Let's see. We have time for a couple more.
>> I talk really fast. Here's a question what are the things that you mark to hand them over to the designers? Heading and tab and region. You spoke to this a little bit. Maybe elaborate on that. Does it all account in the single page or multiple pages? And I'm deciphers if that means the annotations or the information that you are handing over.
>>
>> Yeah. It could be quite a lot. If you had all of the annotations on at once. Designers handle it differently. Some people will have multiple copies of the page or file or flow. They might have one that's specifically has traditional red lines that shows things like margins and specks calling out the specific colors and things like that. And then next to it they might have, you know, here's all of the labels and things here's kind of what should be a button and something that we've included in any of the interactive stuff like links or buttons are the target area components so you can specify if you have a 32 pixel or 24 pixel icon that you can have a proper 44 pixel target area around it. We want to communicate that to developers. And you could have that in different panels. Something that I like to do and had in sort of the example documentation was grouping each element. You'll see the components group here. I would put in all of my headings and group my headings to turn on and off the visibility of those. Depending on what part of the design and content the developer was working on, they could turn on and off those individual layers. In the description of how to use this file, it is really -- whatever is necessary to communicate. You don't need to always -- you don't have to indicate every element. It is really like where is something that might need special consideration? Can we be more thoughtful or intentional with custom components do I need to include this is what and how the keyboard should work with it and this is the focus order. As necessary. Really just a starting point for designers and developers to talk about it. If this is more of them talking about accessibility, that's a win in my book.
>> Absolutely. We're at time. I want to squeeze one more question in. I think it ties all of this together. This is from Phil who says so that you mentioned your approach to the usage of the accessibility library is use it or don't. Is this because you are confident that word of mouth will be sufficient to see high adoption levels or something else behind that?
>> I mean I think no one wants to be told what to do. I think if you build it, they will come. No one was doing it because they didn't have an easy way to do it. There's a psychology theory the more difficult something is the less they want to do that.
>> Right. Right.
>> How easy it is to do it and how motivated I am. If there's a lot of motivation to the accessible, people were doing this on their own. If they weren't motivated and it wasn't easy to do, it was just being skimped. Just making it easy and now that they are kind of expected to be held accountable, this is just another tool they can use. It is not -- I mean I don't know if people use it or not. I can still sleep at night. It is just one of the many things we try to make available and improve about our practices.
>> Awesome. TV >> With that we're not only at time, we're closing down the Axe Con. Thank you to everyone that attended. You took your slides down. Your Twitter.
>> One moment.
