Why Your Inaccessible Website Could Get You Sued & How To Prevent It [TRANSCRIPT]
SOFIA LEIVA: Thanks for joining the webinar entitled Why Your Inaccessible Website Could Get You Sued and How to Prevent It. I’m Sofia Leiva from 3Play Media, and I’ll be moderating today. And today, I’m joined by Ken Nakata, director of accessibility consulting at Cyxtera Technologies. Ken is a former senior trial attorney for the disability rights section of the US Department of Justice. He has overseen countless ADA investigations in cases that have shaped the current ADA law and policy. Ken was also a leading participant in the final rulemaking of a Section 508 of the Rehabilitation Act.
So with that, I’d like to hand it off to Ken, who has a wonderful presentation prepared for you all.
KEN NAKATA: Thanks, Sofia. And thanks very much to 3Play Media for putting this together. Today’s presentation is Why Your Inaccessible Website Could Get You Sued and How to Prevent It. This is a presentation. It shouldn’t take too long. I’m thinking maybe half an hour, just a little over half an hour. But in order to make sure that I don’t run over and that I leave lots of time for questions and answers, I’m going to start my stopwatch. And I’ll keep a close eye on it as I’m going along.
So as Sofia mentioned, my name is Ken Nakata. I was a senior trial attorney at the US Department of Justice in the disability rights section. I spent about half my career working on traditional built environment, accessibilities, and new construction cases, and cases involving mental health conditions, and all sorts of other interesting policy issues, and litigation. And then I spent the second half being more of a regulation geek and helping write the Section 508 standards with the access board, because I guess I was of the more technical oriented lawyers in the office.
As most people probably know, lawyers tend not to be terribly technical people. And if we had our way, we’d still be writing with quill pens and inkwells. But a few of us did manage to take an interest in technology. And I just happened to be one of those people. So nowadays, I help organizations manage IT accessibility, but in both digital environment as well a traditional built environment. And in that role, you know, it’s all about crafting policies and making sure that different stakeholder groups in an organization understand what they have to do, building awareness. It’s really commitment towards accessibility.
So by way of backgrounds, today’s presentation is going to compose– or comprise– three parts. The first part is really a background on what the problem is, what the issue that we’re facing is. This involves the explosion of ADA cases that we’ve seen nationwide recently. And I’ll get into some of those numbers. I think they’re really quite startling.
And then the other aspect of that is the importance of web accessibility for people with disabilities. And those two are kind of countervailing forces. And I’ll get into why.
The second thing that we’re going to cover is a quick legal synopsis. And for those of you who have been in some of my presentations where I’ve talked about legal trends, it’s not going to be that. Most of those presentations have been really in-depth, in the weeds, talking about the differences between the circuits in terms of their interpretation of what place of public accommodation means, or whether there’s a nexus between the website and the built environment, the bricks-and-mortar environment that’s necessary in some of those jurisdictions. We’re not going to get into any of that. Instead, we’re just going to focus in on the key concept, which is effective communication.
Then I’d really like to spend our time focusing on this four-part solution for accessibility. It’s a simple model. It’s not uniquely ours. It’s something which just about everybody who is a major competitor in this space does. Whether they boil it down to four steps or not is really just a question of their marketing team, I guess, more than anything else. But it’s basically the same model that we all use. And then lastly, I want to, of course, leave lots of time for questions and answers.
So jumping right into it, I want to spend some time talking, here, about first starting off with the litigation trends, why this is startling, and why there’s a countervailing interest in understanding the importance of web accessibility. So why do I say that there’s this explosion in web accessibility? Well, if you go back to 2015, we only had 57 lawsuits involved in web accessibility. And then, 2016, wow, that number, it went up five times. It went up to 262 lawsuits by 2016.
And then you think, well, OK, that’s a lot of lawsuits. Well, guess what, 2017, it’s tripled after that. So now we’re up to 814 lawsuits. And now, in 2018, we’re looking at probably 1,200 lawsuits so far at least. Somewhere between 1,200 and 1,500 lawsuits are probably coming in for this year.
It’s hard to say, of course, because it’s only September. And we do have quite a few months left. And a lot happens between October and December. But still, you can see that there’s a huge upward trend in the number of web accessibility lawsuits.
One of the more interesting things about this, though, is, where are these lawsuits happening. And now, in 2018, there’s this big trend towards New York State, Second Circuit. And in particular, it’s in the Southern District of New York. I just gave this presentation just a few days ago at a major law firm in New York. And the breakdown is really startling.
If you look at September, for instance, just this last month, there are only three cases that were nationwide. And then there were 47 cases that were brought in New York State– in New York City. So Southern District of New York is really– Manhattan is what we’re talking about. Even Brooklyn is not even part of the Southern District. So these are basically all downtown New York City cases.
In August, there were 144 cases in the Southern District of New York versus 41 for the entire rest of the country. And those trends pretty much continued. July was 119 cases in Manhattan and four cases brought everywhere else.
And that’s really quite different from previous years. I don’t know what accounts for this. But in previous years, the major centers for litigation have been Southern District of Florida, which is basically southern Florida, Miami in particular, and New York, and a couple in Massachusetts and California.
But for some reason, this year, New York City seems to be the hotbed of litigation. Now this doesn’t mean that just New York companies are getting sued. This is just where they’re getting sued. So you could be a company from Delaware– well, a lot of corporations are based in Delaware– or a company from California. But you’re getting– you have an office in New York City. And for some reason, their New York City presence is what’s getting– is where– is what’s getting some suit.
Or it could just be that the plaintiffs are all in New York City. Or more specifically, what I think is really going on is the plaintiff’s attorney is in New York City. Anyways, so that’s what’s happening in terms of the litigation trends.
Now while you might think that this is all just one big money grab by the plaintiffs’ bar, that would be missing the point, of course. This is what I have to tell my friends in the private sector who don’t know anything about web accessibility. I have to remind them that this is– the web accessibility litigation that we’re talking about is really important for enforcing the rights of people with disabilities. And I think that it really has gone a long way towards improving the awareness of web accessibility, not just in the business environment, but also in that other area of disability rights, mainstream built environment side of accessibility.
Because the Census Bureau tells us that one in seven people in this country has a disability. But the National Federation of the Blind gives us even more interesting statistics. They tell us that 7.3 million people in this country are blind or are functionally blind. In other words, they have a severe visual impairment that impairs– that’s significant enough that they need some accommodation other than simply glasses, that they need some other external aid in order to do their job or to get by in the daily activities of their life. And that’s a significant portion of our population.
Now this trend is only going to continue, of course, as we all know, because the population in our country is getting older. It goes without saying that we, as individuals, are, of course, getting older as time goes by. But what’s important here is that the percentage of the population is actually getting older. And the reason for that is decrease in birth rates. So less people are being born to fill in the early ages time spec continuum– age continuum. And as time marches on, this large chunk of baby boomers, in particular, is getting older and older. And they have become a larger portion of our population.
So in the next 40 years, we’re going from, 15% to 24% are going to be over 65, which is actually pretty startling. And in other countries like Japan and Italy, it’s going to be even more startling to see. And as part of this, all web accessibility is an incredibly important part to make sure that the portion of our population who are blind or who are visually impaired can fully participate in society.
Now of course, web accessibility includes so much more than just blind or visually impaired individuals. But a significant portion of it still involves just fundamental access for people who are visually impaired. And so it’s vitally important to make sure that we get web accessibility addressed to address this aging demographic.
So that’s the importance of web accessibility. I’m probably preaching to the choir with this audience about that. But it’s– I like to think of the importance of web accessibility countervailing against– as a countervailing force against the incredible amount of litigation that we’re seeing. There’s a kind of a push-pull scenario. And sometimes we only hear from one side of the argument.
But it’s important to realize that there’s this other side of the argument that keeps things, I think, more or less in balance. To tell you the truth, even though I mostly work with the defense side in helping corporations address accessibility, I’m very much in favor of all the litigation that’s going on. I just hope that my clients don’t get sued.
Anyway, so let’s talk a little bit about the law. I promised that I’d say just a couple of words about it. This is going to be a whirlwind tour of web accessibility.
There are two basic kinds of law. The first kind of disability law is procurement-based. And here we’re talking about things like Section 508 of the Rehabilitation Act and the various state analogs to Section 508. Here, the focus isn’t really on making sure that any particular individual is accommodated at all. It really is all about making sure that a state agency or the federal government is adhering to particular design standards, like WCAG or like the Section 508 standards, when they’re buying technology.
And here we’ve seen relatively little focus on the litigation perspective. That’s a bit unfortunate, but it also makes sense. It’s kind of hard to find these cases. You really do have to know about a procurement that’s going on in the federal or state government, and then it being challenged. In fact, it’s probably a big contest between losing vendors at this kind of litigation– it’s more likely they come up– than from a person with a disability.
And as I mentioned, it focuses not on whether an individual’s accommodated, but on whether a agency, for instance, met certain procurement requirements when they’re buying their technology to make sure that it adheres to WCAG. The importance, though, of procurement-based disability laws is that they set the infrastructure around which you can provide individual accommodations. So they’re hugely important. But we’re not going to see a whole lot of litigation in this aspect of disability rights.
Where we’re going to see it, instead, is in the more individual-based laws like the Americans with Disabilities Act. Now, most of us think of the ADA as ensuring that goods and services provided by public accommodations are accessible to people with disabilities. And certainly, we see that language in a lot of the lawsuits and a lot of the comments. But really, what it comes down to in the context of websites is this provision. And I’ll read it to you. This comes out of the Title III regulations created by the Justice Department.
“A public accommodation shall take those steps that may be necessary to ensure that no individual with a disability is excluded, denied services, segregated, or otherwise treated differently than other individuals because of the absence of auxiliary aids or services.” And for the legal geeks, that’s 28 CFR, Section 36.303. Anyways, we call this the effective communication requirement. Even though you don’t see those words popping up in any of its language, that’s basically what it is. And I’ll talk about that on the next slide.
So an example of effective communication that we see in a traditional built environment is, for instance– and this is the classic example that we use with the Justice Department– a doctor has to provide a sign language interpreter for a patient who’s deaf so that they can discuss surgery options for the patient’s condition. So if you’re thinking about open-heart surgery, for instance, you probably want– and you’re deaf– you probably want a sign language interpreter there so you can ask all of your questions, like what’s involved in the procedure, and the recovery time, and things like that.
When we transfer that to the digital environment, it has an easy analog. For instance, just in captioning, for instance, a company has to provide captioning for its live webinars. In the print environment, it’s a little different. Because there we’re not talking so much about people who are deaf. Now we’re talking about people who are blind.
So for instance, a restaurant may ask its waiters to read menu options for blind patrons. That’s another example of effective communication. There we’ve got a print media that can’t be made accessible as opposed to oral speech. And similarly, a company has to make sure that its website is accessible to its visitors with disabilities.
So in this sense, what we’re talking about when we deal with web accessibility is nothing new. It comes straight out of the effective communication requirements that were built into the Title II– Title III– regulations from back in 1990, and have been in effect since 1992. Now, I kind of stumbled over my words there, because I said, well, it’s Title II, not Title III. It’s actually– yes, it actually comes from both. Effective communication– the same effective communication requirements are there in Title III of the ADA. But it’s also in Title II of the ADA. The difference is Title III affects private businesses, Title II involves state and local governments.
But it doesn’t just end there. It also continues into the federal government and any federal grantee. And that includes every college or university that accepts student loans according to the Department of Education. So that’s all covered under Section 504 of the Rehabilitation Act. And there you can get in trouble with OCR, or Department of Ed, or any of the agencies that give you money.
It also comes in indirectly in the California Unruh Act. There we don’t see a specific provision that deals with– quite as clear as under the ADA. But we do see this general nondiscrimination requirement for citizens of California with disabilities.
So that’s about it for my legal presentation. If you want more specific details about this, we do have some resources available on our old website, the Cryptzone site. So that’s www.cryptzone.com, where I’ve got a number of legal presentations focusing on all the nuances of effective communication with digital accessibility.
So I’d like to spend the rest of my time really diving into, how do you solve this problem. And here, again, I said, we use a four-step model. This is, again, more or less, the same that every good accessibility company would be doing out there when it comes to web accessibility. The first one is an accessibility statement. I’ll talk about each of these elements separately and dive into them. So there’s no need to take a whole bunch of notes. This is just a summary.
The second element is manual testing of your key use cases and templates. Third is some involvement of automated testing for large enterprise organizations. And the fourth one is what I call creating a culture of accessibility, where we’re really trying to make accessibility self-sustaining so that it doesn’t always have to be constantly harassed at the tail end.
So first is the accessibility statement, which is probably the single most important thing that your organization can do for accessibility. Yet it’s also the one thing that most organizations fail to consider. So what goes into an accessibility statement? Well, it really consists of three parts.
First, there is the accessibility policy. And that sets forth your organization’s commitment to accessibility and identifies your plans for achieving accessibility. So for instance, you can say, in your accessibility policy, if you’re an e-retailer, that you understand the importance of access by your customers with disabilities and your obligations under Title III of the Americans with Disabilities Act. And to that end, you’re going to commit to achieving WCAG 2.0-level AA in all of your new content and as much of your old content as you can get a hold of.
So the second element is the most important one. It’s the contact information. And this is either a telephone number or an email address that customers can use to get back to getting the same information as what is available on your website. You also should provide response time information so that a person with a disability can know when they can call, or if they have to wait for a response, how long they’re going to have to wait.
Now I said that this is the most important element, and this is the reason why– it’s because it goes a long way towards achieving that effective communication requirement that’s under the ADA. Effective communication under the ADA doesn’t have to be perfect communication. So for instance, if you are giving a speech– a public presentation, for instance– and there are– there’s a possibility that you’re going to have deaf participants in the audience, you don’t have to provide a sign language interpreter at that event if you have no reason to believe that there’s not– that there’s– that no one’s going to use it. So one way that you can get around that is you can say, in your announcement, if you require a sign language interpreter, please let us know at least two weeks in advance, and we’ll provide one. Because it takes time to get a sign language interpreter, and it costs a lot of money.
You’re under the gun to actually pay the cost if you’re giving the presentation. But you don’t have to provide it if nobody needs it, obviously. So in that case, it’s not– so the person with a disability still has to give you two weeks’ notice, whereas a person without a disability doesn’t, which might seem unfair. But it’s a practical reality that the organization that’s giving the speech needs time in order to prepare for this.
Similarly, effective communication may be achieved by providing that telephone number and email address. And I say may be because we don’t really know. This hasn’t been tested by the courts very thoroughly. There are some cases, actually, like Robles versus Domino’s Pizza case, that hint that it’s– that that may be a form of– that may be fine as a form of effective communication. And then there are other cases that say, no, that’s not nearly enough. You really– it doesn’t provide the same goods and services.
But it does go a long way towards helping achieve that. And if you can do that while you’re also making a good-faith effort towards making your website accessible, I think that a plaintiff is probably going to look twice before suing you versus suing the person who doesn’t provide that same kind of response mechanism. So it’s absolutely critical, in my opinion, to provide that contact information.
The third element is a best practice. It’s providing a feedback mechanism. And this can also be done through an email address or online form. And basically, what you’re after here is you want to get feedback from your customers on your website, and in particular, areas where they’re having trouble, before they use your contact information, to contact you. So for instance, if you’re an e-commerce site and you have a blind customer who’s having trouble accessing, say, a page in the checkout that is having– that they’re having trouble with on their screen reader, well, you may be working on that page. You may have– you know, you’ve provided, in your accessibility statement, all the contact information.
And– hang on. You may have provided all the contact information that you thought was necessary. But having that feedback mechanism will tell you, oh yes, that area is something that we really, really have to focus on. And that probably should take a top priority because it’s actually causing issues for customers with disabilities.
So let’s see, the next element, moving beyond that super-important accessibility statement, is the second most important element, which is manual testing of your key use cases in your templates. Now fact is that only about a quarter, or maybe a third, of your website– I’m sorry, only a quarter, or maybe a third, of the WCAG 2.0 AA requirements can be robustly tested using automated technologies. And so that means that the rest of those requirements, those 38 requirements, have to be tested manually.
And a way to do that involves having a human being manually read through your web pages using assisted technology. On average, that takes about 30 minutes per page. So if your tester charges you $250 an hour, that’s $125 a page. That’s a lot of money. So you think, oh my god, manual testing is going to cost us a fortune, because we have thousands of web pages.
So then, the first question to ask is, well, what content do you manually test? Well, there, the key question to ask is, why do people go to your website? So here it’s a matter of identifying the key pages that most organizations need– well, can easily identify for pages that are most frequently visited, or the real purpose of the website. So for instance, if you’re an e-commerce site, people will come to your site to search for products, and to add them to their shopping cart, and to go through the checkout procedure. They’re probably not there looking for your information about your board of directors, for instance. So those are the kinds of pages that are critical.
In addition to those key use case pages, it’s also important to get to the template pages. And this is things like recurring content that appears in your menus, or your headers, or your footers. Make sure that you have some pages that incorporate that content. Because if you can get to that content, by taking care of it in one place, you could affect dozens, hundreds, thousands, maybe even your entire website just by getting that template content.
Usually we find that even with really complex sites, with the exception of things like really complex web-based applications, apart from that, usually manual testing, for a typical website, is less than 50 pages. In fact, it’s usually less than 25 pages. So once you’ve identified those 50– or 25 to 50– pages, what do you do? Well, what has to be done for a tester is, an experienced tester will first do a keyboard test. And they’re just making sure that all the content can be accessed using just a keyboard, then using a screen reader to make sure that all the content’s being read out.
And just between those two passes, a really experienced screen reader tester can get at, or understand, where most of the issues are. Now in some cases, they are going to often need a screen magnifier and voice command. A less-experienced tester will typically always use those technologies. But an experienced tester that really has gone through WCAG 2.0 testing a lot will be able to identify, using the first two steps, a keyboard pass and a screen reader, when and where screen magnifiers or voice activation software, voice command software like Dragon NaturallySpeaking, are really going to be needed.
So having noted that, a big question that comes up is whether you need disabled users to actually do the testing. And here I’d say that the most important thing to always keep in mind is that you’re testing needs to conform– needs to test to the WCAG 2 A and AA standards. Using a tester with a disability is important, I believe, because it gets to whether the site is really usable for a person with a disability.
But if you do use a tester with a disability, it’s also important to have a tester without a disability also work on the test. Because we’ve seen– we’ve worked with several customers who have done this– where they’ve had only disabled testers, in fact, only blind users, doing the testing. And when we were– when we shadowed them as they were doing their testing, in some cases, we noticed that entire contents, entire sections of the web page, were being missed. And the tester was going to give it a pass.
And then we said, well, did you see that other content that’s on the page? And they said no. It’s because it’s entirely unavailable to a screen reader. So it’s important that you make sure that, if you have testers with disabilities, you also have testers without disabilities testing alongside them. And then it’s always documented to the WCAG 2.0 standards.
The reason why you have to document to the standards is because you don’t want the test to reflect the individual experiences so much. That’s really more of a usability test. When you’re testing to accessibility, it should be to a universal design standard. And therefore, you’re left to look into WCAG 2.0.
OK, now large organizations, particularly universities, or sites that use, say, very complex content management systems, often have thousands, sometimes even millions, of web pages. And a lot of them vary. And they don’t just all neatly fall into just a couple of key use cases. And in that case, an automated testing becomes important.
Now automated testing, as I mentioned before, is very limited. Only about a quarter, or a third, of the WCAG’s 38 success criteria– or now, I guess, 50 success criteria if you look at 2.1– can be robustly tested using automated testing. But there are some things that can be automatically tested.
Now it so happens that a few years ago, I did some research on what were the key issues that were getting people in trouble. And this was, granted, back in the days of 2015, before we saw this explosion in lawsuits. And I asked myself, what is it– what was it, again, that’s getting people in trouble? And what I found was kind of surprising, that there were four key issues that kept coming up.
And those four key issues are missing alt attributes on images and image maps– so it’s really two key issues– improper table markup, and missing labels and forms. And it seems as though, no matter what complaint I looked to, that those issues were always coming up. The complaints always involved something else too, but those issues just kept coming up. And it just so happens that those key issues can also be tested very well with automated technology. Those issues fall within that quarter or third of the cases that we’re talking about.
So it’s important to include automated testing of those key issues, those four key accessibility issues, because they come up so often in litigation. In fact, I believe that a lot of private plaintiffs are using them to screen lawsuits in the first instance. That’s just a hunch of mine, because they just keep coming up still. And it makes sense that, if you’re filing, say, 300 lawsuits a year, because you’re one of those large plaintiff law firms that does a lot of web accessibility litigation, and you’re trying to figure out which companies to go after, you need something to screen them with before you have your nominal plaintiff go and actually look at the page using a screen reader. And I believe that the easiest way to screen them is to just sit back at your computer and use an automated testing tool.
So there’s also some other advantages, other than just avoiding plaintiffs, that are reasons to use automated testing. One is accountability and double-checking your team’s work. So if you use automated testing as part of your development process, you can make sure that the team actually did some of the basic things that they did without having to hire an external tester.
Another key advantage that a lot of organizations find valuable is measurable progress. So if you take a snapshot of your website today, you might notice that 40% of your images are missing alt attributes entirely. Then, three months from now, if you make a concerted effort at addressing those, that number goes down to 22%. Well, a drop from 40% to 22% is a much better improvement for telling a boss than saying, oh yeah, we just caught a bunch of them. Giving actual metrics to things is something that really proves the business case around why investing the money in automated testing makes sense, and why your accessibility program should continue.
So everything that I’ve talked about until now– the automated testing and manual testing– addresses the problem in the moment. It doesn’t really address the problem for the future. So in order to create a self-sustaining culture of accessibility, that’s what gets a little bit more complicated.
Here, I think that there’s one really cool technique that we came up when we were working with a major electronics firm recently, in the Northeast. And that was using checklists. And the idea here is to create a specific set of requirements that are based on WCAG that are associated with each design– each role within the web design and development process.
So if we think about how to inject a– how to inject WCAG into this, most organizations will just throw WCAG– all the WCAG 38 success criteria at the development end. And that doesn’t make sense. Instead, what you do– what we found is much more helpful is to– my slideshow suddenly stopped. I apologize for this. All right, PowerPoint is giving me issues. I’m getting a little spinning whirlwind here thanks to my Mac.
Uh-oh, we could be in trouble. And it’s entirely my computer’s fault. Well, I can talk over this, assuming you’re still getting audio. Because my PowerPoint seems to be dead.
The idea is that you create a checklist for each of the different stages of the development process. So design would get its own checklist, copy would get its own checklist, and development would get its own checklist.
Oh great, PowerPoint isn’t responding right now. OK. I guess we’ll wait.
And then, another step is to create what– is to create a so-called input checklist. So before a design goes to copy, there’s a certain sort of requirements that the copy team is going to look for before they will accept the project. That’s an input checklist.
And so they’re going to look for making sure that design, for instance, incorporated all the elements that they should be worried about. So design would take care of things like color contrast, and making sure that they specified tab order, and things like that. Copy would say– copy would look at that wireframe that they’re getting. And if it doesn’t include all of those things, then they wouldn’t accept it.
The copy team also has its own set of requirements that it has to meet. So for instance, the copy team might be responsible for writing out the alt attribute text that goes along with each image. And then that’s part of their checklist.
Development would have its own input checklist to make sure that copy did its job of providing all that alt text. So when they’re actually creating their work– and they have their own output checklist– that they know exactly what text to put in there, they don’t have to think about it, because it was given to them by the copy team. So that’s basically how you get around that.
This method of using checklists, we find, has a number of advantages. It’s very flexible. It works across waterfall, agile. Doesn’t really matter. It’s self-policing, creates– has a whole set of built-in reminders because of those input checklists. It eliminates the back-loading to the developers because every organization in the whole web design process now has some stake in the inaccessibility.
It also creates much better training because then you can identify which elements of the training should be targeted to each individual group as opposed to just throwing a general WCAG training at everybody. And because everybody knows their job, everybody has outcomes that are being expected by others. It really does create this culture of accessibility. So basically, that’s our four-step model– accessibility statement, manual testing with the key use cases and templates, automated testing, and then creating this culture of accessibility.
So with that, I will– hopefully my computer will let me hand this back over to Sofia.
SOFIA LEIVA: So thank you so much, Ken. And we’re getting ready to begin the Q&A. So the first question that we have today is, we know the public side of websites need to be accessible. My question is about the requirement for content behind a login. Does it need to be always accessible, or can we wait for a request for an accommodation?
KEN NAKATA: You should try to make it always accessible, I’d say. But your risk exposure is a lot lower. A funny thing is I was just giving this– I mentioned I was just giving that presentation in New York with a law firm. And the other lawyers that I was giving the presentation with were all employment lawyers. And they kept talking about the importance of making sure that stuff behind the login, the stuff that’s only accessed by employees, is accessible.
On one hand, your exposure is lower, because you’re probably not going to get a drive-by plaintiff suing you. On the other hand, the exposure could be greater, because their point was that, in employment cases, you get emotional distress, and you get all these other elements in employment litigation that juries tend to award big awards for. So there’s two competing forces there when we’re talking about stuff that’s only accessed by employees.
SOFIA LEIVA: Great, thank you. The next question we have is, can you explain the level A and level AA standards?
KEN NAKATA: Not in less than an hour, I can’t. But I could just generally say that the A are– the thought behind A, AA, and AAA is the level of importance it is for people with disabilities. A is the very basic, fundamental things that have to be addressed. AA is really the important, really more robust set of accessibility requirements that are practical for an organization. And AAA are really best practices. Even the W3C says, on its website– or at least it used to– that AAA was really an impractical set of standards for most organizations to try to achieve, and that really, the AAA should be thought of as, if you’re trying to tailor your site towards a particular demographic, then there are certain AAA requirements that are specific to those demographics that you should consider.
SOFIA LEIVA: Great, thank you. The next question we have is, can someone file a lawsuit against a website immediately, or do they have to request that the company update their site first– for those of us who work for companies behind the times.
KEN NAKATA: Yeah, so they can file a suit with you directly. In fact, that’s most– some of those requirements about timing, and lawsuits, and things like that are controlled by the local rules in each district. But from what I’ve seen in New York, they tend to shoot first and ask questions later. So in fact, a lot of those cases, the first time that the company ever hears about it is when they’re getting served a summons.
SOFIA LEIVA: Great, thank you. The next question we have is, are there websites that can test your company’s website and forms for compliance?
KEN NAKATA: Yeah, sure. I mean, there’s a lot of automated testing tools that are out there for free right now. Our company has one called Cynthia Says. And it’ll give you a general sense as to whether a particular URL on your page is accessible. There are others that will do a rudimentary crawl of your website for free. Among the automated testing tools, we’ve got one that is much more robust in terms of testing.
But each of us, quite frankly– us and our competitors– we each have our own little niche, I guess, in the market, in the automated testing market. But as I said, they’re going to tell you, generally, about all the WCAG. But really, in terms of whether a particular page meets all the requirements, no tool can tell you that, because so much of it requires manual testing.
SOFIA LEIVA: Great, thank you. We did have a couple requests, if you were able to share the checklists you talked about.
KEN NAKATA: Yeah, OK. That really– I do have a general checklist. And I’d be happy to talk to anyone about that. The reason I’m a little hesitant about just sharing that out is because it is so dependent upon a customer’s development environment. So for instance, what I had to do with that electronics company that I was mentioning was I had to get members of the design team. I had to get members of the copy team. I had to get folks from the development team. I had to get the guys who created the videos that are available on the site. I had to get the guys that are in control of managing contractors into a meeting.
And we all had to sit down in a meeting, all at the same time. And so we had about a dozen people in this meeting. And it went all day. And we basically went through a general set of WCAG requirements and just parsed it out between each of them. And there was a little bit of fighting between different groups that, you know, I don’t want to handle this particular requirement, or this should really be somebody else’s job, until finally, we are able to get agreement onto the idea of who was going to handle each specific task.
But it’s trying to take WCAG and fleshing it out to make it more specific. So for instance, like, when we think of WCAG 1.1.1, which deals, generally, with alt text, we come up with a specific requirement, you know? Instead of saying the abstract language that’s used in 1.1.1, we would say all graphics need to have an associated alt attribute. And that’s the general requirement. And then there’s other general requirements similar to that that fall within 1.1.1, but that’s a specific one. That’s just one specific one.
And then it’s a matter of figuring out, OK, who’s responsible for that task. And who’s input is it? And who’s output is it? And yeah, so I could give you– I could give– I could give you some idea as to what that general universal list is like. But after that, it’s a matter of parsing it out.
SOFIA LEIVA: Great, thank you. The next question we had is, what should everyone do on day one when implementing accessibility?
KEN NAKATA: I think the accessibility statement’s the number-one thing.
SOFIA LEIVA: Cool, thank you. The next question we had is, in a world where you have no team, what can you still accomplish, and how?
KEN NAKATA: If you have no team– somebody has to be creating that web content. And oh, I think if you– first, you go to your boss. And you tell them– you give them the business case around why it’s important. To do that, you bring up this fact– the fact that we’re getting this explosion in web accessibility recently, and that it’s just a matter of time before our organization is going to get tagged with an accessibility lawsuit.
We’re seeing not-for-profits get sued. We’re seeing universities get sued. We’re seeing state and local governments getting sued, all in this– all by plaintiffs in web accessibility. So that’s the first thing.
Once you do that, once you’ve scared your boss enough, then you tell them, well, we’ve got to do something about this. And so in that case, I’d say you have to hire a contractor to do some manual testing. That’s probably actually a bread and butter of what we do as well as most testing organizations do.
And that’s the main thing. You’ll get a report back from us or one of our competitors that will tell you exactly what’s wrong with your website and what has to be fixed. And then it’s a matter of just getting that implemented, either through a contractor or through whatever resources that you’ve got internally. Like, if you do have a web development team, then it’s a matter of getting your boss to raise enough awareness around this issue so that those issues get taken care of.
Then, depending upon the complexity of it, then you should get into checklists, or you don’t have to get into checklists. To tell you the truth, I mean, that whole checklist idea is something that– is something that only, really, more mature organizations do.
SOFIA LEIVA: Thank you, Ken. The next question we have is, do the same standards apply to employee internets?
KEN NAKATA: Yeah, that’s basically the same question as the whether we should take care of things that are behind the firewall that are available beyond the– or a login for employees. So yes, you should. And the reason is your chances of getting tagged in a drive-by lawsuit are smaller, but the potential for larger damages is higher. So yeah, you should take care of it. I think it’s a lower risk. An employment lawyer would probably tell you it’s a higher risk.
SOFIA LEIVA: Thanks, Ken. The next question we have is, we’d like to go back to accessibility behind logins, specific to colleges, in Section 504. We’re wondering if there is any legal requirement for our classes in a learning management system, if they need to be accessible even if there isn’t a student, you know, accommodations in the class or our faculty don’t think it is needed until a request is made.
KEN NAKATA: Yeah, so that’s troubling. That’s a matter for Department of Ed to talk about. My feeling about it is that universities should do it anyways. And the reason why is because, in college, at least when I was in college, students used to drop in and drop out of classes at a moment’s notice. And then, all of a sudden, when you have to hand it– when you, all of a sudden, drop in, you’ve got assignments that are due very quickly. Or you’ve got reading assignments that are due. Or you’ve got projects that you’ve got to do.
And if you suddenly wait for the accommodation, you’re putting that student already behind. And so it really does affect the learning opportunities for a student with a disability. Colleges and universities are really in a unique situation in that regard, because the timeliness of the information, and the importance of timeliness of information, is really critical.
But maybe I was just a really diligent student. I don’t know. I was one of those kids who never got a– who never asked for an extension, because I felt like I had to meet every single deadline. But maybe that’s not the case anymore. I don’t know.
SOFIA LEIVA: I was the same way, Ken.
KEN NAKATA: OK, yeah. So we get the importance of the timing in colleges and universities. It’s kind of like paying your taxes, right? You don’t want the IRS to have an inaccessible site on April the 14th, right? You know?
SOFIA LEIVA: Exactly. That’s a great metaphor.
KEN NAKATA: Yeah, it’s important. Yeah, yeah.
SOFIA LEIVA: The next question we have is, how much of a threat are these drive-bys? If they aren’t representing actual people being affected, can they be thrown out? Or is it still involving actual lawyers?
KEN NAKATA: Oh, they do involve actual lawyers, and they do involve the actual plaintiffs. And in many cases, they actually involve plaintiffs who actually use those goods and services. It’s just that the web, nowadays, is used by so many people. And so many people use so many different websites.
So for instance, the Gil versus Winn-Dixie case– that was the really famous case recently in the Southern District of Florida that went all the way to trial. I’m absolutely confident that Mr. Gil used Winn-Dixie. And I’m absolutely confident that he really was a regular customer who used the website.
Did his attorney use an automated tool? I don’t know, to tell you the truth, whether they used an automated tool to screen cases and figure out that Winn-Dixie was a likely target. But in that case, I’m pretty– I’m absolutely confident that– you know, that he benefited from the ultimate result in that case.
In other cases, it’s not as clear. And this point really does come up a lot in the credit union litigation that we’re seeing. So in those cases, we’ve got plaintiffs who have no intention of becoming a member of a credit union, or a specific credit union. They may be hundreds of miles away, or they may not even meet the minimum qualification to ever become a customer of that credit union, but they file a lawsuit against it anyways.
Yeah, those kinds of cases– in those cases, those are just purely nuisance cases. And the Credit Union Association is actually the ones who are spearheading this movement in Congress to have the Justice Department say something– give further guidance on web accessibility, because they’re so annoyed by the fact that these ridiculous plaintiffs are suing them. So it goes both ways. Sometimes they’re just nuisances, and sometimes they’re not.
SOFIA LEIVA: Great, thank you. The next question we have is, what are some of the award sizes being handed out in these lawsuits that win?
KEN NAKATA: That’s a great question. Well, most of these cases never see trial. They always settle pretrial. In fact, only two cases that have gone into federal court have gone all the way to trial, or to a dispositive stage, by the judge. One of them was Gil versus Winn-Dixie. Another one was– let’s see. Gosh, my mind is slipping. I can’t remember it. It was a more recent case where it was disposed of on summary judgment.
Anyways, in Gil, the damages weren’t that significant because the ADA doesn’t allow for the award of things like emotional distress, or punitive damages, or anything like that like you’d have in a typical torts case, like a product liability case. By contrast, in things like– if you do have a case in California, however, you end up with the Unruh Act, which has liquidated damages of $4,000 per claim. There, you can get into some significant damages.
So the case we all know about is the NFB versus Target case, where they ended up settling for $6 million. $6 million was a lot of money, it seems. But in actuality, I think it would have been– it’s actually quite small compared to what their potential exposure was given the fact that they had class action. And each member of that class is entitled to $4,000. And if you just add up the number of plaintiffs that you have in California in a class action, it can easily get to a sizable amount of money.
And then there’s also the question about, well, what constitutes a claim? Is it every time that you file a lawsuit? Is it every time you encounter a barrier on a website? Or is it every time that you can’t do a whole transaction? What does it mean? There’s been a little bit of clarity added recently by California’s Superior Court opinion, but it certainly isn’t dispositive of the issue. And we don’t really have much guidance.
So if you get sued in California, potential damages are huge. If you get sued anywhere else, potential damages are actually not that huge. Nevertheless, you don’t want one of these things. You will end up paying a fortune in attorneys’ fees.
SOFIA LEIVA: Thanks, Ken. I think we have time for a couple more questions. The next question we have is, the fear at our institution is that if we go to a company to test our accessibility, they will report us or make us fix our problems in an unrealistic time frame. Is this true of your company?
KEN NAKATA: No, most of the private companies won’t do that. So if you go to us or one of our competitors– I have to give our competitors a shout-out, because I don’t want this to be a product pitch or a company pitch. But if you go to us or one of our competitors, we’re not going to turn you in.
By contrast, if you go– I would be concerned about just turning to a disability rights organization and having them test you, because their interest is really focused on advocacy for their members. And if their members are all people with disabilities, then that can obviously cause some issues. But all the rest of us understand that you’re trying to stay out of trouble. And we’ll strongly advise you to do things. But if you decide– to make your website accessible. But if you decide not to, that’s your own business.
On the other hand, I should say, there is some concern about whether it’s discoverable. So we can’t turn you in. But if you get sued, and they make a– they ask you, in discovery, whether you’ve ever had a accessibility review of your website, you’re going to have to turn over our report. That’s true. So we’re not turning– we’re not turning you in. Instead, you’re turning yourself in, basically, because of discovery.
But you can prevent that. And the way in which you prevent that is you have representation from counsel. And you have your attorney act as the conduit for the report. Because if our accessibility report then goes to your attorney, then that is protected under attorney-client privilege and attorney– attorney-client privilege as well as attorney work product privilege, because it’s in the anticipation of litigation.
And in that case, then your attorney can say, yes, we have a report. But we’re not turning it over to you, because it’s protected by privilege. If you do it outside of that having an attorney involved, then it’s not protected by privilege. And your attorney will tell you to turn it over.
SOFIA LEIVA: Thanks, Ken. The next question we have is, WCAG 2.1 recently came out. Should we develop any test to– or should we develop and test to 2.1 instead of 2.0? Or is 2.1 used as a standard in any litigation?
KEN NAKATA: Yeah, so 2.1 is not used in– hasn’t been used in litigation yet. W3C’s still working on the techniques and guidance that’s associated with the techniques that were added under 2.1. 2.1 has, I think, 50 success criteria, level A, and AA. And 2.0 has 38. And the difference, that delta of 12 requirements, are just purely additive.
So if you meet 2.0, don’t worry. Your effort has not been in vain. It’s already gone a long way towards meeting 2.1. And so I’d say go for 2.0 right now because the way in which you do it is pretty well-established. And it’s very well-documented and very well-known. It’s been out for over 10 years. So we know exactly how to develop to 2.0. And then as a later-on project, make 2.1 the next goal once all the techniques are fleshed out.
SOFIA LEIVA: Thanks, Ken. And I think we have time for one more question. Can we get sued for accessibility even if we are currently working on accessibility?
KEN NAKATA: Yeah, so that’s a really great question. There was a case recently involving Hooters restaurant where they settled a case with one attorney and were working on accessibility– improving the accessibility in order to meet the terms of the settlement agreement that they reached with that attorney. And then another attorney came along and sued them again for web accessibility.
And they said, your honor, we don’t think that we’ve got a– the second case should be dismissed, because we’re already working on accessibility to satisfy the first attorney. And this case actually– I forgot how it was decided at the district court level. But the 11th Circuit, which is an appellate court, obviously, said, sorry, the second lawsuit can proceed because the second attorney has no stake in what you agreed to in the first lawsuit. And so unless you’ve achieved WCAG 2.0 and can show that all the second attorney’s claims are moot, because they’ve already been addressed and have already been fixed, you’re still under the gun. And so you still can easily get sued by another person.
SOFIA LEIVA: Thanks, Ken.