- [Kari] Good morning. Good afternoon, everyone. We will get started here in just a few minutes. Just gonna give time for all the attendees to join the room first. So just be patient with us. - Hey everyone. I always like to see where people are around the world. Hey, like add your location in the chat. I'm here in California, Northern California, Minneapolis. I mean, I'm wonder, you know, this webinar today is really focused on USA, I'm interested seeing if we have people from just all over the world. We have Maryland, Minneapolis, Southern Massachusetts. Arkansas, right? Rocklin, California, my neighbor. Selfishly, I always love doing this. You know I'm considering my escape from California a little bit, so I like to see where people are living. Alaska. Okay, great. I think this is... And you know, this part gives me energy and I hope it gives you all energy, right? That we are all united from around the world, this country by this cause of accessibility. We all work for the web collaboratively. Toronto, okay. - [Kari] Let's see. It looks like we're having a slowdown of people joining, so I'll go through our housekeeping items real quick before we get things started here. Again, thank you everyone for joining us today. My name is Kari, and I am the Senior Manager of Sales Development here at TPGi. Just to cover a few housekeeping items before we get started. This session is being recorded and we will email everyone the recording. Usually it takes about two days after the event. We have captions available, so feel free to use those as needed. We will have time for live Q&A, so please use the Q&A box and we'll answer as many of the questions as we can. Sometimes we miss questions if they get mixed into the chat, so try to use the Q&A box for your questions please. And lastly, if anyone is needing any accessibility support, training, usability testing, et cetera, I'll send out an email with a link to schedule time to speak with one of our experts after the webinar. And with that, I will let Aaron get started and provide an introduction of himself. - Hey everyone, my name is Aaron Farber. As I said, I'm based here in California. And just a quick moment about my own background. I've worked on Web Accessibility for nearly a decade, and I've worked on it in kind of many different capacities. So before I came to TPGi, I had my own web accessibility consulting and development shop. I have a background as a front end developer. And essentially in that I worked with very small businesses, the kind that would use like WordPress or Shopify, and I'd audit their websites and I handle those fixes myself. And in that role, in that business I encountered a lot of organizations typically because they were facing an accessibility complaint. And so I learned a lot just simply riding along in that process. And then now here at TPGi, we're supporting accessibility at the biggest brands in the world who are delivering cutting edge and complex applications. And it is different. Those different industries. And I'm gonna share kind of what I've learned, my impression. The question of web accessibility lawsuits is such a large one. We won't cover everything today, and I want to get through everything quickly so that we do have time for questions. And I wanna note here at the start just that it is very easy, especially when you're dealing with a legal topic to say, it depends, right? And so instead, I'm trying to bring clear conclusions from this ambiguity and keep that in mind there are asterisks and things like that, and I'm happy to get into those, and regardless of what the marketing people say, I don't have a hard stop at the end of the hour so we can stay and really go through it all. So rest assured. Alright, so today's topic is, How to Deter and Win Web Accessibility Lawsuits. So first of all, let's just look at this from the top level. The state of web accessibility litigation. There were 4,600 digital accessibility lawsuits filed in 2023. And the top 10 plaintiff side firms, the plaintiff is the one filing the case, right? They represent around 25 plaintiffs that is injured parties, but they account for 84% of all claims, right? So we can think about that just simply we put those lawsuits in the category of what we might term like drive by lawsuits. You can pick your terminology. And here on this, we see that 33% of these cases are state court lawsuits, and 67% of them are federally filed. Now, most lawsuits are based in Florida, New York, and California. One key trend here that we're gonna talk about is that the US Court of Appeals, the second district here, they determine that essentially a plaintiff has to show concrete and particularized harm. So they're moving away from just the tester type claims. And plaintiffs must put forth more effort to establish standing their right to bring suit. Legal activity is increasingly moving from federal courts to state courts, which have more favorable state-based accessibility laws. For example, the New York State Human Rights Law, California's Jesse Unruh Civil Rights law. And all of this, again, like illustrates that they are making it, the courts and our country are making it more difficult to bring these suits forward. But again, just because you know with the way the internet works, you are selling products to all over the country. So to receive one of these lawsuits, you don't have to be based in Florida, New York, or California, you just simply have to conduct business in those states. And I'm looking at electoral college maps. I think collectively those three states probably represent 40% of the US. But we have fewer drive, drive-by web accessibility lawsuits. You know we have high profile instances of unscrupulous lawyers facing consequences. For example, the San Francisco DA's case of Boudin, he charges an attorney from Beverly Hills who sent letters to simply demanding settlements and falsely claiming to file suit. So here we see, if you go to that lawyer's state bar page, they display the Scarlet letter. That they're facing a felony for sending these ADA lawsuits. And if you feel you've been unfairly targeted, consider letting law enforcement know, that won't resolve the issue for you necessarily, but you'll be doing I think your role as a good citizen. And I just wanna underline again, is that there are many ways to respond to these cases and deter these cases. And I'm covering only a limited number here. And I swear that's the last disclaimer I wanna provide of that kind. Oh, wait, what? How did this slide get in here? Saul Goodman from Breaking Bad, I don't know what this guy is doing in here. All right, well, let's keep moving. Alright, so the industry breakdown here, we see that 82% of the websites which received these lawsuits are e-commerce. And 18% represent other industries, that's restaurants and food services and education. And I wanna thank Usable Net and Safe Arthur and Shaw, for doing this research which I've used, and they are such leaders in accessibility and a great resource. So credit to them. Now, fewer than 10% of these suits ever reach a jury. Going to court is expensive and unpredictable. Most businesses reason that it's less expensive to settle, of course, right? Settlement does not stop receiving future lawsuits. It's not, you've given your pound of flesh and that's it, right? 25% of the lawsuits filed in 2023/24 were against companies who had previously received lawsuits. So if you do receive one it is incumbent on you to resolve those issues. But we're gonna keep moving. So the lawsuit origins, right? So we're talking about these 4,600 lawsuits and they're indiscriminate on some level, but they're not totally indiscriminate. So why are some sites targeted more than others? I think that's the key question here that we're concerned with. So first of all, the lawsuits range in quality and level of effort expended by the plaintiff firm, so we'll talk more about that. However, there's two clear aspects which draw the attention of plaintiff firms, that is accessibility overlays and automated scans. All right, so what is accessibility overlay? These are widgets, which you may see at the bottom of websites. It resembles the handicap placard, it's a little button. These widgets recreate browser-based or assistive technology features and some change for example, it says it would be like they would allow you to magnify the page or increase the text size, those kinds of things, which are already natively available in the browser or through an assistive technology such as Zoom text. Some of these overlays have their own screen reader. Some of these overlays now they're going a step further and they're changing the HTML markup at runtime. So basically after the page loads, the overlay is applying changes to the markup, dynamically changing it, rather than changing the underlying source code, right? So we see the difference there. Overlay changing it when the page loads versus your developer going into your WordPress theme, your Shopify theme and changing that code. 20% of these lawsuits filed are against websites using widgets predominantly AccessiBe. There were 449 suits in 2023, and over 500 in 2024. Now, a question to the audience and add this into the chat. Think about this from the perspective of a web Accessibility tester, a lawyer, a litigator involved in this topic. When you see a website that is using an accessibility overlay, what signal does that send to you? So add it in the chat. I'd be curious what people say. I'm gonna take just like 15 seconds, which is not enough time. So please I hope you type a hundred words per minute, and then I'll share my thoughts, but add it in the chat. They don't know enough to fix digital accessibility, bandaid fixed client, foresight, unserious, no effort. I'd like to see at least 80% of those with overlays being taken to court, my man. That you've done your due diligence and your site is good to go. I like that. I don't know if that's like sarcastic, Mary, but if it is, I like your style. I'm a fan of the dry sarcasm. So to me accessibility in a single line of code is not possible and it's demonstrably false, right? Plaintiff firm and accessibility subject matter expert's perception is that these businesses took a shortcut and they did not consider accessibility in the design and development of their website. Because they're applying these changes at the end of the process rather than at the start, right? And the overlay to me indicates that the business may be unable to remediate their website in a timely basis. These tools exist for business and develop business convenience. Because it is, many of these businesses, especially the kind that I formerly worked with, don't have the technology or the orientation to resolve accessibility issues perhaps on their own. So that's why they're doing this overlay, and in a sense, that makes them a target because it shows that they are gonna have difficulty responding. But most importantly, overlays may not improve user experience. The web accessibility community, some of the people on this call has painstakingly documented that these tools do not improve the user experience for people that use assisted technologies. To learn more about this topic, you can go to overlayfalseclaims.com. And I will note that I wanna add this here, and it's important. These overlays do have potential and value as technology. Applying JavaScript based overlays at times is the only way to change third party code or things you may not control that code base. Also, with the advent of AI, these tools are getting better. They are able to recognize buttons and headings and things of that like on the page. So I actually have hope for these tools. I believe they have value, but at this time they are not enough to get you to 100% accessibility. And there's no such thing in a sense as partial conformance, it's full, it's binary, it's full or not. Of course now they didn't initially market themselves that way. Businesses are rebelling against some of these overlays. So for example, a New York city based dermatology practice filed class action lawsuit against AccessiBe alleging false advertising and ineffectiveness. This was reported on by Michal Nowicki, who's an attorney for a prominent law firm involved in these cases. Now onto automated scans. To me, more than, we said 20% of the lawsuits have widgets. And by the way, not only can you visually determine whether a site has a widget, but you can easily determine that through audit, through scans of the web. I myself have done scans of large numbers of websites. You can determine what plugins and libraries are being used in the website. That's very easy. But moving on, automated scans are the most common trigger for a drive by lawsuit. Simply put, right? Like plaintiffs firms can easily run scans on websites, they have limited expertise. But when a site contains a large number of issues, the plaintiff firm then delves deeper into the site, perhaps then they instruct a screen reader user to go to the site because one cannot receive a lawsuit because of WCAG violations. Maybe in a superficial sense. But one receives a lawsuit because someone cannot use the site as they normally use the web. And typically if there are WCAG violations, that means they're unable to use the site as they normally use the web. Now, automated scans are improperly used by plaintiff firms. I wanna emphasize that using an automated scan in litigation without express consent violates the terms of service. And that is true for most automated accessibility vendors, whether it is TPGi or WAVE. So if you receive a complaint or you receive a demand letter, I understand those things can be separate, and they've used an automated scan in the results they've explicitly like included, attached that or used that, alluded to it. Let the automated scan vendor know. Again, it will not exempt you from that lawsuit or anything like that but again, you'll be doing your role as a good internet citizen. And so here we see that WAVE, which is is a web Accessibility evaluation tool from a not-for-profit organization called WebAim. Here we see language from their website. It says, "It is not our intent that WAVE be used "for legal or litigation purposes, "while WebAim supports the civil rights of individuals "with disabilities to access web content "and provides services to help organizations "implement accessibility, "WAVE cannot provide a good measure of discrimination. "Its use in legal actions can cause confusion "and may suggest relationships with complaints, "litigants and defense that are not valid." In bold. "The use of WAVE or WAVE results data "for any purpose related to a legal action "is not allowed without written permission. "If you are aware of WAVE being used in violation "of these terms, please contact us." And I will say that even upon receiving cease and desist, I know that some of these law firms continue to use these scans, but nonetheless we have to continue that work of discouraging that behavior. TPGi here we are advocates for disability for people with disabilities, it's in our family, it's in our DNA, it's who we are, So we are not at all supportive of our scan results being used in this manner. Now evaluating automated scan results, first of all, check whether the results are testing applicable accessibility standards. We're gonna talk more about this in a sec, but I see this happen actually, right? And the prevailing online accessibility standard is the web content accessibility guidelines level double A. Let's look at why. Okay, so first of all, let's talk a little bit about what WCAG, right? WCAG is produced by the Worldwide Web Consortium, which is essentially volunteer group of people around the world who are involved in web governance. That's the authors of the web content Accessibility guidelines. So the first, two point, I don't wanna say the first, but version 2.0 was published in 2008, 2.1 was published in 2018, and 2.2 was published in October, 2023. So for the time being WCAG 2.0 or WCAG level, or version I should say not level, but version 2.0 or 2.1 is kind of the standard that I've seen referenced by courts and government agencies. Although some states, especially when it comes to their own governmental mandates, they have signaled that they will shift to 2.2 as the standard in 2025. But for now, again, I have not seen any core require conformance with 2.2. And here we see a table and we can see that from 2.0 there were a total of 38 success criteria, which is guidelines, in WCAG terms. We moved from 38 in 2.0, to 50 in 2.1, and 57 in 2.2. So each of these is supplementary, right? Like to pass 2.1, you have to pass 2.0, to pass 2.2, you have to pass 2.1. But as I say, so there is perhaps more complexity involved in these, although I will say that most of these new success criteria, they are concerned with kind of like clarifying ambiguities and gaps in the previous WCAG. Alright, now let's talk about the levels, right? So we talked about the versions. Now let's talk about the levels. So WCAG is three levels of conformance. There's level A, this ensures just the most basic level of access for disabled people. It does not provide an equivalent user experience. Level AA ensures disabled people do not encounter significant barriers. It provides a mostly equivalent user experience. Level AAA, enhances the user experience for disabled people and it ensures accommodation for people who may have multiple disabilities. Now we thought about WCAG conformance levels in technical terms, let's talk about in human terms, right? Or I mean, I'm sorry, the opposite, right? We talked about in human terms, let's talk about in technical terms now. So to make an application accessible, could require changes to a site's code base aka engineering or changes to a site's visual appearance. So level A does not require one or two, okay? So level AA requires one or two, level AAA requires one and two. So if we were to use an example here, like an image missing alternative text. That's a level A issue, because that is a feature alternative... Images natively support alternative text that doesn't require any custom or significant engineering. And also it doesn't change the site's visual appearance. Color contrast, that can be easy to solve, right? We simply change a color value hexa decimal code in the CSS. And that's very easy to do, but nonetheless it's level AA because that involves a change to the site's visual appearance. So again, like these levels of effort involved in these are not perfect, like they're an approximation. Now level AAA, an example would be one of those AAA guidelines. Again, success criteria is to have like a sign language interpreter, right? So think about that, that involves additional work, significant work, and it changes the site's visual appearance. So WCAG level AA is the established legal remedy. Basically, like court said, hey, we don't have the specialized knowledge to understand what constitutes an accessible website. You say you can't access this website. We don't necessarily know what makes up an accessible website, but hey, the worldwide web consortium, these people, they have done a lot of... They've put in an immeasurable amount of work in determining what makes an accessible website. So WCAG level AA is often set as the remedy. Like if your site is inaccessible, hey, conform to that. Level AAA is never set as the standard. In my time here at TPGi, which is approaching on five years. I don't know what anniversary that is. Somebody let me know in the chat so I can let my manager know. So level in my time here at TPGi, I have never heard of an organization striving to conform to level AAA. But nonetheless it is promoting a high quality user experience that is difficult to achieve. So again, I like level AAA, but it's just when organizations receive scan results containing level A issues or best practices, these are inherently low priority. And here we see a screenshot of a level AA six issues on 18,000 pages. That's a screenshot from a recent accessibility complaint file, or not complaint, but a summons or whatever filed in court that organization as part of that summons, they included as evidence and automated scan result, which did include level AAA issues. And so my first comment to them was like, well that's not really valid, because that's not a standard that you're ever gonna be realistically required to conform to. Thanks Jed. But I wanted to know, do I get like a paper gift or do I get like 10? What do I get for that anniversary? So run your automated scans though. So we've talked about what triggers these lawsuits, and so we already have some thoughts here, right? Like, number one, having an overlay put too much more risk. And number two is having large numbers of automated errors on your site is going to raise, you know, draw attention to you, right? So don't wait for litigation, run automated scans on your website to understand your level of risk. And running an automated scan in and of itself does not require accessibility expertise. Like you as a product owner or something, you can run that scan and you can deliver it to others to evaluate. But oh yeah, all right, I'm gonna run an automated scan, but which one? Which one am I gonna use? Alright, so I'm gonna compare ARC, which is our in-house rules engine with Axe-core which is open source and used widely across the web. There are multiple vendors, and the automated rule engines overlap and the results they return, but there's limited value in running scans with the different engines because again, they overlap so much. And honestly just in practice, like you would be devoting a lot of effort to like matching the two, like, okay, it's like this issue and this one, and then this one's referring to the same thing. It's not a great use of your time, so just pick one. Now Axe-core is driven by its marketing pitch and philosophy. Is the slide deck available? Hey, I'm sorry Russ, it'll be available afterwards, but it's a great question. And so comparing ARC and Axe-core. So Axe-core is driven by its marketing pitch and philosophy, no false positives. And so that means no mistake in accessibility findings and you know, it's actually a very restrictive standard. You know you think about the web is vast with a lot of edge cases. Now ARC is concerned with the different permutations of browser and assistive technology. It casts a wider net and ultimately, information is power. These results are for yourself. Whoops, click elsewhere. Now ARC and most vendors, automated vendors are gonna report scanned results in a really similar way though. So here in ARC we refer to it as an error. We report three kinds of things. An error, an element automatically identifies WCAG violation. An alert, an element which requires further manual inspection to confirm as a WCAG violation. And a best practice an element which may not represent a WCAG violation, but impacts the user experience. So ARC's has similar things, right? Like they have, I believe their category names are gonna be like failure, versus like needs review, and then I think they have best practice. But it essentially, it's the same thing, it's the same idea here. Now I wanna have a note about Google Lighthouse here. So Google Lighthouse is an automated testing suite built into the Chrome browser. If you open developer tools, you inspect the pages code, you know there's lighthouse there and you can run tests on your site's performance, Accessibility, SEO, whether you're a progressive web app, don't worry about that one. And in the accessibility scan used by the Lighthouse, they use a subset of Axe-core, and they also apply WCAG 2.2. So they include results from WCAG 2.2. Now, as I said, it uses a subset. So using Google Lighthouse will report more wrong, fewer issues than Lighthouse. So I apologize, I gotta change that slide here. So again, like using Axe the scan in, or ARC and these things is gonna report more issues. And that makes sense, right? Like it's built into the Google browser. They understand how these scans are gonna be used by, at perhaps adversarial forces, so they're gonna be cautious about what they report, you know? Now, automated scan best practices. So with ARC monitoring, that's in our web-based platform, and you can talk to us, I'm trying to not... We're not gonna spend too much time covering our products. You can provide a homepage URL and let ARC crawl and analyze your entire domain. Most vendors are gonna have a similar product or approach, right? Where they scan your site. Now, the one thing to keep in mind here is that these scans evaluate pages as they appear on page load. And typically like e-commerce sites, you are gonna have to trigger content to appear, right? And that's where it's great to use the ARC toolkit from extensions to test deeper into user journeys. With ARC toolkit, you can run a scan whenever, wherever. So ARC toolkit makes it easy to scan pages which require authentication, like you have to log in. Pages which are behind a firewall or other security policies, right? So you could be doing this on your staging or lower level dev environment, and you can test specific points and user journeys, even local file URLs. So in short the advantage of chrome extensions is you can get the page into your preferred state, then open developer tools and run your scan. So you can open the shopping cart or add an item or whatever and run your scan. And then that gives you more visibility. And of course those are critical processes within your site. And again, anyone can run these scans using these chrome extensions. Yes, it does require more knowledge to evaluate them. But the primary strength of ARC monitoring that is compared to ARC toolkit is that each issue is mapped to resources on how to understand, test and solve that issue. So now let's talk about it. The most common automated errors cited in lawsuits. The lack of the text alternatives. So that's traditional image or image-based links or SVG-based controls is at the heart of nearly 50% of automated errors detected in a broad-based scan of e-commerce sites. So WCAG success criteria 1.1.1 Non-text Content and 2.4.4 Link Purpose in Context are the most common violations cited in lawsuits by far. So in other words, images, missing alternative texts and links lacking any text, right? So without any text, a screener to user who can't visually perceive the page without that text, they don't know the destination of the link. They'd have to open the link and go, navigate around that page to determine what it is. So as I said, image-based links and controls represent multiple WCAG violations. And I think this is a topic that this is a design pattern so common in e-commerce websites, we think about like the product gallery page. And here's usually how I see it go, is that you'll have like a product and then you have some text beneath. So here we have an image of a sneaker, and then we have texts underneath, I'm a product and for 220... Is that pounds or euros? Like, gosh, I'm such an American. But we see here that the product label text is located outside the product image-based link. So that's multiple WCAG violations at once, right? Because we have an image missing alternative text, that's one thing reported. Then we have a link lacking any text, so that's a second thing because again, since the image doesn't have all text, the link doesn't have any text. So that's two issues. And then depending on how you flag this, some automated scan engines may even flag this as a 4.1.2 issue because it has no name, right? So name, role, value. And we don't have to be too concerned here today with this, you know, the particularities of WCAG reporting, okay? But the point is, it's one that really shows up in a scan and makes your site look like you have a lot of automated scan results. And the solution is simple, here is to simply enclose the image and the text in a single link, right? Thank you Kevin. And it's a euro, okay? And so make the product an image and product title text into a single link. I have a resource here from Adrian Roselli, former TPGi engineer. It's great and very in depth. It's really developer centric. Next source for the most common assertion is related to number one. And we're just gonna elaborate about a second further, is icon base navigation menu buttons. I've seen this reference multiple times, is that they say essentially the hamburger menu button lacks an accessible name. And that of course is a critical issue, right? Like the hamburger menu triggers your navigation menu to appear. You know, that's a gateway to navigate in the site and it gets overlooked. I will say it's funny because it's just a tribute to kind of the lack of expertise of some of these plaintiff firms is that I very rarely see them before automated scans on the mobile layout. It almost seems to be entirely on the desktop layout, is just a symbol of kind of their actual effort and genuine, authenticity in filing these claims because we know that 50% of web users are using a phone, right? So the mobile layout is very important. Now, the source for most common issues for assertions, I say assertions, as in we assert that these elements do not conform to an automated rules engine. Sites which use ARIA, simply put have more automated errors, okay? ARIA is used for modern UI patterns which cannot be achieved in native HTML alone. So for example, tab panels, expandable collapsible widgets. Now, how do you recognize an ARIA widget, right? So let's say you're a, well, let's say a product owner, I'm gonna put this in both terms. Like, let's say you're a product owner or a developer, how do you recognize an ARIA widget? So a developer, of course you can open the code, you can look at it, but I honestly, you don't even have to, right? An ARIA widget is a JavaScript powered interaction. JavaScript is how we make the web move. JavaScript adds the functionality to a webpage in short. So you click on something and it changes page content without reloading the page, that's using JavaScript, right? So that's how you know if it is a JavaScript powered interaction, again, like something is dynamically changing the page, that's an ARIA widget, most likely. If it's lacking ARIA, then it probably needs ARIA, right? But here's the thing, ARIA carries very precise specifications, so it's easy to misconfigure. So again, if you're not using ARIA in the proper way, it's gonna actually result in a lot of automated errors. So we have to be careful when using ARIA. Now there are steps to overcome ARIA based issues. Now ARIA is very, and I realize I haven't said enough about ARIA here, but just to explain here, it's to contextualize those changes in the page, right? It's to bring sound from silence in a sense. Because like a person clicks on something, for a screen reader user that has to trigger an announcement. So ARIA exists to trigger those announcements and provide dynamic feedback. That's a very developer-ish thing, and so simply put, like, if I was a site owner the simplest way to overcome ARIA based issues is just to simplify the interface. For example, here we see a table, headers, we see the first column is ticket types. It's essentially a horizontally scoped header. Then the second column is advance, and then it has a tool tip icon, and then the last column is day of with an icon. But in any case, the point is here is that after advance, that tool tip is expanded and says get tickets in advance and safe. Yeah, tool tips don't follow a standardized pattern, right? That's gonna be difficult to solve. So maybe again, rather than... And in this case with this organization, we actually did custom code to make those tool tips accessible. Again, it's a good level of effort. Alternatively, we could have just had permanent text. We could have just said, get tickets in advance and say, we could have just put that text right under advance. Having text is inherently accessible, right? So that's the easiest way to overcome ARIA issues is just simply to remove your ARIA and do a simpler interface. Also, PDFs can be a target. And I will say it is very difficult to make accessible PDFs without specialized training. Automated scans do flag PDFs and the PDFs almost always contain errors, but more than that, right? Like using a PDF is not really a very positive user experience. It assumes that the user has the requisite software, they have Acrobat or whatever, plus using a PDF browsers are inconsistent, unreliable in how they render PDF content. So instead we can solve PDF simply by creating an accessible HTML form or using Google forms, right? Like external, or it could be embedded in your website. So you have a form to get a refund or a rebate or something like that could be a Google form. So again, like, simply just removing PDFs from your site can be another way to kind of reduce the attention that you draw. Now, color contrast in the context of lawsuits. Now this one is kind of a, is an interesting one. So a single line of CSS can result in hundreds of errors. I mentioned my name here because I wanna emphasize that I'm not omniscient, okay? Like others on this call, if you have a different experience than me in this respect, I would love if you would add it in the chat, but I do not know of any litigation, web accessibility litigation that has been predicated on color contrast. And that makes sense, right? Because color contrast is rarely gonna prevent someone entirely from using a website. It's porn user experience, it's an inconvenience, it makes it harder to use the website, but doesn't prevent someone from using entirely. And more than that, a lot of people that have color blindness and other things like that, they have chrome extensions, they have methods to make pages to enhance color contrast on their own native browser. So they may not even experience the issue in the first place. Now, Axe-core, the rules engine states that color contrast is the most common issue in their automated scans. So we see in Axe-core when they run scans, 30% of all issues are color contrast issues. So again, it is by far the most common thing flagged in a automated scan because again, the way that websites are built, like you picture like a table with all these cells, you know, a human being looks at that and says that table has poor color contrast, automated scan results is gonna say, hey, you have a 10 by 10 table that's a 100 cells, you have a 100 instances of low color contrast. Wow, that's gonna blow up your automated scan results. And what's so frustrating about this to me is that I see in a way it's drawing attention to your site because you have all these automated scan issues, but then when they actually file a claim, they're not able to reference color contrast because we are concerned with screen reader users, right? That's gonna be our plaintiff. So we can't say our screen reader's plaintiff also complaints about color contrast 'cause that wouldn't make sense here. All right, now we talked about the automated scan results and most common things here, right? Your job is to gauge the impact on user experience of each automated scan results. Typically, that's the first thing teams do in reaction to a complaint or demand letter, especially if it contains automated scan results. And prior to TPGi that was a business I had in some respect. That like an attorney would reach out to me like, "Hey, can you verify "or gauge the impact of these claims, "are they legitimate?" And then based on that they use that information in their legal, in their arbitration processes. Now, the quality of a complaint, this is on my mind right now. I have encountered a lot of people recently who have received accessibility lawsuits and that's partly what motivated this case consider the two claims here, buttons do not have... And I've seen both of these in complaints recently. One, buttons do not have accessible names versus it is not possible to determine what color is selected. I should say when I met one buying a shirt, we can tell which one of those claims is more valid, meaningful, and genuine. They're the same claim, right? They're the same claim, but one person has just thrown you automated scam results, the other person has the plaintiff that has actually gone this additional step to gauge the impact on user experience and demonstrate that this is a barrier. So I have so much more respect for the second claim and it is much more compelling in legal context. Now, we're gonna cover a couple of things quickly here. Does having a phone number protect you from web accessibility claims? No, it does not. No it doesn't. But stating that you can provide accessibility support over the phone is helpful to users and it is empathetic, but it does not exempt you from having to solve website issues, right? Because a phone number does not provide an equivalent user experience to having a site that can be used at any time of day. And you know a lot of this web accessibility topic started because of ATMs, because they did not have a voice interface. And some banks initially argued, well the person can go into the branch, that's an option. And the court said, "Well, that's not the same "as being able to do it at any time of day." And that makes sense, right? I mean, I like to buy my shirts at 1:00 AM, like at impulsively. That's how I do my shopping. I don't wanna have to rely on a phone number. But moving on, keep it moving. Alright, so now accessibility statement. Now I have seen some complaints cite the lack of an accessibility statement. It's an interesting one, right? Because to me it's kind of like they're throwing, like... What is the phrase? They're throwing spaghetti at the wall. I don't know. But they're looking for ways to just like bolster their claim. So they're gonna say things like, "Hey, we went to your site multiple times on this date, "that date, the other date." And that makes their claim more compelling. They don't have an accessibility statement, they have no way for us to provide accessibility feedback. So again, every e-commerce vendor should have an accessibility statement. It's a setting to document your substantive efforts on accessibility, the things that you have done and provide accessibility feedback mechanism. It's a top deterrent to plaintiff firms. They're gonna look at that. And to me state if you are working with a respected accessibility vendor. Those lawyers understand who are legitimate vendors and if you put forth effort. Now, I will say if you were working with TPGi, please check with your account manager if you were gonna use language referring to TPGi and we can help you with that. And this is a major topic, because some states are wanting to see more of, or talking about having basically... Here in California for example, we're considering legislation where you have to state whether you have worked with like a professionally and accredited accessibility vendor. That's not currently the law here. We passed it out of committee a few times and then the legislature looked at it and was like, actually this is a pretty consequential law. So it's been punted into next year and I'll let you know. No, yes, posting the sites footer. Yeah, thanks for adding Aaron. Now I was talking earlier about how most people settle, some don't settle. Here on Twitter I saw this recently. Beardbrand received a classic drive-by lawsuit from one of these plaintiff firms that have sent out hundreds if not thousands of them. And so they were sued for 75,000. That's the maximum limit under New York's human rights law. And it wasn't a reputable claim in a sense. But they didn't give in, they didn't settle and they won. And here's what happened, and I looked into this a little bit and talked to them, is essentially most of the complaint was just boil or plain language. It didn't actually refer to their sight, it was just like, you know, but they had only one or two legitimate claims in there and they denied all of the claims. They just simply denied them. If I look at their legal response, they just say we categorically deny claim one, claim two, et cetera. And in response, the plaintiff firms simply dropped the case. They did not go to court. And I think that reflects that the level of effort that these plaintiff firms are willing to expand on filing the claim reflects, I mean, the level of effort that these plaintiff firms expend on filing the claim reflects the level of effort that they will make to carry on the claim. In a sense you can frame it as, you know, the bullying on some level. And sorry, the story doesn't necessarily have a happy ending, right? That you don't get to... Because the case gets dismissed or something like that you don't get them to pay your attorney fees. Like for the lawyers on here you know that getting people to pay your attorney fees it's a separate legal process. And so most likely you're not gonna get that done. This person, they're active on social media. They wanna fight, they wanna do stuff for attention and you know, again, and I'm grateful to them for that and I gave 'em a click. Now what to ask for if you must settle. Not everybody can be a Beardbrand for a variety of reasons. And you may have a legitimately inaccessible site. Like it may have very critical barriers. First of all, the number one thing to ask for is just simply longer remediation timelines. Extend them, give yourself more time to work. That's a key negotiation point. Second, be strong in arguing against claims. So fix these things while the complaint is in motion. And again, you could go into those and demonstrate you've solved this. Now here's the TPGi plan in one year, again, I don't wanna focus on TPGi here today. Well, yeah, please do actually focus on TPGi, sorry for the marketing people. Let me rephrase that, right? First thing that we'll do here, and we have a plan for e-commerce retailers. So again, I hope you reach out to TPGi and just learn more about the plan and we can... And again, like you don't even necessarily have to do a TPGi. TPGi will help be there for every step of the way, but it's about the vision here. First thing is to run automated scans. Understand your current state of accessibility and how others perceive your site. Then what TBGi does is we manually test the key user journeys, right? Because automated scans have their limits. And for e-commerce sites, we know the key user journeys that have to be tested manually that deserve the highest level of scrutiny, visibility, and have the most impact. And from this automated scan results and from the manual testing, we provide you batches of issues to work on for each dev cycle. And that's great because I find most e-commerce sites, you have a dev firm you work with, you get 20 hours a month to have time with them or whatever amounts, hey, we'll help you use it, we'll give you stuff for them to work on and you can demonstrate the changes to your site. Since you're scanning it, you have defensible data points validating your work on accessibility, showing continuous improvement. And then here at TPGi, you get regularly scheduled check-ins with an accessibility expert. And again, that's great because not every organization really needs a full-time accessibility expert, but I think you need access to one at any time. You see the difference. So yes, let's make it accessible. And I wanna say one last thing here. I've talked, I wanna emphasize here, we talked about these lawsuits and I feel like some people in this chat have a negative opinion of these lawsuits. Sure, yes. I would like for it to be a regulated process where you receive a complaint and you have an amount of time to remediate your site before you face penalty. I think that would be a good approach. Virginia, California, other states are considering laws that basically will do that. But again we have the ADA because it's actually it's constitutional basis. It's actually the Interstate Commerce Act that it is a burden to interstate commerce for people with disabilities to not know whether they can be served at a particular location. Brown v Board of Education, we got rid of segregation in the United States because it was determined that that was a burden on interstate commerce. It wasn't reasonable to go to a hotel or something you're traveling and not know whether they can serve you. So when you are making something, accessibility security, this is why. So accessibility is why America is the greatest economy in the world and one that everybody wants to participate in. And you are playing a role in that. And so we all work for the web, as I said, we're at the end of the hour, but I will stay for questions. I'm happy to take 'em on any topic. I know I said that, but yes. So yeah, thank you for your attendance. And you know what? Just by being here, you are all making a substantive effort on accessibility. You're showing leadership, you're putting thought, and you know what? You are free to reach out to me over LinkedIn or otherwise and I'll help you know as much as I can. So again, we're all in this together and I appreciate your effort. Yeah, let's see if there's any good questions. Sorry, I was talking so fast by the way. I know I have a lot to cover, a lot of things that I wanna get to. And I didn't even get to all of them. I wanted to actually talk about Shopify some 'cause I'm a big supporter of Shopify because-- - [Kari] I don't see where you missed any questions, at least through the chat. I think you answered anything I saw from there. - Yeah. And so to elaborate on that last thought here, you know, the reason I'm a big fan of Shopify is because they own the payment page. The payment page is critical and Shopify makes it accessible. They are a leader in accessibility, they're very skilled. And so you know that that page is gonna be accessible and you don't have to worry about, oh, the error handling for if they don't put in a CVV or something like that. That's gonna be very difficult things to fix. Alright, so let's see, we have comment here. I wanna tell my users that the products meant for designers, hence they have no motor or visual disability. I don't quite understand that comment, Hannah, but free to reach out. How do I tell my users that the product is meant for designers, hence they have no motor or visual disability? They very well could. They very well could. You know people have all types of disabilities you can't perceive. And so again, they may very well have that. And I speak from my own experience, of course. My father has retinitis pigmentosa. He's been blind essentially most of my life, he's a medical doctor. So people don't expect him to be blind, you know? So again, like you never know. And people also have temporary disabilities and things. And again regardless of, we don't get to make the determination of who uses our product. Think about that reasoning. If we said, "Hey, we don't have "this kind of person that comes in." It's not how our economy works. And again, that's why America is the greatest economy because of that expectation that you can be served anywhere. - [Kari] We've had two additional questions pop in the Q&A. - Okay. Should I tell my users on the website before they register, that the tail is meant for those who have no disabilities? I would not say that. I think that would be explicitly stating that you are discriminating. I think that would be a... I think that's wrong number one, but that's not important. No, I think it increases your legal liability. It's similar to how years ago I recall a case where there was a website that had a one version and then it had an accessible version. So it's like you could click on the accessible version and then essentially it was like a stripped down version of the website without all the images and decorative stuff, which might have been complicated for a screener user to understand. Quartz basically viewed that as like, hey, that's separate but equal. That is not an equivalent experience. So I just think like doing those things where you're explicitly stating like, hey, here's the disabled route. No, you're gonna implicate yourself, so don't do that. Yeah. So, hey, great everybody, thanks for hanging on another two minutes. - [Kari] And there's two questions in the Q&A. - Oh, is there, geez. All right. Yeah, let me see here. Oh, in the Q&A, I forget, we got multiple things here. All right, what is the timeline to react to a lawsuit? It's interesting, right? So that process with Beardbrand lasted about 12 months. And to me, you want to rapidly respond to the lawsuit and forcefully. So I don't know about the timeline to react to a lawsuit. There is one thing that I wanted to cover here, which I did not today, so limited time, but I'll share the story for people that are hanging on. I used to live in LA and there was a bar at the Grove that's a big mall in LA, and they received a complaint like this and they essentially ignored it. They just put it in the trash and they actually because they have ignored it over the course of, I think nine months, something like that. They ignored it for nine months. They actually became the first business in California to receive a $4,000 penalty under the Jesse Unruh Act. So, I don't know the exact time, but I think you wanna respond promptly. And again, I just think in terms of wording off these plaintiff lawsuits it's just showing that you have resources and you're prepared to defend yourself, just like anything with the law, right? Lawyers are afraid of taking on people who have resources and stuff. So I think again, like it's really important to respond in a timely manner. I don't have an exact amount. I think it really depends on the state and the court. And these things are very protracted nowadays. You know all these courts have massive backlogs. So anyways, but it's a great question. But just don't ignore. And Shopify, TPGi dash, Justin. Shopify, so that's your answer, Kevin. Thank you. Justin. Shopify, TPGi dashboard works well to scan those sites too. Easy question, but I didn't look it up and wanted to ask. Yeah, I mean you can use... I mean TPGi, we can scan any kind of website, whether it's Shopify website, WordPress website, a custom react or Angular website, whatever have you, or Webflow, whatever it be. So yeah, we can scan all of those kinds of websites. We can set up monitoring where you have defensible documentation, again, we save the scan results and over time which is confidential in your own organization, or you can just use our ARC toolkit and that's free. I encourage you to download, install it. I hear return to Shopify and Webflow. I don't understand the question, but you know what, Justin, given that you're referencing Webflow, I'm gonna assume you're like a designer. I like Webflow a lot because I always say this to people is that Webflow is the one site way of building the one site builder where you can actually create a 100% accessible website using Webflow. It takes effort, but you can do it because with Webflow you can add whatever ARIA or HTML attributes you want to elements on a page. We know that's very difficult at times to do with Shopify and WordPress themes. Because again, like you can't go into the theme and make those changes because you want to be able to receive updates to that theme, right? And then when you pull those updates, it's gonna override those changes you've made. But again, Webflow doesn't have that aspect of like the update and version control, well, they do have version control, but you're not like pulling these updates from another party. So I like Webflow, I have a lot of thoughts about Webflow we can save for another conversation, you feel free to talk about it offline, Justin. Yeah, we've had a lot more questions on using Webflow, but we're trying to make sure people don't get too wild. Hey, you know what? One thing that's also nice about Webflow is there are accessible component libraries you can pull. And again, I think Webflow has a pretty savvy audience. And for the record I've actually been contracted to fix Webflow sites in the past, so it is something I've done. - [Kari] Alright, looks like we have hit the end of our questions, so I'm gonna thank everyone for joining us today. Again, Aaron, thank you so much for your time. If anyone has any additional questions, or if there's something else they would like to ask you could reach out to us at info@tpgi.com, or at Ida, it's I-D-A@tpgi.com and we'll make sure we get your questions answered and thanks so much and we will see you guys at our next webinar next week. - Take care.