>> All right. All right. Thank you, Shawn, for that introduction. I am very excited to be here today. As Shawn said, my name is Eric Zirlinger, and for the last year I've been at the design leader at Deque, which is kind of a dream job to be doing something that makes you tired for all the right reasons and helping make the world a little bit better. I have the privilege of leading an incredibly talented team. Folks like Shawn, our moderator, who way smarter than I will ever be. For a little visual context about me I have brown hair that's short on the sides and long on top, and a scruffy short beard. Currently, I'm sitting in my home office and I'm not going to lie to you, the only part of it that it's clean is what you can see on this camera. If I showed you what is just to the side, it would be disappointing for everybody. I do have an energetic presentation style, and I tend to use a lot of body language along with my words, so I will do my best to kind of be aware of that as I go along. I also do joke around a lot, and I have a tendency to speak a little fast. I will also do my best to be aware of that. Just a note, I am going to describe everything we see on the screen. I want to make sure that I'm doing my best to translate all of these images to everybody. My hope today is that after today's session, you can immediately start using some of these approaches. And that's what I think might be a little bit different in this session. It's really about practicality. And let's be honest, I will not be able to answer everything. Even more important, I don't know everything. If I don't know something, I will be very honest with everybody. Today is about meeting you where you are, and let's start by focusing on progress over perfection. So diving straight in, who is this presentation for? Well, the content does focus on digital accessibility beginners. However, it's also beneficial for those who have a lot of experience and might be looking for new approaches. Some of what we may cover or what we cover today will be familiar, and you may have a way that works better for you. And that is great. What I would ask is share that with this community. This is all about a community sharing all of our knowledge together. So our big goal for the day is to equip designers like yourselves with some practical strategies and approaches to common accessibility design issues. Also, don't pretend like you're not impressed with the design of this slide. It is just a simple title and it is just a little bit of sub copy. This is why I went to school. So how do we meet that goal? Well, you're going to hear me say things over and over again like a broken record. First, we want to get on the same page about digital accessibility. Then we will move on to practical approaches and strategies about some some common digital design issues. We will start with learning a different approach to color contrast. We'll then move on to learning how to test if we're relying on color to convey meaning in our designs, followed by learning how to approach and document reading order. And then lastly, we'll learn the basics on how to write link link texts that make sense on its own. If some of this is new and the terms are unfamiliar, that's okay. I'll do my best to explain it in the time we have, but remember, you will always have access to this and you could dig a little deeper on your own. Lean into the community from this conference when you have questions as well. As we're all working towards a common goal. A little disclaimer. Let's agree that any typos and there probably are some are a style choice in this presentation. They don't reflect how well my teachers taught, and those teachers shouldn't be blamed. Even though I have an English degree and I still cannot use a semicolon correctly, transparently. I'm not even sure at the end of this if that is a semicolon. So without further ado, let's begin. Let's start by getting on the same page, and we will do this at each section, getting on the same page. This means acknowledging that accessibility is complicated. And if that was the end of the presentation. Thank you for coming. I hope every single person had enjoyed this entire conference. I said it. We are all thinking it. Let's take a deep breath. We're all in this together. We know it's complicated. We know it to be true. If it weren't true, we wouldn't be here. All designs would be accessible and everyone would have access to all information. That would truly be wonderful to be out of a job, because that was the case. So what do I mean when we say complicated? Well, let's examine something complex that isn't about digital accessibility. I'm going to do my best to say this in the best possible announcer voice that you've ever heard. Here is a complicated statement in the domain of architectural jurisprudence. The presence of an ingress and egress latch serves as a paramount for ensuring compliance with accessibility statutes, fortifying premises liability, and enhancing the functional. The functional efficacy of architectural constructs. Anybody have any thoughts to what that means? John, don't say anything. To put it simply, it means that doors need handles. That's what we're trying to do here. Simplify some of these complex concepts and statements. So similar to that big, complicated statement, accessibility can feel complicated and like that simplified version of doors need handles. The Web content Accessibility guidelines. WcaG for short help make it easier to understand, but it is okay to still say that it can be a smidge confusing. So let's take a quick look at a wcaG example for success. Criterion 1.1.1 Non-text content. What I'm showing here is the actual web page for this success criterion, and we're not going to dig too deep into it. But what I want to convey is there's a lot here to understand. We start with an in brief section, which is excellent in humanizing what this means. Then we have our success criterion followed by the intent. Notes on capture. Additional information. Benefits. Examples. Then we go down to related resources. Techniques, sufficient techniques. Short text, alternative techniques. There's so much and I'm not complaining. It's all important. But it's okay to say that this can feel overwhelming not just for beginners, but for experts as well. So moving back to our presentation, what I want to really think about is how do we how might we simplify WCAG so we don't have to refer to it all the time? Let's try and think about accessibility from a user centered perspective, and focus on what the user is trying to do with the product or website, not just a technical perspective. We're going to start with color, contrast, and design. I have a slide here that says color, contrast and design, and it says a different approach with a question mark. Why the question mark for a different approach? Well, the approach I'm going to show you might be different for you, and it might not be one that resonates with you. And I encourage you to challenge it. I encourage you to evaluate it. This doesn't mean you shouldn't learn more about color contrast. Many of us use plugins to check color contrast, but do we really know what the color contrast requirements are for every single element on the screen? For the exceptions, for text, for images? Do we know them all? It is absolutely okay if we don't. So let's start by getting on the same page. What is color contrast? Color contrast refers to the difference in luminance or color that makes an object or its representation in an image or on a screen, distinguishable from other objects in the background. That definition can be a little confusing. I highlighted here the word luminance. Can anybody explain what it means? Could you explain it to a fifth grader? We're not really going to dig too far into it. It's complicated, I get it, and it's okay to not know what it is, but can we simplify it in a way that we could explain it to a fifth grader? Here's a simple way that I like to think about it. Color contrast is the difference in colors that makes one thing stand out from another. It's making sure that words and pictures are easy to see and read against the background. Why is color contrast important to users? Well, for those who can perceive the color, it can help make it easier for a user to accomplish a goal. Remember, I will always say we are always focusing on the user and what they need to accomplish. So here we have an image of six circles. Each circle has a number inside the number and circles are made from dots of various sizes of varying sizes. The dots are all different colors. This is a common visualization to represent contrast issues and color blindness. I'm not showing this to dig too deep. I'm only showing this to get on the same page of what we mean when we say we're talking about color contrast. As mentioned before, there are WCAG success criteria for color contrast that help us ensure our designs conform to contrast requirements. Regardless of what we learn today. Please read them. Ask questions about them, ask the community, dig in deep and learn more about them. What I tried to do in this next visualization is show a decision tree that attempts to show those WCAG, color contrast, success criteria and their various exceptions. We're not digging too deep into this as well. The takeaway here should be, as you can see, there are many, many decisions to consider before we know what the color contrast requirement is. I do recommend reading them again because of the wealth of information, but memorizing a decision tree like this can be really difficult, especially when in addition to color contrast, there are so many other success criteria we have to satisfy as designers. So the big question I have here is can we prevent color contrast issues and satisfy wcaG with one simple question? And I think we should try. Here is a practical approach that I like to take for color contrast. When thinking about color contrast for everything a user can see on your site or your product. Ask yourself is it needed, helpful or not needed for completing their goal? If it is needed, the contrast requirement should be 4.5 to 1. If it is helpful, the contrast requirement should be 3 to 1 and if it is not needed, often heard as decorative, there is no requirement. I am going to say this question over and over again to internalize it and drill it into our heads. This approach actually falls somewhere in between WCAG levels, which is the standard for many companies and EAA. That means when followed, it should address all double A issues because it is more strict. Now there's a risk with this approach. The risk is saying, well, what is helpful and what is needed. And this is important for your organization to align on early on when you're working through this. Let's take a look at this approach in practice. Here I'm showing a button. It has a black build button with a white leading icon on top of it, and a white text label that says Download results. We're going to go element by element and ask our question starting with the text label. Is the text label needed helpful or not needed for the user to complete their goal? And in this case, the goal is to download results. I would say that this text label is needed. Without that label, all users wouldn't be wouldn't be 100% confident that what this button is going to do. So that means if it's needed, this text label is 4.5 to 1. Moving on to the icon. Is this icon helpful, needed or not needed? I would say because we have this text label that this is helpful but not necessarily needed. It's important to note that there there aren't too many universally recognized icons. So if this one is commonly known but not universally recognized, it could still be helpful. So because it's helpful, the contrast requirement would be 3 to 1. To this background, this white on top of black would be 3 to 1. Then moving out again notice how I'm working inside out. The background fill is black. Is that background fill helpful, needed or not needed for the user to know how to do their job? To complete their goal of downloading the results. And I would say that it is helpful. It helps me know that this is a button. If I didn't have it and I just had the label of download results, and that label happened to be a darker color on its own standing there, it wouldn't be needed, but it's still helpful. So because it's helpful, it's 3 to 1. So just remember that note if the content is needed for the user to accomplish their goal, think of it as 4.5 to 1 is the requirement. If it is helpful for them to complete their goal 3 to 1 and if it is not helpful at all, no requirement. So it's easy when we're looking at it in the button, and we're not going to have time to dig into a complicated, incredibly complex visualization. But I promise you, you can apply this approach the same way. We're going to look at the infamous donut chart. Here we have a donut chart. The chart has a circle around it. And the purple progress bar that's filling up roughly three quarters of the way around that circle. There is a large number in the middle of this chart for 75%, and just below that number is the text that says Accessibility Score. The chart is trying to tell the user that their accessibility score is 75% out of 100. Let's take our approach and start with the big number and work our way out, asking ourselves the same big question over and over. For everything a user can see. Ask yourself, is it needed, helpful or not needed for completing the goal? Starting with that 75%, knowing that it's supposed to communicate the score of 75%, accessibility score of 75%, is that number needed? Helpful or not needed to communicate the goal? I would say without it, they wouldn't know their score. So it is needed. That to me says the contrast requirement is 4.5 to 1. Moving on to the text below it. Accessibility score. Is it needed, helpful or not needed for the user to know their accessibility score? I would say it's needed. Without this, you would just see a 75% and you'd say 75% of what? So you need both that giant number of 75% and the text accessibility score to convey for the user to complete their goal of knowing what this means. Now let's move out to that donut chart. And I'm not going to spend time looking at this border or this light or this light gray background in the in the background fill. You should do this for every one of those elements. But let's just take a look at that progress indicator, that purple indicator that fills up three quarters of that circle. Knowing that this is communicating the accessibility score of 75% out of 100, is that progress indicator needed? Helpful or not needed? And this is where I would say it is helpful on glance. That progress indicator visually kind of gives me an indication that it's not an entire 100% out of 100%, but roughly 75%. But if I removed that progress indicator, would I still be able to accomplish my goal? Yes, I would still know because of that large number and that accessibility score text, that this represents 75% out of 100 for accessibility score. So very quickly, again, 75% accessibility score, that text regardless of size. And I know there's a lot of requirements I like to say that is needed. So that means the requirement is 4.5 to 1. The visualization around it of that donut chart is helpful, but I do not need that to accomplish my goal. So if it's helpful 3 to 1 and we're going to stop here, there's a lot that we could go into it. But what I challenge you to do is test this, evaluate it, check it against those WCAG success criteria. Really make sure you feel comfortable with this. And my goal is at the end of this presentation, you have internalized this so much that if I ask you if something is needed, you can say the contrast requirement is 4.5 to 1. So I drill this into your head one last time. How can we approach color contrast without always having to refer to WCAG? Ask yourself for everything a user can see. Is it needed, helpful or not needed for completing their goal if it's needed. 4.5 to 1 if it's helpful. 3 to 1 if it's not needed. There's no contrast requirement. Let's keep on with the color theme and move on to not relying on color to convey meaning. Let's talk about how to ensure that your design design does not need color to convey content and meaning to users. As always, we start by getting on the same page. So what do I mean here? When I say not relying on color to convey meaning? Well, color should never be the only way to communicate important information in interfaces. We know this to be true. We hear this all the time, but how do we test for it? How do we make sure that our designs are not relying on color? Well, we've heard people say always add another visual element like an icon pattern or text label, and that's great. But we should still evaluate. Did we kind of really satisfy that even when we added that pattern, that text label that icon? Let's look at the risk of using color to convey meaning. Here we have three circles in a row that look like grayscale, but they're actually full color. What I did in Figma is I applied the luminosity blend mode. Do not worry if you don't know what that means. We're actually going to show this today. From left to right we have a dark gray circle, a light gray circle, and a medium gray circle. Each one of these represents a different status in progress, not started and completed. Can you confidently say which circle represents which status? Just by looking at these circles on the screen? My guess is no. Now I have the same three circles in a row. However, this time I turned off the luminosity blend mode in Figma. From left to right, we can now see that we have a red circle, a yellow circle, and a green circle. Each one represents a different status in progress, not started or completed. Can you confidently say which circle represents which status just by looking at these colors? You might have some preconceived notions, but can you confidently say it? Now? For the last time, we're looking at these circles, and from left to right we have a red circle with the label status completed, a yellow circle with the label status in progress, and a green circle with the label status not started. Now, can you confidently tell me what status each one of these circles represents? Because I didn't rely on color, there's another way of conveying that information. I'd say hopefully yes, but I'd still want to test it. So be honest. How many of you thought the colors would represent different statuses than just what I showed? How many people thought that the red would represent not started? How many people thought green would represent completed? We have these preconceived notions. We don't want to rely on color. We want to make it incredibly clear. This illustrates the risk of relying solely on color to convey meaning. But let's look at a more realistic example. I'm going to show an example in a digital design space. Here I have a mobile layout with the title example of relying on color to convey meaning. There is additional text that says, can you confidently identify all the links? What if the ability to identify the links was critical to accomplishing your goal? Then we have an email input with hint text that says your data is protected in our privacy policy, followed by the input. Once again, this design looks grayscale, but it's not. In Figma, I applied that luminosity blend mode. How many links do you see here? Take a look at it. Think about it. How many can you confidently say you see? Now, same approach that we just did before. I'm going to turn off that luminosity blend mode and show you the same design. Now I've added this design in and turned off that mode. How many links do you see here? You should see three red links. The word links was a link. Accomplishing your goal was a link and the privacy policy was your link. Did you all get it correct? How many did you get? This illustrates relying on color to convey meaning. And I'm not saying what we see here is the solution, because these two screens are what people would see depending on how they perceive color. But how do we make sure that all people are clear what the links were on the page? Let's look at how we can prevent this. I'm now showing one more of that same view. This time the links are underlined and I have made the font weight heavier. The luminosity blend mode is back and again, don't worry if you don't know it, you will. Even with it on, you can confidently identify all these links. We prevented the problem by not relying on color to convey meaning, by adding weight to the font and underlying those links. Common best practices. But we know there's a lot of ways that we have to test and evaluate this. So let's start to look at our practical approach. The practical approach to prevent this issue in your design tool of choice, apply the luminosity blend mode. Different tools do this differently. I'm going to show this in Figma because it's the tool I know most commonly most best. But I want you to then test once you apply that blend mode. Test this version with users to confirm the content. So let's take a look at what this means. I'm going to bring us into Figma, and I am showing an example here of a website. This website has the luminosity of blend mode applied. The website is showing across the top a top bar with a logo menu, items of home about pricing and a CTA for start a free trial. Then in the hero, we have a big title, a smaller title, a smaller subtitle, a large CTA, and then next to that CTA, we have the Contact Us link. Then we have an image of paint rollers going up and down, followed by a section, a testimonial section where we see happy customers. And each in this testimonial section, we have these cards that represent specific testimonials. I'm a happy customer and the company. Now looking at this, can you confidently tell me all the interactive elements on this page? Let's turn the luminosity blend mode off. So here in Figma, what you see is I'm going over to that panel on the right side where we manipulate everything we need to manipulate. And there's a label for appearance. There is a teardrop drip icon, rain drop, whatever you want to call it. And when you click on that next to appearance, we can see that I can remove the blend mode. So when I remove the blend mode, you should see all the interactive elements. And I'm relying on color to convey meaning. So hopefully you were able to articulate that this was we have this big button. We have these links that we are saying. But how many of you thought here we're confident that the company's name and the testimonial cards was interactive? Maybe it is, maybe it isn't. But I used red to show that it was. But when I had that blend mode on, you couldn't tell. So here is how I want you to test it. Remember, you have your final design come into your tool of choice, and in Figma you can come in, highlight the frame or highlight the section. Go to that appearance area on the right side. Click Apply Blend Mode and then go down to luminosity all the way at the bottom of that menu. And this is what I want you to show with real users. Ask them, can you identify all of the interactive elements on this view? And watch as they do it. See if they're guessing. See if they're stumbling. See if they're confident. But now we're looking at it here on this webpage. And this is a relatively simple design. But let's go back to that infamous donut chart one more time. Now I'm showing a donut chart. And I'm not saying this is a great design. Donut chart. This donut chart has a legend. The legend shows us that there are four categories A, B, C, and D, and next to each one of those categories is a rectangle that represents the color of the place in the donut chart. Now you can see here we're supposed to have four categories. But in this donut chart, how easy is it for you to see these categories? If you did that ever so popular squint test, if you just squinted your eyes a little bit and blurred it up a little bit, can you see all of these categories? Let's turn off that blend mode one more time. I go to appearance and I click on the teardrop raindrop over here to turn it off. Now you see all of these colors. Color was relying. We were relying on color to convey meaning. So when you're doing a data visualization, there are tricks we can talk about applying patterns to each one of these. We can talk about separating it. But what I'm asking you to do is you don't have to memorize all of them. Now, I'm asking you to test. And remember, you don't want to rely on color. So before you dig too deep into how to solve these, test those patterns, test that idea by going back into Figma as an example. The tool that I'm just showing here, or your design tool of choice in Figma, going to the appearance area, clicking on that little raindrop teardrop and applying luminosity and test this visualization with real users. Ask them what is this visualization trying to communicate to you? That really kind of drives this point home of don't rely on color to convey meaning. So going back to our presentation, I'm going to stop here on color and we're going to shift gears. And if this seems like a lot I know that's okay. You can always reference it later. Because remember we have a practical approach for color contrast. We now have a practical approach for making sure that your your designs do not rely on color to convey meaning. But let's take a look at reading order. A practical approach to communicating. Reading order to developers. And as always, we're going to start by getting on the same page. What is reading order? Reading order is the sequence in which content is presented to users, particularly those users using assistive technologies like screen readers. It's how text and other elements are read from the top of the page to the bottom, typically from left to right. But let's simplify that again. We don't want to get into that jargony space. Simply put, let's put the content in an order that makes sense so people can easily follow steps and get things done. Remember what I said before? We're trying to humanize it. We always want to get back to that place of what is the user's job or goal. I find it easier to internalize these concepts than memorize these big definitions as we're moving through. So why does it matter? Well, assistive technology like screen readers do not have the ability to see a visual hierarchy. We need to tell it how to see, and we need to communicate that to our development team. Designers spend all of this effort designing a solution to help users solve a problem. We discover, we define, we iterate, we refine right as we're moving through this. And we don't want that problem solved, that solution to a problem just to be for those who can perceive the content when they see it, we need it to be for everybody. So we need to make sure that users of assistive technology are presented the content in the order it should be consumed to solve a problem. If we do not communicate this, someone will have to do it later. And that may not align. That may line with all that work that you did to develop a solution to meet the user's goal. So let's take a look at this in a website and discuss reading order. Make it more tangible. Here we have a website. This has a relatively simple reading order, and I say relatively simple because nothing should be perceived as 100% simple. The website shows at the top a top bar with menu items across and a CTA. There's also a hero with a large title, a subtitle two, and an image of books. Lastly, there is a testimonial section with five cards. Each card has a short line and the company name. Let's quickly walk through the logical reading order. So when we're looking at this website, we talked about top to bottom and left to right. As a logical reading order, we could say that the user would read across. We might hear that popular scanning pattern. They might read the logo in the top bar, followed by the home menu item about pricing and start a free trial. They've gone across that top bar. They come back and they might read this title of a website about reading order followed by the website is here to demonstrate the meaning of right. And then we have start a free trial. Contact us and then remember when we talk about reading order, this will be read out to screen reader users. And then we get down to the testimonial section. So it kind of follows pretty cleanly that idea of top to bottom and left to right. But I'm going to shift the content around. We're all familiar with those award winning websites that we see where things move, and content is laid out in incredible ways. And what I'm going to show you is truly an award winning website to nobody but my mother. It is not pretty. It is not great at all. So I just moved the content around on this same view. This website now shows the same top bar, but I removed that CTA. So we see logo home about pricing. However, in that hero section that the big title of a website about reading Water and that sub copy of the website is here to demonstrate are no longer stacked vertically, they're horizontal and in line. So now and then, in the middle of the page, there's a start a free trial button. Right. And below that is that image of books which would get read out. And then going back below the fold is that contact us. We changed the reading order. But think about the user's goal. What if the user's goal is to contact us? What if that's a secondary goal? The user has to navigate through that image of books alt text to get there. We really always want to attach reading order to the goal, and I don't care if a person is trying to fill out a form. If a person is reading a blog article, if a person is using a product for their daily tasks, there's always a goal. So let's make let's take a look at what I mean when I say that practical strategy. So the practical approach here first, as all designers do, we need to figure out what the person needs to do with this site, product page, etc. Second, we determine what order they need to read things in their job or goal. And lastly, we document that order for all break points to communicate developers to developers. And I'm going to pick up the pace a little bit here as we're doing this, to make sure that we get all this content in here. We're showing a very common card design, an image of a majestic white horse. I think it's a horse with a smile only a mother could love. And then we have the importance of brushing technique. Title A description that says A step by step approach to brushing your teeth to make your dentist smile. Now imagine this is one of many blog listing a blog cards that you see on a listing site. And let's ask our first question what is the person trying to do with this card? For the purpose of this, let's say they're trying to. The user is trying to read an article that interests them, right? So we're really trying to define that to attach to the user goal. Now the second question in our approach is what order do they need to read this content to help them determine if the article interests them? And I would say the first is the importance of brushing the title of brushing. Brushing the title importance of brushing teeth brushing technique, followed by that sub copy of a step by step approach to brushing your teeth. Then the image. Even though the image is on top, why is the image on top? Well, without that image, if I removed it, they'd still be able to accomplish their goal. So there are two ways to document this that I like to teach. One is the just using arrows in your design tool of choice. I'm showing for option one, an arrow that starts at the title and goes down to that sub copy, and then an arrow that goes back up. But the approach that I like to personally use is the second one, which is using numbers. And this one allows us in the design tool of your choice to create a little badge. And there are excellent toolkits out there like the CVS toolkit. For this, start with a number one and document that reading order. So we have the number one for the title, the number two for that subtitle, and the number three for the image. But what about a more complicated design. And this is a big one. Remember you can reference this presentation later. And I'm going to move pretty fast on this. We don't just look at those little individual cards. Now I'm showing a dashboard and it's got a lot of charts in the sidebar menu. It can feel intimidating and overwhelming to add these numbers and arrows. It could get messy to communicate, which defeats the purpose. So how do we make sense of this complicated design? Well, we stay true to that approach. First, we break down this complex dashboard into smaller, simpler components, and I recommend even separating them in your file. And for each one of those components, we ask ourselves the same question what is the person trying to do with this? What order do they need to read things to get it done and document this reading order for all break points for each of these components. Then I'm going to ask you to repeat that for every one of these components. And then lastly, you want to put all of these puzzle pieces together. And the reason we're doing that is because now you don't have to document every component in detail for the developer. They can reference that. But you're now having them jump from big section to big section. So the developer knows the big overview of the reading order. And then within each component, they know how to dig in a little bit deeper. But we're not muddying this documentation. And there's a bonus if you do this in a design system, because you only have to do it once. If you document these patterns, you only have to do it once. So let's move on to our last practical approach how to write links that make sense on their own. A practical approach to making link text clear. What do we mean by meaning linked meaningful link text? We always want to get on that same page. Meaningful link text tells users their destination before they click without requiring them to read surrounding content. Users should not have to guess. A common example is the link text learn more. We all have done it. We all have seen it. If you just read that without. If you just heard link learn more by itself, could you confidently say where it was taking you? Let's take it out of the digital accessibility space for just a second. And imagine you hopped into an Uber and rather than clearly knowing where you're going, it just starts driving you somewhere. Would you be okay with that? Could you imagine if you paid all of this money for Taylor Swift concerts and you're expecting to get there on time, but instead you end up at the zoo? That's not what we want to do to real people. So why? It's important because many people who use screen readers hear the words and links on a screen, read out loud, and instead of using and instead of seeing them, that makes it a little bit more complicated when you just say learn more. So let's make it more tangible. Here I'm showing a section called Recent Articles with three cards. Each card represents a different article, and each card has an image, title, text, and a Learn More link. There is also this view all link. This is a very common design because we can perceive all of this content. Then the learn more links might make more sense. We might have a reasonable understanding of where we were going, but now I'm showing you if I just removed all of that visual content and now you just see the links, view all, learn more, learn more, and finally learn more. If someone read just these links to you, could you confidently say where each one of these was taking you? This is a common way of navigating a screen reader. Users might jump from link to link and rely solely on the link text to determine where it takes them. They might navigate that page just by links. This image shows a mockup of the VoiceOver screen reader tool from Max menu for links. It shows the menu title links followed by the Learn More, Learn More, Learn More and View All. This would leave a user guessing where their goes. It could go anywhere. It could take us right back to that zoo that I talked about before. When you want to go to the Taylor Swift concert, I really have nothing against animals. I just want to point that out. So let's really take this practical approach and drive it home. If someone read just the link words to you, would you know where you'd go? Always ask that question. Let's quickly try it out. Looking back at Learn More. If someone read just the link words learn more, would you know where you'd go? The answer is no. Let's make the answer yes. Now I have that link text saying Learn Digital accessibility. If I just heard the link text learn digital accessibility and only the link text could I tell where it's going? Probably. You'd probably understand that it's taking you to learn about digital digital accessibility. And the tip that I use here is a verb and a noun to make it more clear, but let's look at a more complicated example very quickly. What if it opened a new tab in the browser window? Some say you could add an external link icon, but that is not universally recognized. What I would recommend is just putting in that open digital accessibility guide in a new tab as the link. If you heard Open Digital Accessibility Guide in a new tab, could you confidently say where it's going? And there are issues with long text? I totally get it. But I'm asking you to be clear. So in summary, let's bring what we close at. Let's bring it all together. Today we learned a different way for color contrast, a different way to approach it. We learned how to make designs work without depending on colors, and we learned how to determine and document the reading order. We learned the basics of meaningful link text. And that leaves us with one last question before we go. What is the color contrast requirement? Content. If content is needed for a user to complete their goal, don't answer it in the chat. If you got 4.5 to 1, great. If you didn't, that's okay. And now questions, thoughts, concerns, fears, challenges, spoiler alerts, cookie recipes, favorite quotes, or incredible poems you all want to share. Shawn, take it away. >> Great job Eric. Thank you so much. The attendee interaction in this presentation was amazing. I have to say, I was trying to keep up with just the chat alone and it was intense. So again, thank you Eric. Let's start off with some questions for you though. The top one that I'm finding right now, I think you'd be great to help our audience. What do you mean by break points? Regarding document this order for all break points as the as the third directive for reading order. >> Great question. So for the purpose of this conversation, we know that we might. And I'm going to use specific semantics with this. We might design for desktop. We might design for tablets. We might design for mobile. I like to think of break points as different sizes in that regard. But we know that designs sometimes shift content around in adaptive design. It might not be truly responsive, so an item might move to an unexpected location. We want to be clear that we are capturing that. Does that content move around, and do we need to address that for the developers so they don't assume the reading order as content may shift from from screen size to screen size to screen size. Now I will also add to this, Shawn, because we've talked about this before. Ideally we want to design not just popular patterns. We want to start to question. That doesn't mean we challenge familiarity, but we want to really design. To say it shouldn't shift. That reading order is the same regardless of the screen size or the viewport size you're looking at it. So when your document it, document it for where they will see all of this different content on desktop, on tablet, on mobile, or if they're zooming in on a desktop and you're seeing that smaller experience, make sure if content shifts you are capturing it, but avoid it at all costs. >> Awesome. Here's another great one. I think this will kind of fall in line with your your presentation today. How do you explain color contrast? Simply to folks new new to this. >> Is so going back to this, I'm going to kind of move us through. Please ignore as I shift through this presentation really quickly. I don't want to make anybody I don't want to challenge everybody too much with this, but I think it would be helpful. So I really lean into this color contrast explained simply when I say the difference in colors, that makes one thing stand out from another. I mean it, and I would recommend you could leverage a visualization, but you could talk through it a little bit more. So when I explain this to small children, I like to think of color contrast as a zebra with zebra stripes. Right. If the contrast is really poor and low, you can't see those stripes on a zebra because it is one color standing out from another. But if the contrast is really strong, then a person could see those stripes big, bold and beautiful on that zebra, right? So to me it's the way of saying, can you see something stand out from something else? And I would also be really I want to really make this a point. It's not just on solid backgrounds. We've been showing examples of link of text on top of a button, but when we are saying it needs to stand out from another, all of those beautiful designs that have a gradient with text over it. Think of the complications of testing that for color contrast, you have to make sure that at every touch point that is really that the text is legible. It's the color. Contrast is good. So you need to stress test that same thing with moving image, with moving video. And when you have images, that makes it harder. So to put it simply, what I would like to do is explain to someone, can you see this color on top of this color? Can you read this content on top of this color? I think that's pretty much as simple as I can explain it now, but if there's a better way in the chat, please let me know. I am all about learning something new. I also got to talk about zebras, so I feel really good that I'm watching all of these things with my young son. >> All right, let's see. Doing a time check. I think we have maybe two more. This one was another hot one. Where do you draw the line between decorative and meaningful images? Which one should have an actual text? >> So this one I want to be clear on this. I would absolutely check with subject matter expertise and dig in deep and make sure you are clear when you are with the WCAG success criteria. For me, when I think about alt text versus non alt text or decorative, I go back to that sentiment of does the user need this to understand the content on the page? So when I look at, for example, an icon in that button download, does it need alt text? Does a user need to here download icon and then download results when they're looking when they're hearing that icon out I would say no. The way I like to think about that is if I removed that image, that content, does the user lose any meaning of the content on the page? Will they not be able to accomplish their goal? So that's how I like to think about it. I like to think of it as a I keep bringing it back to the user and those goals. If I removed something, if I removed the image, the icon, will the user not be able to accomplish their goal? If the answer is yes, include alt text. If the answer is no, it doesn't impact their goal and it's just redundant. It's just there. It's decorative. Then don't worry about the alt text, but confirm it with your in-house subject matter experts and ask the community. Remember, you got to dig deep. There's some subjectivity here. Also, the best way to do this don't just rely on my statement. Test it with real users. See what happens if that. If you don't have alt text, can a user test that? Can a user still accomplish their goal? Don't just take my word for it. We are not the users as that popular sentiment, and we have bias when we're looking at this. >> Awesome. All right, we got room for one more. The last one is can I use an icon and an aria to say will open in a new tab rather than the long anchor text? >> So when we say Aria just for everybody with the beginning presentation, we're talking about what's these programmatic labels. Right. So if you were to say can you make an a programmatic label? What I'm saying here is the user doesn't see it on the screen, but if you read it, if they heard it in a screen reader, it would say opens in a new tab. And I totally agree that you can do that. But I will challenge something here for everybody who isn't aware. Look up, read about the curb cutting effect, what's good for all, what's good for most is good for all right. It's good for some is good for all. And that means don't just think about the person who is the person who can't perceive that when they're looking at it. Think about persons with cognitive challenges and disabilities. Think about people who aren't familiar with the technology. Think about all those users. Would they know when they clicked on that link if we didn't expressly say it to them that it's opening up in a new tab? Could it be jarring? I like to think about my mother asking me questions about technology, and that would be new to her and it might get lost. So yes, you can edit programmatically into the code, but I would still challenge you. If it's good enough to be in that code, then shouldn't it be clear to users who can read it and see it? Also, that fist pump I think really drove the point home. Did it look cool? I hope it looks cool on YouTube. >> Thanks so much Eric. Thanks for this great session. Friendly reminder. You can continue the conversation on our community discord if you haven't already. You can join via the link posted in chat. Be sure to also share your experiences on social using the hashtag Axe-con and enjoy the rest of Axe-con everybody! >> Are we good?