- [Stefani] Okay. I don't know why it hits recording right away, but it did.

- Hello, everyone.

- [Stefani] Hello, I'm gonna get started.

- We'll start in just a moment. Hope everyone's having a good day. Hope to a good start.

- [Stefani] Yup. I'm gonna get started shortly. We'll begin momentarily. Okay. All right. Well, good morning and good afternoon. My name is Stefani Cuschnir. I am a business development manager here at TPGi. We're gonna wait one more minute just so that everybody can come into the session. Hang tight and we'll get started shortly. All right. Very good. Thank you everyone for joining us today. You're here for the Understand, Test and Solve series. Today, we're gonna be talking about color contrast with Aaron Farber. I'm gonna cover a few housekeeping items and then hand it off to Aaron. This session is being recorded and we'll email everyone a recording after the event. We have a cut... We do have captions available, so feel free to use them as needed. And lastly, there will be time for a live Q&A. Please use the Q&A box. You can find that at the bottom of your panel. And we'll answer as many questions as we can at the end of the presentation. If anyone needs any accessibility support training or usability testing, we will be sending out an email with a link to schedule a time to speak with one of our experts. With that, I will let Aaron get started and provide an introduction to himself.

- Hello, everyone. Good morning. Welcome to the Understand, Test, Solve Color Contrast webinar. My name is Aaron Farber. I'm senior platform consultant here at TPGi. Before I get into my role here at TPGi, let me give you a little bit about my own background. In 2016, I changed careers from public policy, political realm, to tech, and I attended a coding bootcamp called App Academy. Following the coding bootcamp for several years, I ran kind of my own accessibility testing and development shop, you know, focused on small businesses, really the kind of organization that would use WordPress or Shopify. Then in 2019, I joined TPGi as an accessibility engineer working with, you know, some of the largest, biggest brands in the world. And in that role, I primarily served as an accessibility engineer, what you might think of as kind of a WCAG auditor. In 2021, I shifted here at TPGi to supporting 100% a very large tech company. And now, for the last, well, since 2022 now, I've supported organizations using our ARC platform, which is part of the reason that we're here. Of course, I think that the lessons that we go over today really apply to everyone, you know, however you are solving your accessibility issues. So here is kind of our agenda for today, is first to plan for accessibility testing. Second is we're gonna talk about keyboard focus styling, which overlaps really with non-text color contrast. Then we're gonna go over text color contrast. And lastly, non-tech color contrast. So first, a note about what I do here at TPGi and kind of the origin for this Understand, Test, Solve webinar series. In my role, I primarily support the ARC empowerment program, which trains organizations to plan and execute in really every area of accessibility. And the fundamental goal there is for organizations to create a repeatable, well-defined accessibility testing process, and to empower teams to address issues one-by-one while growing their understanding of accessibility over time. So the goal today is, you know, partly to go over that workflow within ARC and its related, you know, tools and resources. You know, a fundamental thing that I've learned in this, you know, so in our empowerment program, get the opportunity to work with big organizations, smaller organizations. And one of my, you know, kind of fundamental takeaways from this experience is that you know, the lack of accessibility buy-in that, you know, people may know that their organization, it's not due to a lack of will or skill or even empathy perhaps, but it's due to a lack of clear steps. It's people not understanding necessarily how to go about achieving this multifaceted complex topic of accessibility. So each month, TPGi is holding a webinar to cover one group of accessibility guidelines. You know, one fundamental concept in accessibility. And the structure is always the same. And I'm not, you know... Perhaps some of you attended some of our previous ones. This is gonna last for about 30 minutes, something like that, maybe a little less today. And then we're gonna have 30 minutes of Q&A. I really see this webinar series as a resource for our community. So your first step right into it with planning for accessibility testing is you have to create a test plan. Divide your application into a set of representative samples. It's not feasible to test every page or every part of your site. 100% test coverage is not the goal, it's a representative sample. So for example, before setting up monitoring or even going about your manual testing, here we're looking in this slide, we are viewing a screenshot of the top of the TPGi.com website, and we can see, you know, it's a very traditional website. But now, we're gonna look at how to start dividing it into component. So here now we have a picture of the... This slide displays a picture of the TPGi website. We have a kind of a header that includes, you know, login and contact information that is highlighted. Then we have another section of the navigation bar that contains navigation links, ARC platform solutions resources about blog. And then we have the hero section along with the call to action button highlighted as another component. And, you know, this is a fundamental step to take at the start of accessibility testing 'cause it allows you to, one, start dividing work amongst your team and it allows you to work on accessibility at a cadence that kind of fits your organization. My own philosophy is that, you know, any progress is better than no progress. Slow motion is better than no motion, right? So when you have broken it into components, it's easy to start delegating work and it becomes easier to track your progress over time and understand the source of issues. And for most larger organizations, right, you have multiple teams probably working on the same application. So when you break it into components, it becomes easier to, again, delegate that work. Now, after you break your site into, you know, these components, these test samples, your next step is to group related accessibility guidelines. So it depends, you know. At the empowerment program, we see people do accessibility testing a lot of different ways. Some organizations, they have testers that really just own an application. They're testing it from start to end. Others, they have multiple people on the team. But I find for most organizations, especially smaller ones, you know, accessibility testing is a responsibility that is kind of diffused but it's shared by multiple people. Well, so when you group related accessibility guidelines, it enables testing to be done by roles with just the requisite skillset and it increases efficiency and reduces duplicative work because you're no longer shifting between unrelated accessibility guidelines, right? If you are simply just going from top to bottom, you know, through the tag success criteria, the web content accessibility guidelines, the prevailing standard for online accessibility is made up of, you know, perhaps, you know, probably 50 accessibility guidelines, if you are doing it at level AA, which is kind of the norm. If you're just going down through that list numerically, you're shifting from screen reader testing in a sense or color contrast testing to keyboard testing, these very different activities that really call on different skillsets. And lastly, when you group related accessibility guidelines, it leads to full WCAG coverage, because you know exactly the concepts which you have covered. You can easily understand that 'cause you have different user groups covered and you know the ones that have not. And again, you know, my own philosophy with testing is that we need to put these into terms that, you know, people understand in people terms. Okay, so onto color contrast testing today. Why is this a group? Well, because it does not require an engineering background to test or, you know, familiarity with assistive technologies. Color contrast testing really only requires basic familiarity with developer tools. That is when you inspect on a page, you can view the underlying code, right? So when we're doing color contrast testing, here's kind of the guidelines that go together. There is first of all 1.4.3 color contrast minimum of AA, 1.4.11 non-tech contrast, 2.4.7 focused visible, 1.4.5 images of text, which is partially covered, and 1.4.1 use of color, which is partially covered and not so much the focus today. Now in practice, use of color may be the most critical issue because typically when you are using only color as using color as the only means of conveying information, well, you're likely excluding screen reader users, perhaps people who are colorblind. So that can be the most significant issue, and that is something that cannot be tested via automated means or that's something that requires your own human judgment to understand how color is being used. No computer has the fine grain intelligence to do that. So the first step is accessibility foundation. That's a fundamental step in the ARC empowerment program. So the empowerment program, which is kind of what we're doing today, leading people through a logical sequence of creating a robust accessibility program. And the first step is to have a foundation of accessibility knowledge for keyboard accessibility testing or color contrast testing. Simply the modules, you know, well I should say actually, so in the ARC platform, we provide a set of self-paced accessibility training modules, which are role-based. And what is great about role-based training is that it is only containing the information pertinent to those roles and it can usually be consumed between 15 to 45 minutes probably for each of these modules. And when teams have this foundation of accessibility knowledge, they work much more efficiently and accurately as they move progress through issues. Now in the ARC platform, and again, the things that we're talking about ARC today really just apply to all accessibility solution, which is that in ARC, the knowledge base is your single greatest resource. ARC's knowledge base contains our documentation on using the ARC platform, as well as resources on iOS and android development, web development, how to do UX research, and just a really wide array of accessibility topics. And so this is really should always be your first resource for looking for support. So now onto Understand, Test, Solve, why is that the name for today's session? Because the ARC platform at the platform's core is ARC Monitoring. ARC Monitoring essentially is a set of automated accessibility rules being run on your website, your web application. And the main strength of automated testing is that each rule is mapped to select tailored resources within the ARC platform. And with these resources, it's really a three-step process. So for each rule, we provide, first of all, the WCAG reference module. Well, this is the understand step. Understand the accessibility, the significance of an accessibility guideline first. So the WCAG reference module summarizes each accessibility guideline. Next. Well, now, before understand step, you're not even really interacting with code, you're really first understanding what is the significance here. So they say you can't automate something you don't understand. Now test, well, we have to test an issue to determine its impact on user experience and to verify that it's a legitimate issue. Yeah. So for each rule, we provide the excerpt from our WCAG test web module, which provides step-by-step manual testing procedures for every accessibility guideline. All of the content which I go over today, it's kind of listed from the WGAC test web module, and I'm pulling out actually this is a very small amount, you know. Not anything that I go over today is due really to my own experience or expertise, anything, it's really just from our resources, yeah. The last step. Now we've understand the issue, we've tested it, we determine its impact that's legitimate, last step is solve. Solve an issue with battle-tested clear steps for implementation. Each rule, we provide a excerpt from our accessible web content development module, which provides code samples, expected behaviors that allows you to retest and validate the solution. All right. Now that you have your fundamental training completed, you have an understanding of accessibility for your role, the next step is to equip your team with the relevant testing tools and assistive technologies. Although not today 'cause we're going over color contrast testing. So that is Color Contrast Analyzer and ARC Toolkit. So the Color Contrast Analyzer allows you to enter color values or use its eyedropper tool What is great in the Color Contrast Analyzer is free and can be downloaded from TPGi.com. It works for Windows and Mac. And what's great about the Color Contrast Analyzer is it works at the operating system level. So you can grab any two pixels on the screen, not just within the browser. Now, let's talk about color contrast text requirements first. Text and images of text must have a contrast ratio of 4.5:1. Large text, which is over 18 point, you know, tech size or 14 point bold, you know, must have a color contrast ratio of at least 3:1. Now why? Well, text that is larger and has wider character strokes is easier to read at lower contrast. Now in ARC Monitoring, and this is a question that I feel arises often, is, you know, how we handle color contrast within the platform? Well, in ARC Monitoring and we're viewing on this slide a screenshot of a monitoring dashboard within the ARC platform. And we can see here that we have, for this scan, we scan three pages, there are 78 errors and each error is mapped to a WCAG failure, and we have 126 color contrast failures. And then you notice in the performance summary section, we have the WCAG 2.1 density, which is the density of automatically detected WCAG violations on these three pages. So 78 divided by 3, that is 26. And notice that color contrast failures is not included in that figure. In the ARC platform, we display the number of total color contrast errors. We do not display the individual errors and that is for numerous reasons. First of all, that a single line of CSS can cause hundreds of violations of CSS, I should say, of color contrast. Secondly, background images, absolute positioning where elements overlap one another images of text, A color contrast is actually quite difficult to test for via automated means. So our expectation is always that our users go to the site, go to the URL and visually manually inspect the issues. So now our toolkit, it's important to understand its relationship. And our toolkit I should note, you know, is a free Chrome extension available in the, again, from TPGi.com, or just, you know, Google it, of course. And our toolkit is essentially used as the same rules as our monitoring, as our platform. Our toolkit allows you to scan essentially anything that is within your browser. So you can easily scan pages that require authentication, specific points in user journeys, or even local file URLs. So here, let's understand the relationship between ARC Toolkit and ARC Monitoring. ARC Monitoring displays test results, it displays HTML code snippets, and gives you access to all of ARC's tools and resources. So here, we see a screenshot of a form control issue. So we see for our monitoring, we have input has no accessible name as the rule. And if we were to zoom in here, right, like it's fairly small I realize. Like we have a set knowledge base resources for that rule so that you can go through the understand test all process. Whereas for our toolkit, you go to the URL and you can run the tests and view these elements visually. You can visually inspect them, which, again, is helpful for people that don't necessarily live in code, like, you know, the engineers here. And with our toolkit, you manually inspect those color contrast errors. So when you are testing color contrast for text, the best practice is to compare explicit author defined CFS color values, that is the hexadecimal codes. So on this slide, we see a screenshot of Chrome developer tools where we select the text element in the HTM elements pane. Then in the neighboring styles pane, we view the CSS, we view the color, which is the text color and the background color, which is . And so that's how you will find out the color values. Once you have those color values, enter them into the Color Contrast Analyzer. And you'll notice here in this screenshot of the Color Contrast Analyzer that it provides the color contrast ratio, it's 5.5:1 in this example. And it states whether it meets WCAG requirements for the different tech sizes. So, again, link, it provides that information right out. And it's also I find that this is very helpful, the Color Contrast Analyzer for providing screenshots about color contrast. Now when you are comparing texts, there are two important exceptions. One is for disabled interactive controls. So when a control is disabled, that is a person cannot click on it, cannot activate it via keyboard, text color contrast requirements do not apply. Makes sense, right? That people should... You know, if people are supposed to, in a sense, ignore that element because it's disabled, right? And the other exception is for branding. So for branding where the color contrast, or I should say not the color contrast, but the colors of the branding are critical and the visual presentation of that branding is critical to understanding its meaning that has exceptions for color contrast for tech. So now it's important to understand that branding does not refer to your entire site, you know. So when you have just backgrounds, you know, you just have background colors in tech, that isn't necessarily your branding, like that's really part of your website. So really branding is fairly limited, right? Like it refers to like your logo and that kind of thing. Actual UX copy, you know, and parts of your user interface, I would not consider that part of branding and we can definitely have questions about that at the end. Now a note about the eyedropper tool, okay. So as I said, the best practice is to compare the author defined CSS values, which we graph from developer tools. Well, we use the eyedropper tool. Why don't we just use the eyedropper tool? Well, it's because your monitor calibration profiles affect the color value drawn by an eyedropper tool. You know, think about when you have a TV or your computer screen, right? Like video game mode or like night mode, those things affect the values pulled by an eyedropper tool. Therefore an element could pass on one device and fail on another. So the best practice is to be device agnostic. So when do we use the eyedropper tool? Well, we use it for images of text, chart and graphics, all the content that doesn't have a defined CSS value that we can just pull from. So for example, let's look at non-text color contrast here. So non-text color contrast requires 3:1 color contrast between elements, and it refers to UI components and specifically graphical objects. Now, a note about UI component is that don't perceive non-text color contrast requirement as meaning that the borders of a button have to have, you know, a certain color contrast with the surrounding background. So color contrast, right? Like these people that are affected by color contrast can view the screen, right? So the positioning of the UI component, you know, a button and so on, these things have a great effect on people's understanding of the page. So it's not simply that hey, you need a border that has a certain thing, a certain that has 3:1 color contrast with the background. So really in context in my own personal testing, non-text color contrast most arises where it's dealing with graphical objects. So in this slide, we see a picture of the United States and we have a gradient, a color gradient being used for the different states, which ranges from 4.5 to 6.7. What that unit is, well, that's a mystery, right? But it doesn't say in the legend. But the point is here is that the 4.5 is a light blue and then 6.7 is a slightly darker baby blue carry winkle something of this like this. Right, this is a classic failure of non-text power contrast because we cannot discern the difference in rank between these states. And yes, the states have a border, but again, you know, if we can't tell the difference between them. So when we're testing this, really our concern is we would really be testing the color contrast of like neighboring states. But how do we solve this issue, right? And this is my last thing to discuss today because really there's so many different ways that we can solve for graphical objects lacking sufficient color contrast. Well, first is we can use patterns. Rather than rely on colors alone, we can use polka dots or stripes to represent different states. Alternatively, we can use data labels. So we could simply just put on each state. Nebraska 5.0, Oklahoma 5.4, and so on. And then color, we're not relying on color as the only means of conveying information. And for me, you know, WCAG is objective. So multiple testers should reach the same exact conclusions when they're providing a WCAG audit. So perhaps this also could be seen as a use of color violation. There's no other means of indicating the different categories. And that's where I'm kind of getting at, that like use of color is really requires your own human judgment, and it's kind of a more catchall accessibility guideline than text and non-text color contrast. And I should say also that non-text color contrast applies to focus visibility. That essentially when you have a focused outline, the pixels that is replacing a screen, there has to be a 3:1 color contrast ratio difference. Now, before we head into questions, I will note that I have done this presentation through the vein of WCAG 2.1 level AA. In the ARC platform, we provide all of the resources for WCAG 2.2, which also uses the same rules surrounding color contrast, although WCAG 2.2 has a lot of additional success criteria. Just to clarify about focus visibility, that that's a color contrast issue essentially. But in WCAG 3, which is to be released in future, they will be using a different ratio, a different algorithm to determine color contrast ratio than what has been used in WCAG 2 to this point. And I will note that when you use Chrome developer tools to test for color contrast, you are using that new color contrast algorithm, not the traditional one that we use for WCAG 2. So just wanna clarify them. I'm happy to answer questions about that. I just did not cover it today so much because it's not actually the accessibility standard currently. So with that said, I'm gonna start looking at the questions. And this is great 'cause I think the questions are best when we start getting into the weeds. Yeah. So all right. I'm gonna start opening them. I see we have chat enabled. Great. I just typed this query into ChatGPT. Well, I'm gonna ignore that for now. And put that as my least comment 'cause, you know, I prioritize human beings. So does the requirement for color contrast ratios apply when using inverted color or other color options? No, it does not, because that is something that is being applied by the user, not the website, right? And this one reason I did not go over high contrast mode is that WCAG does not specifically test for high contrast mode. There are so many kinds of color contrast enhancement or color correction tools out there that people use. Visual impairments is such a wide spectrum of issue of different ways that people have challenges surrounding color. So really the reason that we have images of text as a WCAG requirement is because when you use images of text, it prevents people from applying their own text formatting style to a website. So the requirement for color contrast ratios is not concerned with how the change is, how the user is mutating the page. The requirement is simply that pages can be manipulated and changed. So that's why images detect is an accessibility guideline. Just to explain that. And it's a great question I wanna include in the future because now that I'm thinking about it, it's really an interesting topic and you can see it makes sense, you know. WCAG's authors were very precedent in how they came up with these rules. Okay. Can TPGi conduct user testing of my form scratched new website? It'll be completed in six months with people who are my target audience, cognitive and visually disabled. Yes, at TPGi, you know, we do user testing, user research and we can provide design reviews. Yeah, please reach out to TPGi through the website and they can facilitate that. And yes, we do have a special testing audience that we do convene in-person and I think we can also do remotely. So it's really a great way to go about things. And when you do review at that design stage, you prevent issues from reaching production where code is rigid and it's hard to changing. Okay, next question. As per surveys, most of the colorblind people can perceive only certain colors like blue, green. So does this affect how we test for color contrast and color alone? No, I don't think so, because we have the guidelines that we are applying then. And WCAG and all these surveys about visual impairments, you know, they're kind of separate things in a sense. But thing to keep in mind here again is that people, there is such a wide spectrum of visual impairments. It's about creating sites which can be manipulated by people, you know, with their own text formatting styles. And also, using our common sense that when we are using, you know, significant color contrast, when we don't just skirt at the minimum ratios but we actually like, you know, excel at that, you're gonna support, you know, this wide group of people, with, again, all types of visual impairments. So I don't feel that it affects how we test it. It's just about having empathy and appreciating where color is being used on your site. And again, you know, most times when a site has low color contrast, it disadvantages certain groups of people but it perhaps, it's not disabling, you know, it does not necessarily prevent access from the application. So, you know, that it's really more about thinking about use of color and whether color is being used as the only means of conveying information. Does the color contrast to cool tool use the WCAG 2.2 color contrast ratios? Yes, it does. And I'm sorry for my own confusion explaining it. Yes, WCAG 2.2 uses the same color ratios as previously. The overhaul. And again, like just WCAG 2, 2.1, 2.2, to meet 2.1, you have to meet 2. Meet 2.2, you have to meet 2.1. Therefore those are... What's the word where you're like adding? They're like compound, added, you know. They're like supplementary. They're building on previous versions of WCAG so they can't, you know, go back to WCAG 2 and change the color contrast ratio algorithm. So that's gonna be done in the future with WCAG 3, which I'm not even sure when it's planned to come out. I think like 2026, something like that, like it's pretty far off. So it does use the WCAG 2.2 color contrast ratios. Again, the thing to keep in mind with WCAG 2.2 is that it is mainly clarifying kind of ambiguity in WCAG requirements, okay? So like we said, like with focus visibility, that is always been like previously like testers here at TPGi would flag issues of an element not having sufficient visual focus into care. And to clarify, you know, back 'cause that was our previous webinar and for people that missed that. Keyboard focus is the element on a page that is open to receiving keyboard interaction. So, you know, people that use the keyboard to navigate the web, they press the tab key to move from one interactive element to the next. So previously, you know, it's very important that they are able to visually determine the currently focused elements. So when the focus indicator was barely perceivable, when it lacked, you know, testers would flag that as a non-text color contrast 1.4.11 issue. However, in WCAG 2.2, they've added additional success criteria. Just to clarify that ambiguity that, okay, really, that focus visibility is in scope. And there was always some question amongst people whether it was just because of that ambiguity. So just to clarify that. Next question. Does WCAG requirements apply to dark mode as well? No, they do not. Because again, that is about applying. People are gonna use all different types of textile link to apply to websites, you know. So for example, one of my best friends is colorblind and he doesn't actually change any of the color like I see him like when he uses his computer, but he doesn't actually change the color of a site at all. In his tool that he's using, it just changes the text to different font. So I see like when he's like coding or something, it's like something's recursive or, you know, others are small caps, other things are like Times New Roman. So he's using those differences to understand it, not dark mode or anything like that, which drives that kind of the point that I keep restating here, which is that most important is that you are allowing users to apply their own text formatting styles. So do WCAG requirements apply to dark mode? I say yes when it comes to images of text, because when you use images of text, it prevents someone from using dark mode, light mode, any mode, right? Yeah. So that's really how it applies. And I will note that images of text has an exception for which is the same as what we discussed today, which is that you are allowed to use an image of text when the visual presentation is critical to understanding the meaning. So in other word is branding. And you cannot easily recreate branding using CSS. Right, like let's think about like the Coca-Cola logo, which is cursive, or let's say like Cabela's maybe. Like, that text cannot be easily recreated using CSS, therefore, it's exempt. But we really associate that text with those brands, therefore, it's exempt. Next question here. If an app provides both light and dark mode, both of them should respect the color contrast and WCAG rules or is one enough? You know, that's a really interesting question. That's a really interesting question. And before I... You know, I wanna start just by answering that question just a kind of like a higher level about accessibility in general. Many people are interested in accessibility because of concerns about legal and reputational risk. Lawsuits and public, you know, protests of things, right? That does not come about from WCAG violation. Maybe in a superficial sense. If you were to receive an accessibility complaint, it's because someone cannot access your site. So when I hear this question like kind of like we're fixating on the finer points of WCAG compliance, which I think is fascinating, of course, like it's fun to talk about and, what's the word? I always say it's like tell ludic, right? Like we're like debating the finer points of it. But really it's more theoretical than practical and realistic, right? Because if someone can use your application using both light and dark mode or using one or the other, like they're not prevented access. But with that said, so I wanna say that before I get into the WCAG rules, because my point is that accessibility is about ensuring everyone has the same experience, is able to access an experience. This question to me drives at usability about ensuring a better user experience, which is not a legal matter but just being, you know, good site owner being, you know, providing a high quality user experience. So in terms of supporting both, I feel like when I've heard in the past is that if you are specifically providing light or dark mode, they must be follow color contrast rules, because in that situation, the user is not applying their own text formatting styles, you are providing them to the user. So I would say, let's go down the rabbit hole. I think that WCAG rules do apply to light and dark mode if someone has a contrasting view. No pun intended. Please provide that in the chat. I think it would be interesting. I love the topic and it's a great question. I think one is enough though, you know, personally, because again, like someone can use your application. And another thing I will say about this is that... And, you know, this kind of like a topic that TPGi and a lot of people on the accessibility kinda harp on a lot is these accessibility overlays. These things that, you know, can fix the site of your website, you know, in an automated manner and the code is not specific to your website, right? It's just the plugin that you apply to any website. Here's the problem with that and it really draws the color contrast. People, the internet is so diverse, we can't even like comprehend it. Okay? So people are coming to your site using all different types of like color correction and color enhancement tools that we don't even know about, and solving for issues you didn't know that people had in a sense. A site cannot predict exactly how people are going to do those things. That's the issue with those overlays 'cause they're just saying like, hey, this will fix the color contrast, like this is for people that need that. No, it's such a wide spectrum. Like those people come to the website with their own tools, which they normally use throughout the day. Just imagine like entering a store and someone like said, take off your glasses, like put on this pair instead. So anyways, my point is to all of this is that it's about providing an interface which can be customized by the user, not necessarily doing that customization for them. If someone really values dark mode, create your site in a way that works with those kinds of technologies. But again, not discourage to use dark mode because I'm a dark mode user myself. But just keep that in mind here. Great text on white or black was invented by Satan. Hey, you know, maybe, you know. How do you really communicate the importance of human testing for color contrast to address this or other issues, or providing other accessibility settings or options to allow users the options they need to understand the content and context? Hmm. Well, how do I con communicate the importance? Well, you know, that's a really interesting question. You know, I think people take different approaches. Some people like to talk about, you know, the empathy for disabled people, people that would be prevented access. I think others like to note how accessibility, you know, creating an accessible experience, like supports larger business objectives. So to me, like here's the thing about accessibility is that when you build a site with accessibility in mind, you make your site open to a wider circle of people and that's great and that, you know, is something that's compelling to people. But more than that, which I think is kind of the other case that I make is that when you build a site with accessibility in mind, you create a better website for everyone. So, you know, people are, I defer, I think of my old coworker, you know, who said selfish accessibility, meaning that he wanted an accessibility feature for himself. That's what I think of. It's like that's a really compelling argument to people. So maybe with color contrast, you might reference that like, hey, 50% of web traffic is on mobile devices. When people are outside viewing their phone, there's much lower color contrast. So therefore it's especially important to provide high color contrast. All right. So that's my response there. And it's a great topic though. But anyway. Okay, so Elizabeth Dunn. Isn't it important to note that when you selected fine CSS value, you must also examine CSS determined styles also applying any filters on the color, such as a transparency level? We pulled that text away. Is it here? I don't see that.

- [Stefani] It's in the answered section, Elizabeth. Sorry about that.

- No, it's okay. So fine. So okay. So that is a great question, Elizabeth, and that is a nuance that I would like to add to this webinar is that when a text has transparency or, you know, the CSS value is not accurate, as you noted, like we can't compare that, therefore that's a situation when to use our eyedropper tool because as I said, we use the eyedropper tool when the CSS value cannot be used alone. And so that is a really great point that you made, and thank you, Elizabeth. So it's definitely something I'd wanna note in the future there about another situation when you use the eyedropper tool is when text has a transparency level. A great point, thank you. All right, let me see here. What is a good way to avoid contrast problems? Well, you know, this is really... This webinar is focused on testing color contrast and maybe to change it a little bit in the future. But the way to avoid color contrast problems I feel is to have a defined color palette for your website. So, you know, that you have three or four color combinations that you're gonna use, five that you're gonna use throughout your site. And it's kind of like your brand identity. So I think it's just using a brand identity that has sufficient color contrast and then just being loyal to that brand identity. I think that's the best way to avoid color contrast issues. I think most color contrast issues arise probably just because, you know, people are just kind of creating that interface ad hoc, like it's not part of any larger vision, I should say. And also, I think that when sites have, you know... Because, you know, I recall once I worked on a website where the entire website was like orange and used black text, like dark orange and black text, because that was part of their logo, like they did tanning, you know. But the point is there is that like their brand identity lacks sufficient color contrast so they themselves are not aware of the issue, they're just using their brand identity and that's where I'm driving at though, like when you have like a color palette that you know is accessible color contrast, like you can just use that widely and removes that guesswork for people that are maybe not like as well-versed on accessibility questions. So personally, I'm a big fan of a mood board, you know. I think that's a great thing to do when you started, when you're working on your business is just create those color combinations. Okay. Now next. What about color or in infographics or more complex images? Or what alternatives are there to make these resources more accessible? Okay, a couple things come to mind. First of all, as I said, we can use pattern, we can use data labels, we can make the colors between adjacent parts of a graph more distinctive, meaning that we can like have like 3:1 color contrast rate. We can have like this picture below here of like the United States, right? Like we could have found a couple of different colors that have 3 to O color contrast with each other, like three to O ratio with each other. So that's one option there. I think another option to consider, which again we're getting at like the finer points of WCAG compliance, but I think another option is you could provide the information in this picture of the United States in table format. So therefore if someone is unable to understand the colors within the map, they can use the table. So that may be accessible on like a legal level whatever, but I don't think that's a very good user experience. So I think maybe the best way would be to have like some kind of like feature where you can like enable data labels or you can view the graph in different manners. I think really again like accessibility, like so many accessibility issues can just be solved with providing the same information in different formats. So I think those are all ways. Patterns, data labels, tabular format allow user to do customization. You know, maybe when you are using a charting library, be sure to consult the accessibility documentation and see if they provide those kind of color contrast customizations. So for example, here at TPGi, we often recommend that people use Highcharts. Highcharts is a free charting library. Highcharts, out of the box, provides power contrast customizations. You can basically allow users to add data labels or to do patterns to do those kinds of things. So again, like that's something not to endorse pie charts so much, but just to endorse looking at documentation and determining whether it has those kinds of features. You mentioned large texts as in 14 bold and 18 point font. Is that referencing WCAG? Directly. That's right where I got it. Yeah. Last question it appears or maybe, I don't know. So then maybe I'll look-

- [Stefani] Aaron, there are several questions in the chat but if we don't have time I guess we can .

- Okay. So last, are the info buttons or tooltip or X close buttons part of text content or non-text content? They're part of text content. So again, like those are, you know... Again, like non-text content really refers mainly to parts of like... And really now that I'm thinking about it, I wish I said this earlier. Is that like non-text content would be when you have like an icon within a button and you need to be able to understand what that icon is indicating in order to understand the control. So, you know, if you had... An info icon is like bad example, I wish I had choked that one, 'cause like it's technically letter I, right, like usually. But like let's say it's like an on/off switch, right? You know that's an icon. So it's important that people are able to discern the shape of whether it's like on or off. And I'm describing like, I don't know what you would call that on/off icon, but I mean like a little like PC tower, you know. So non-text color contrast, when we talk about UI component, it's referring to really the icon, like not so much the borders and things like that. And let me see, we've got chat to questions.

- [Stefani] I can read you one question. We really don't have much time left, but I did jot them down so let me see where's the chat. Georgia asks if a single line of CSS can cause dozens of color contrast failures, are there plans to group the tools test findings?

- You know, that's a great question. I think that's something that is, you know, on our long-term product roadmap, but, you know, it's very difficult. Computers do not have the fine grain intelligence to really understand that issues are related, you know, and it's not so simple as like, oh, they share the same CSS class. No. I mean like again, you could have a table that has many and has similar elements but like each has different color. Again, it's just... And they won't even necessarily be styling based on like CSS class, right? Like they could be using all different types of selectors and things like that. Just color contrast is difficult to test for via automated means, and that's the advantage you're doing a manual review yourself is then you can group those issues. So we make you aware of and then you can group 'em. All right. Next question, please.

- [Stefani] So it is one o'clock. I understand to drop. There are about four more questions but we can always send them over to you and send them out with the recorded session as well. You want one more question?

- Well, I defer to the marketing team here of whether I'm happy to stay on and answer these questions. If it's bad-

- [Stefani] Wave about 69 people still on, so let's do one more question. I actually have to go to my next meeting after that.

- Oh, of course. So here we go. The next question is from Chelsea. For color contrast exceptions around disabled items, does this apply to things like future disabled steps in a progress bar? For example, a multi-step flow where you are making selections and the progress indicator provides information on how many steps are left as well as what those steps are. Sort of a long question. Should I read it again?

- No, that's fine. I think that it's interesting to me because I feel like my inclination is to say that is not an exception, because that text is not an interactive control that's been disabled. So if this progress bar was like a set of links really that like, hey, like step three is disabled, you can't currently jump to step three 'cause you haven't completed step one and two, then I would agree with you, it's probably exempted. But if it's something that is static text that is always not interactive, I think that's probably not an exemption. I think that the rule of disabled text refers only to interact with controls. So again, like with that progress bar example, like if it's a progress bar that really serves as like navigation also, well, then therefore yeah, you can skip to that. Or therefore, and you can't skip to it, well, then it is exempt. So yeah.

- [Stefani] So I think we'll wrap it up with that, Aaron. Thank you all so much for attending the webinar today. I am gonna put in the chat a link if you wanna set up a time to talk to someone about your accessibility needs and we will type up the other questions. Anything else, Aaron, you wanna add?

- No. Hey. I'm a resource for everyone on this call. You know, please reach out, you know, through TPGi or other channels like LinkedIn, I suppose. And yeah, I'm happy to support and answer questions, and obviously this is something I'm personally affected by and something that I just love discussing. So yeah, please don't be a stranger.

- [Stefani] Great. Thank you so much, Aaron. Lots of positive reinforcements in the chat. Thanks everybody and have a great day.

- [Aaron] Great.