How Designers Forget to Consider Accessibility

[amazonv]

 How Designers Forget to Consider Accessibility

Type: Breakout

Track: Design

As a creative director, I’ve consistently been presented with designs and experiences that target a specific, typically abled audience. This talk will educate designers and the accessibility community on typical ways accessibility is forgotten in the design process and tactical, design-focused solutions.

 

>> Hi everyone and welcome to the session. We are going to get started in just a few minutes to allow some other folks to join. Please hang tight in the meantime.

 

 

 

>> Hi folks if you're just joining and you're looking for how designers forget to consider accessibility, you're in the right place. We are going to kick things off with a few housekeeping items in a few minutes here and then we'll get into Brandy's presentation so please hang tight.

All right. Well, it is 7:30 Eastern Time so I think we'll go ahead and get started. Hi everyone. Thanks for coming to the session. My name is Grace Kirkly, I'm with Deque and I'll be moderating how designers forget to consider accessibility with our guest Brandy Bora, design director with Verizon. I have a couple quick notes for our attendees. I'm sure those of you who have attended multiple sessions earlier today have these memorized but I'm going to go through them real quick. First off, the session is being recorded and the recording will be available to watch on demand on the presentation page that you're currently on after the presentation has concluded. Live captions are available below the video screen and the slides for today's session are accessible and also available on the presentation page where at the bottom it says to documentation, there should be a button there. If you don't see it, you might have to refresh your page. Finally, we'll save about 10 minutes or so of today's session and dedicate those to Q&A. Please post your questions as they come up in the SLIDO Q&A section that's right next to the chat module, also located next to the video screen. And I recommend sorting the chat by recent so any new comments scroll dynamically up to the top. With that, I'm going to hand things over to Brandy to present.

>> Thanks!

Well, let me tap into my little presentation there. Okay. Awesome. There's some little notification waiting for me. Great. So thank you for joining my talk today, how designers forget to consider accessibility. To go through the outline of our discussion today. First we are going to talk about who I am and talk about what my point is. Then we'll go through the design process. The design process for this presentation will consist of the engage phase, discovery phase, design phase, delivery phase, implementation phase. And we'll talk about some opportunities to improve accessibility and inclusion in the design process and then we'll summarize some of the points that we've made in the conversation.

Then hopefully we'll have a lot of time for question-and-answer.

So hello again, I'm Brandy. I'm a creative director at Verizon. I have a picture of me here with a wiggly gif of a mask. I have about 20 years design experience. I've designed a lot of different kinds of things. Signage, different applications, desktop, mobile embedded, physical objects, websites, games, immersive experiences and processes. The company I work for, Verizon, is a U.S.-based telecommunications company with 30 plus million users. We also have hundreds of designers and thousands of developers and dozens of partners and vendors that work on our digital platforms. I'd also like to shout out to our awesome accessibility teams. Some examples of things I've worked on. This is a page with a lot of different pictures on it. I have a picture of a series of remotes I designed along with a lot of other people at Comcast for the Xfinity remote experience. I've designed a bunch of applications. I have an image of the current Verizon app that I work on. I've designed party games. I have a picture of a party game I designed by Southwest a long time ago. Also used to work on the American Express Serve card payment platform. And then I designed this piece of street furniture that informed the New York City link  service. If any of you live in New York City, there's a public telecommunications instrument for users to interact with that gives you specific information, free WiFi, and allows free calling. Disclaimer before I get into the crux of the conversation. Some of the opinions that I express today are my own opinions and they're based on my own experiences and observations trying to make accessible designs. And a note on how I created this document if it's helpful to anyone. The document was originally created in Google slides. I'm presenting it in Google slides. It's exported into PowerPoint and PDF that's being shared. And then Alt text is prepared for each image and each gif I'll share and I'll describe each one I use today just in case there's any difficulty accessing the  descriptions. What's my point?

My point is that designers forget about accessibility. It's not that they don't care or it's not that they don't try. It's that for a lot of different reasons that I'll get into today, it's a part of the design process that's just forgotten. I'm showing a slowly moving gif of a really common example of a design talking to itself or a design creating things that are inaccessible but for a specific set of reasons. This is a slowly moving gif of a desktop website for the recess beverage company. The recess beverage company is a CBD-based beverage company that when originally launched had a very specific look and feel to target a very specific demographic. With that, the designers they for their desktop website picked up visual cues and trends that spoke to the audience. However, what happens in practice is a design that has some accessibility challenges. If you're able to see the slowly moving gif, you can see a lot of content that doesn't follow a clear hierarchy, it doesn't follow a clear grid, and the grid and hierarchy slowly breaks down more and more the user scrolls. And that free floating disorienting feel is meant to mirror the feeling you might feel while drinking recess, the  CBD-based beverage. And so this kind of conversation of who we want to design this for and the way we want it to feel begins a conversation leading towards an eventuality that design gets carried away with, leaving out how lots of different people might be able to interact or not be able to interact with that experience.

So one thing I've often heard as someone who's been through the design process with a lot of different teams for a lot of different reasons is that accessibility is often an after thought. It's too much work, it's too expensive, or it's not on trend. These are perceptions that different teams I've worked with have had. Here are two very popular examples that I've included here for reference. One is the original version of acorns, acorns is the financial management application. It's a complex piece of data visualization that shows where at any moment in time a user's projected balance might go should they continue to invest or include more money in that investment. There's a lot of tone on tone here. There's a lot of gradients. There's a lot of movement. There's a lot of numbers. There's a lot of content and it can be really difficult to parse. The effect is it looks smart. It looks complicated. It looks like money is growing and things are moving and positive emotions and smart things.

However, it can be really hard for somebody to understand this and use it or interact with it.

And then the dominoes pizza tracker which I'm sure at this point a lot of people are familiar with. I can't tell you, I was a consultant at the time that this launched. I think every client I worked with wanted this. They wanted a version of this for their own application. Not really considering how difficult or limiting it was to use something like this.

So as a designer or as a design consultant particularly, when a client comes to you and says,  hey, I see this in the real world and I see lots of press about this. I want you to do this. Make me a version of this well, that's the brief, they ask me to do that. How can I, the design consultant, unpack that or talk them out of that, especially when they have such an explicit ask?

Another contributing factor here is that project time lines are packed with activities that already over commit individual designers. So in an agency setting, it's not uncommon for designers to work 60, 70, 80 plus hours a week to satisfy demand for deliverables. So a client has hired a design firm or design team to help produce their idea. And now that they've hired that team and spent the money, everyone wants to make sure that the team is being productive and making lots of things. So they quickly cram the day with deliverables. So I have two images here to support that, showing on the left a complicated time line with lots of diamonds representing deliverables and lots of different lines representing work streams. On the right I have a screenshot of my actual calendar that has multiple overlapping commitments in each time slot and lots of overlapping out of offices for all the people on the team.

So then accessibility's often relegated to the implementation part of the process. So let's say we're a design group, we have been hired, the group that hired us feels like they know what they want. They want a pizza tracker for their particular problem. And we have got a design process that we're committed to working through and it's crammed with activities. If at all, accessibility is assumed to be part of the implementation process. So we'll go through our set of activities and then someone at the end will make whatever we do accessible. So in the typical engage part of the process, I'm showing a line here with a bunch of bubbles on it. Those bubbles represent different phases of the design process. The first one being engage, usually the purpose ever engage is to frame the problem and engage designers. This is usually led by the client on an agency client relationship or the business owner or the feature or the product owner or somebody who needs design or needs a thing.

So they will come with their idea of the thing. I think I want design pizza tracker for whatever my problem is. And then you the designer might have some opportunity, might have some opportunity to rework or reframe that with your partner. Some activities, you might start with a request for proposal. You might work through statements of work to engage different people to work on your problem. Then there's the discovery phase. This is where designers learn more about what the problem space is. You might do a lot of activities to gather requirements or understand the problem better. You might stakeholder with all the people that are involved. You might conduct secondary research. You might do some competitive analysis. These are all things you might do to better understand the problem or problem space. Then there's the design phase. This is where the designers will describe the experience and depends upon what you are designing. You might draw things, sculpt things, list things. Some activities are trend mapping, concept design, different fidelities of user testing and ultimately describe the final design in whatever way is meaningful to the problem you're trying to solve. Next is the delivery phase. That's where you document whatever the design is. Again, there's a lot of flexibility here. It really depends upon what you're making but activities are design documentation, user stories, grooming if you're doing software. So that's where you've designed a thing, everyone's agreed on the concept of that. Now you need to basically teach other people how to participate in the creation of that design. So that's specifications, blueprints, a CAD model, whatever it is. This is different artifacts you need to teach people how to make it real. Then the implementation phase. The implementation phase is when we build the thing, when we make the things users are going to interact with. For the rest of the conversation I'm going to talk about software design because that's what I know best and spend my time doing. If you're not interested in software design you can expand what I'm going to say and apply it to whatever kind of product making or thing making is relative to you. Some activities here are development, user assurance testing, visual testing, assurance testing. And then this is where people typically think of in my experience, accessibility testing might go, if it's part of this process at all. At the end it's lumped in with all the other testing activities as some kind of validation.

So to dig a little bit deeper into each one of these phases starting with engage, we are going to talk a little bit about SOWs. I'm not sure if you can see my window in Windows so I'll collapse it. Talking about two specific artifacts, RFP and SOW, requests for proposals and statements of work. Those are designed to get a design partner help a team create things. The language in both of those things is usually very focused on the business needs, the outcome or the KPI that's measurable and important to the business. The time line and the specific artifacts that the designer will make. Sometimes they might specify attributes of the visual design. They usually don't describe in too much detail or have too much flexibility of other considerations. I pulled some language from past SOWs and RFPs I've worked with. The past one are the designers will spend at least 10 weeks creating at least 15 to 20 screens for app and web. Another is they will work with business partners to understand business requirements. They will reflect our brand style guide while staying ahead of trends. They will understand the needs of new market segments, produce 1 to 3 hero flows and 10 innovative concepts that appeal to them. And then words that are often used in SOWs or RFPs are innovative, push trends, contemporary, fresh. That kind of language is used often when part of the purpose of the design is to address some look and feel or user experience softer needs that address some kind of perception that the brand or the brand experience or the UI experience is not aligning to some benchmark, either with a competitor or with an analogous industry or with the expectation of the end user.

In the discovery section, typically in discovery you'll be given a persona or segments or person I or archetypes or some information to describe who you should be designing for. I have two images here. One of a persona named Jim Smith and one of a stakeholder named John Jones and they're images of two men that look very similar to one another. And in my  experience, especially working on a lot of financial applications, this becomes a true experience, at least for me. Personas are often generalized and typically abled. This means I'll be given a piece of  information. I want to design a financial experience for our Jim Smiths and it will give me information and an image like the one here of a Jim Smith, and I'm given some financial information about him and I'm given some general demographics about him. But then it's assumed that he is typically abled. In some cases it's called out specifically additional  considerations, but generally the assumption is typically abled.

And research usually focuses on the experience of those people and competitive analysis doesn't really consider accessibility. So the design team might be given information on the performance of demographics, but the demographics or the performance of a particular product or experience or comparative or competitive analysis doesn't take into account more than gender breakdown or age and it's a good thing if we can even get those pieces of information. And then design. In the design phase, designers often sell stakeholders designs that are inaccessible.

So design activities collage trends to determine what users and stakeholders like. The inspiration that's pulled is often not accessible and stakeholders and users that are responding to those prompts are usually typically abled. On this page I'm showing a lot of images of slowly moving gifs of different inspirational images of fictional applications that come from places like the Hans or dribble. These are all focusing on motion concepts. And as a creative director who runs a product, I see things like this all the time. A team of designers are asked to pull together a trend or asked to look out in the world and see what's happening with a particular interface challenge and what they will bring back is a bunch of things that they found from dribble or enhance that came from different designers, portfolios from design school, and none of these things reflect real usable  UI, especially at scale. They reflect some kind of emotional or highly visual or motion sort of experiment.

And in great cases, we can pull from this things that we can use and make accessible to everyone, but in most cases, someone will fall in love with a very specific visual prompt and then the conversation will turn south into well, why can't we make that, why can't we make it exactly like that, how have we failed to make it as good as that?

These are the kinds of negative framing this this kind of activity often devolves into. Another issue that is common in the design phase is testing. So in the design phase we do lots of different types of testing and lots of different fidelities of testing. But low fidelity and medium fidelity prototyping are really common. And testing platforms have a lot of technical limitations. Beside the technical limitations users selected for early testing usually represent the market segment. If you remember earlier in the conversation, I showed you two images of a persona and a stakeholder that represented or resembled each other?

Often to further that, what happens is the testing includes people in that segment. And that seems to make sense, right?

You want to make sure you're designing the experience for the user who will use the experience. But we often forget to include ableament as part of that. We don't include people who may have challenges using the thing you designed.

So they are not part of the screening process and therefore they are not captured and included  discretely as parts of the test. And then quick prototyping tools and platforms are usually not usable by assistive technologies. So that's very limiting in how you can validate early concepts with users using assistive technologies. Two images that I have included here are from my real life. I work at Verizon using envision as our prototyping platform. The image on the left shows a complex state where we're replicating an OS modal on top of an inscreen modal. Because this is a flat drawing, a user using assistive technologies cannot interact with this screen in any way.

So we have to come up with other ways to make sure that our designs are usable early on. And then the one on the right, we were given a design hypothesis from a partner design team pretty early that leveraged this really heavy use of a very bright red color. And we had early doubts about the use of that color. We know it doesn't pass on most sizes. So we did some design experiments and tested it in envision. So yes, we could do some testing with some users that have color perception challenges and vision challenges, but it still wouldn't work with assistive technologies so we have to come up with other ways to test it to validate early on.

And then the delivery phase. So here I'm showing a gif of Mr. Burns of Homer Simpson, the caption says thanks for your feedback and the gif is of Mr. Burns taking a piece of paper, putting it in the shredder and then throwing it out the window. My point is now we have been through most of the design process. The designers have been given a brief and a specific person to design for. They made sure that they designed something on trend that the stakeholders and users liked and everyone's fallen in love with it. Now we're ready for delivery. Once that concept is sold, accessibility and other groups like legal, compliance, developers and other types of testing are usually positioned in opposition to the design, because the design has already been fallen in love with, somebody fell in love with the design, lots of people fell in love with it or committed time and money and attention to it. But they did that without consideration of these other teams and the other people that might have to use this experience. So now instead of becoming a yes/and, it becomes a direct opposition. So the design team in some cases too might be finished with their engagement. Their SOW might have been written such as you have got 10 weeks to design a solution to this and hand over the key experience. That positions the in-house team in opposition to the design partner that was hired where someone else has to come in and finish or fix the work that was given. That makes any accessibility feedback or anything else out of scope or it would have to be a change order so that makes it more expensive or it's handed over to a different team again to fix. After all that handoff, there's a big decision to make. Either we can take that design that everybody fell in love with and shoe horn that idea into accessibility, we can figure out how to fix it, we can move this there, change that to this, do the little things that we can do to make it accessible, or there's a perception that we're chipping away at the design.

Then in implementation, this is the worst case where accessibility sees a design for the first time. And this happens all the time. I'm sure like a lot of you attending this session know this and feel this every day. But this is generally like when accessibility will see that design for the first time, remember, like somebody's already fallen in love with it, it's already been validated with users that represented the market of focus and now it's been handed to you in accessibility and it's not accessible for a lot of reasons. It's fundamentally not accessible. This is where all the bad feelings begin. If you didn't have them before. So again, if this is the first time you're experiencing design or seeing the requirements, you, the accessibility professional, have lots of bad feelings about it. And then you want to share what's wrong with this design and the process that led to this design with whomever you can to prevent it from happening again.

And then this is how designers are delivered that feedback. They will literally be given an email, a brief, a list with phrases like oh, with red pen markup, that's not accessible, that won't pass, accessibility won't like that, accessibility rejected your design, do it again, contrast fail, make contrast 7:1, that's too small, I can't make that accessible, that blue is too blue, make it less blue. And all this specific binary pass/fail good bad sorts of feedback. So the opportunity here is how can we include accessibility throughout the process and become mindful of the needs of all users?

So I know that might sound like, yeah, we should do that, like we should always be doing that, right?

Here's some opportunities for us to do that I hope that are -- showing you a picture of the design process again. Engage, discover, design, deliver, implement. In the engage phase I told you some challenges I've experienced in the past with SOWs and RFPs. One thing we can do to improve that is to make sure we create language for all teams to use for those specific artifacts and project kickoffs. One thing we have internally is some boilerplate language that anybody can take so we can make sure our SOWs and RFPs have specific language that says instead of must meet the segment, must be on trend, that we can say must meet our accessibility and inclusion criteria. And I'll talk more about that in just a moment. Then in the discovery phase we can become stakeholders. So anyone that is an accessibility professional or has experience designing for accessibility, you can identify yourself as a stakeholder, make yourself known, and then educate your designers and business peers and you can create ways to test concepts or you can at least help your research team identify how specific experiences can be validated early on if you are heavily limited by your platforms.

Then in the design phase we can create playbooks of examples to help designers learn to draw accessible experiences. In delivery we can evaluate and provide feedback and requirements during the grooming process if you don't do that already. And then in implementation what we can do is we can turn problematic designs into teachable moments. We can establish ourselves as partners and prevent future occurrences. I'll dive a little bit deeper into each one of these. I'm going to share with you a personal example. When I was relatively new to joining Verizon in 2017 we had just started a major rebrand of the my Verizon app which is an app that people use to check how much data they were using and to pay their bill. That was the main two features. It took a lot of work to make that design, the new design accessible, because this design I'm showing here that's very pass actually, I'm showing an image that has lots of different screenshots of lots of different parts of experience, that original design wasn't accessible. It wasn't designed to be accessible. We had done some little hacks to make some important functions accessible, but it was really, really difficult to get it to work. So since we had the opportunity to redesign, we made sure that the design that we currently have and the philosophy and the principles of that design had accessibility in mind. So we partnered with our internal accessibility team to create something that we all felt was universally usable. So the image I'm showing now is also a full screen image with lots of different call outs of very specific moments in the app experience. This is a black and white design system, so that's also sort of easy and lucky for us that those are the brand's colors, black and white and very dark gray. But we had the opportunity to lean into that and make it part of the style, not just do it because that's how we can ensure perfect contrast. We can elevate it. If we need to have large type so that everybody can use it, let's make that like part of the aesthetic, not like, oh, we got to because people need to be able to read and stuff. That's that hohumming attitude. These are attributes and they makeup the personality of the brand and it's something that's able for everyone to use. And I won't say that this design system is perfect. It has lots of problems. We have one example is an over reliance on carousels that we know are problematic. I'm not saying we nailed it and do everything well. But one thing we did do well is start from a base design system and set of design principles that represented a solid set of scaffolding that we could build upon because they themselves, the original elements and components of it were accessible.

So during the engagement phase we can create language to leverage during that phase. So we can define what we mean as an organization, as a team, as a product when you say you're accessible. You can documents that and socialize it so teams can leverage it throughout the design process. This is something we have at Verizon that we co-created with the accessibility team and it's incredibly helpful. We pull this language and reference it in our SOWs and RFPs and it's extremely helpful. That way we can hold ourselves and design partners and vendors accountable for our experiences. So if we do get a piece of design back or a concept that's not accessible or we think might be problematic, we can more easily say hi, partner, please take a look at this. Just remember when you begin an engagement with us, you're committing yourself to create accessible experiences or experiences for everybody to use. I'm showing four different 10ents of those guidelines. We design texts, buttons, navigational elements to the color contrast ratio of 4.5 to one and use visual indicators with interactive elements. Experiences work for customers without vision. We design experiences so that screen readers can properly move through our screens and flows. EG, a numbered list component is laid out in order so a screen reader moves through it, reading in the correct order, one, two, three, four. Experiences work finishing customers with limited mobility. We design inclusive experiences that allow customers with limited motor function to tap and scroll simply and easily. We don't create experiences that rely on sophisticated gestures. I could talk all day about that last statement. But as an application designer, especially like a couple years ago, that was -- that little piece of language won so many internal and external battles for me because I could say look, those gestures, those cool things you saw wherever, that's great. But on whatever app or in whatever trend board, awesome, but if we do that and lean into it, we are literally excluding lots and lots of different types of people, myself included. And it doesn't align with our tenets. And just that, it doesn't align with our tenets or accessibility statement or brand guidelines on accessibility, then that stops the conversation right there. Got it, everyone gets it, and we can move on and start talking about something else. Experiences must work for customers with cognitive, language and auditory challenges. We keep our layout simple and logical, our language easy to understand, our navigation consistent. We only include visuals when necessary and always provide supporting text. This is another one too, just documenting it somewhere that we won't solve it with imagery. That was a huge deal. That was a problem we had in an older version of our brand. Solving it once but making sure we had language to prevent it from occurring again is really helpful. Again, like I'm not saying we did it perfectly or anything, but this is an example of some language we wrote and documented and shared out with all of our partners and vendors and we can reference back to and this helps us work through some common and early challenges. Then you can become a stakeholder during discovery. So at Verizon accessibility is a stakeholder that helps us understand needs and considerations before we commit to anything. Anytime we have an idea of something we think we could work, we make sure to include our accessibility partners. Every design team has an identified accessibility partner and if we don't we know where the central accessibility office is and how to begin that conversation. There's really no excuse to not include accessibility as early as possible. For your org, you may not have that ability or maturity yet in your company's exposure or partnership with accessibility so you might have to start early or create a center of excellence, you might have to create somebody and designate them in a leadership role or write a charter as I showed you in the prior slide and socialize that that defines the discipline or team or tenets. And teach your organization how and when to engage with you. The important thing is overall to establish yourself and establish a relationship and offer yourself as that resource and share feedback at every step that you can. So I have a gif here that I'm showing of Wil Smith, the fresh prince, and DJ jazzy Jeff doing their secret handshake from the classic sit com the fresh prince of Belaire, which was a childhood favorite of mine. And that's the kind of relationship that we should aspire to have with our accessibility partnership at every moment within the design phase to make sure that we're being inclusive. We can also create helpful examples for the designers during the design phase. So the WCAG presents as a space for specialists rather than for designers. It looks like sort of a library sciences website reference kind of place. So often what I've seen in the past is someone will give the designer this link, the WCAG link, or they will give them a copy paste piece of guidance from the WCAG. And it feels so legal and so formal, designers aren't sure what to do about it and kind of approach it fearfully or with intimidation. What we can do to bridge that gap is create some specific examples. I'm showing you a couple of examples of how we define this for the Verizon world, but this doesn't have to be for using your own product as an example. It can be screenshots of anything in the world. But here are just two that we have that are really common. The one on the left of the screen is screens should follow a strict hierarchy and it's an image of a phone customizing screen that's pretty complicated. These are both plausibly complicated on purpose to illustrate how a designer can deal with things that are very complicated but still make them follow a clear order and be accessible.

So the guidance is screens should follow a strict hierarchy, ensure that the purpose of the screen can be easily understood, even when our complex end services are inherently complex because with the products and services we deal with at Verizon, they are the thing itself and acquiring the things are complicated. It's a major purchase. There are a lot of decisions to be made. There are a lot of decisions that our users want to see or interact with all at once. So trying to put those things together and make them easy for everyone to engage with and understand is a challenge, but like as a designer, that is the challenge, that that's the fun and exciting part of design is solving complex problems.

So some specific guidance for that kind of content is all screens need to have a descriptive title. Reading order is top-down, left-to-right. All screens have a strong header style that's a major typographical jump from body to subsection. That's taking some guidance that's our brand and taking that brand and translating into this screen. So major typographical jump between header and body, that's not WCAG language. That's our brand language, but that's an interpretation of both wrapped up together that we co-wrote with our accessibility team. And then all functional copy, that's an internal phrase, is action oriented and instructional and simple. So again, all these pieces of language here, they are not copy pasted from the WCAG, but they were written between the design team and the accessibility team in partnership to help designers understand how to interpret accessibility considerations in a given design system or for a given product.

Then on the right is an example of form elements, because we know form elements are commonly incorrect or just difficult to interact with. So I'm showing a gif of a little bit of a complicated form for us. We don't actually use forms that much. So these form rules are specific to our forms, but overall, keep forms simple, direct and required. So we have an overarching principal just don't have forms if you don't need them. That's not something we usually need. But if you do have to have a form to capture information, forms have to have a title, instructional text to orient the user. The text must meet -- all fields have to have labels, all fields have to have specific descriptive errors. Screen level errors appear at the top and bottom of the screen are persistent in the view. And all fields are required in our form fields. Optional fields are rare and called out with an asterisk. This is our interpretation of the WCAG in our brand, but these we have stacks and stacks of these things to help the in-house designers and any agencies we onboard learn how they might interpret and what they need to consider when they think about accessibility in our brand or for our product or for our users.

So then delivery. When you're in the delivery phase, one of the things we can do better is work with research teams, we can talk through challenges, we can figure out how to validate, create a plan together. I have a gif here of a printer printing out the word test test test test. Lots and lots of testing. I can't stress how much testing enough. We know as much as we can before we push it out to all of our users. What are the limitations of our testing tools?

What considerations can you include in your test?

Is there any way to simulate a screen reader experience and validate it early on?

There are ways to do it, but you can talk to an accessibility professional either in-house or ask someone in the world how you might do that with your particular design. We can consider including participants that would identify as having challenges that might impact their ability to use design. Figure out how to do that in a way that makes sense for your product.

Think about amongst yourselves like what challenges would impact their ability to use. Who would be able to use this?

Who would not be able to use this?

What do you need to do to make sure everyone can use it?

So then use this opportunity finally in delivery to provide feedback on the design. So I have an image here of the meme your design is good, but it can be better from Wonder Woman. You can leave comments on the design, however it's shared with you, but when you do that, as the accessibility professional, make sure that you try to avoid pass/fail language and try to avoid specific solutions. Instead, frame it as a value-add. So instead of maybe saying this color doesn't pass or this link isn't right, and instead of saying make the link underlined, unless you have specific guidance on that, instead try to phrase it as an opportunity this would be a lot more usable if we had two ways of interacting with it or two ways of understanding that this is interactive.

If you have a relationship with the development team, work with them too. Maybe your level of effort as accessibility professional can get added to the overall development LOE and that will shake the tree. Suddenly if LOEs start getting bigger and bigger and bigger and it's because the accessibility effort to write accessibility requirements and test against any given story, if that's considered all together, that will hopefully begin to understand how important it is to prevent that long tail or heavy lift or the larger LOEs at the end of the process by better earlier considerations in the first place.

Z implementation. So we can coach, we can reject, we can partner and power through. This is when you're all the way at the end and the first time you see the design and it's not accessible. You can design. That's your moment to say I can, depending upon where you work and who you work with, you can coach the people that created that design on how to work with you to make it better the next time. You can reject the design. That might be a tactic that's really effective where you work. Or you can partner and offer to do it together the next time. That might be more work for you. It probably is. And it may not be the right thing for your team, your culture, your product, but you have got to experiment with those kinds of tactics and figure out what will work for your team and for your designers so that the people that you work with can begin to internalize the needs of all of your users and be more mindful on future projects. And then repeat that. User experience designers or designers should get it. Once you bring them on board or make them mindful and show them the opportunities to be inclusive. They should get it. But not Nemeth's. That's an assumption. And not necessarily everybody on the team will empathize or trained to empathize or simulate empathy. So when you do partner with a designer and educate them, you'll build new advocates and hopefully future designs will become more usable for the end user and less painful to create.

So in summary, designers forget, trends are often inconsiderate, the process isn't inclusive, but you can educate, you can partner and you can create new advocates and hopefully make the process easier for everybody and more inclusive.

Here's some references. This will be provided on the site. I think a lot of you here don't necessarily need these references but I've also got some Verizon team shout out stuff in here too. Yeah, I'm excited to hear what if any questions you might have and I hope that was helpful to anyone.

>> Great!

Thank you so much, Brandy. And definitely just judging by some of the comments here, not only was your presentation very practical to apply, but also very relatable. We have a lot of people saying gosh, this is me, this is my job. And I wish we could have another hour in this presentation is one of our comments here. We only have a couple of minutes so I want to make sure that we at least get one question  in.

>> Do I stop sharing or no?

>> You can keep the slides up.

>> Okay.

>> So this person asked:  You mention that envision makes it difficult to test something like a modal dialogue with the screen reader early on in the design phase. Are there other more accessible tools you would recommend using for testing designs?

>> No. That's like the challenge. So we're still in a position where we really have to rely a lot, like way too much, on gut and working with our accessibility team to just build off what we know to be true today and what's problematic today and what we know isn't. For our end, that keeps us safer in our designs and like prevents us from experimenting more, which is kind of a bummer. So we err on the side of safety. But if we were to pick up something that we know is going to mess around with something we think is going to be a gray area, this is coming up for me now, actually. We are going to mess around with some modalities that might be challenging, we are going to do have to work on a way to simulate it and test it specifically for AT users, because that's who, for that particular thing, that's who really would have the hardest time with it. Anybody who has color perception or low sighted challenges or dexterity challenges should still be able to use it because it's already accounting for the nature -- we have to find a way early on to validate that we can make it work. We might even have to go build it, like build and experiment and test the experiment.

But low fidelity, like paper prototyping, there's a lot of very experimental ways of testing those, but yeah, not using a broadly available platform liken vision or Marvel or Figma.

>> Awesome. Thank you for that. Looks like we're actually over time a little bit so sorry for those whose questions we didn't get to. Thank you so much for your great engagement and thank you, Brandy, for your presentation. I think everybody enjoyed it.

>> Yeah, if you have questions for me in real life, feel free to find me in real life and ask me.

>> Awesome. All right. Well, everybody please enjoy the rest of Axe-Con and have a wonderful rest of your night.

>> Thanks.