Web Accessibility: Who is Responsible? - Andrew Kirkpatrick

Transcript for Who is Responsible for Web Accessibility?

Hello. My name is Andrew Kirkpatrick and I'm the Director of Accessibility for Adobe. I head up a team of engineers and product managers that work across the Adobe product line to help our teams understand requirements for accessibility, to work on standards, and to help our engineers implement accessibility successfully in our products. I've worked on accessibility now for almost 20 years and have been involved with standards work at the World Wide Web Consortium (W3C), including being the Co-Chair and Co-Editor of Web Content Accessibility Guidelines (WCAG) version 2.1, and use that work with our teams at Adobe all the time.

So today I'm here to talk about website accessibility and ultimately who is responsible for the sites addressing accessibility and being able to be used by anybody. So can a vendor guarantee that their site will produce an accessible site, that their product will produce an accessible site? The short answer to that is no. We get this question asked a lot.

There's a variety of different tools that are out there in the world. Adobe has tools like Adobe
Experience Manager and Adobe Commerce, which are used to produce web content, websites, web applications, and those other products that are out on the market as well. There's still tools that are targeted at enterprise customers, and there's a target set products that are targeted toward consumers
and other small organizations.

And a lot of these tools have varying levels of technical expectations for the people who are ultimately creating the content. So is it possible to choose a tool that completely eliminates the need for that customer to think about accessibility as they're developing their site?

To build an accessible website, you need to think about accessibility from design through development testing as part of that testing, you know, testing, technical testing, testing with end users. But there's elements that require input from the authors as that work is going on. A tool can handle some things automatically, and a tool can also constrain the content in such a way that the customer who's implementing the site has fewer choices and therefore can be forced into a more accessible end result.

But that's often not what customers want. But if we looked at, you know, just a few different examples here, a tool can require that images that are placed into a site have alternative text. That's pretty easy to do. There's a requirement within Section 508 in the US that requires that there's prompting for accessibility information and prompting for alternative text is one of those things.

But can the tool verify that the text is appropriate? Also, it can make the developer add alternative text, but it can't stop them from adding junk alternative text or inappropriate alternative text. Similarly, tools
can provide the ability to add headings, but the tool itself can't enforce that those headings are used incorrectly. That they're put on text that shouldn't be headings or that text that is a heading actually has has that heading applied to it.

So there's important work that tools need to do to provide capabilities, but ultimately the authors need to be very involved in that process. Same thing happens for items like tab order when you're adding content onto a into a website, different color choices. Most customers want to be able to apply their
own design decisions, their own design system in the cases of companies that have whole design systems. They're not looking for the small selection of color combinations that a tool provides.

They want to use their specific colors, and that applies to different design elements as well as text contrast. And then also, of course, there's customers who want to be able to add in video into their content. So if you add in video is the tool that allows you to add a link to a video responsible for that video having closed captions or having audio description? As a tool vendor, I would say that's a very
difficult thing for us to be responsible for.
We want to make it possible for people to add a video and to add closed captionings or audio
description or both to that. But we can't very well... We can't very easily mandate that for all videos.

Ultimately, it kind of comes down to us from this, looking at this and saying that more customization options for content are what our customers want.

But in providing that for customers, that also increases the burden on those site developers to make sure that the changes that they make, the choices that they make, the different content that they're providing, is accessible. So how much can we do for customers? And I think that the answer there depends on what the product is doing. It depends on the level of development that is provided or that's
expected from the customers.

If we have a product that has a component library that is available for the customers to use, and that component library is further customizable by the customers, then again, they have more responsibilities
to make sure that they haven't changed the accessibility that was provided. Or if we provide a component library and those are the only components that customers can use, then customers would naturally want those components to be accessible and to not have to worry about whether they have
accessibility problems or not.

So depending on what level of flexibility the customers have, there's different responsibilities that a vendor may have for what they're doing. One example of this is that in Adobe's Experience Manager
product, we provide a set of core components. And we do work to make sure that those core
components address accessibility so that if you're putting in, whether it's a checkbox component or a tab system component, that it has keyboard accessibility and it is expressing the right information to assistive technologies so that when people are using it, they can count on a certain level of accessibility.
But AEM is a very flexible product, and we have customers who don't want to use the core components.

They want to develop their own. So when they develop their own components, they are entirely responsible for all of the accessibility of those components. And for some of our large enterprise customers, that's fine because they know what they're doing.

But for other customers, accessibility is still new to them so that they're adding to their workload by choosing the more custom route. I think that the bottom line that I want to emphasize here is that when we think about accessibility conformance, right now, you cannot verify conformance with accessibility
standards completely from an automated fashion. So there's tools like ACTs that are used to do accessibility checking on sites, and they will verify a percentage 30/50/60% of the content of your site, 30/50/60% of the rules that you're trying to conform to on the site.
it will be able to check, but there's still a need for manual verification of certain accessibility rules. And that's things like the alternative text quality, the order of headings, tab order being correct, the reading order being correct. If these things are not verified, then there may be issues there. And so unless a tool
can fully automate the accessibility checking, the person or people who are doing that development work are going to have the final responsibility for whether that content meets or doesn't meet the accessibility standards. One of the questions that comes up a lot is can customers just require accessibility in a contract?

We get this a lot. We get requests from customers with legal language that says that, you know, we need to agree to indemnify the customer against any and all complaints against them related to the Americans with Disabilities Act (ADA). And we can't accept that. If we were building the site using
professional services organization to build a site for a customer and we're using Adobe Experience Manager or using some other tool, but we had people who were responsible from beginning to the end.

Then in that situation, sure, you can and probably should include accessibility in a contract to be able to say, "OK, you're building this site for us. We want you to verify that you're going to build it in an accessible manner." And a good vendor would say, "OK, here's how we're going to verify that." That's
what's going to constitute the acceptance criteria, and we're good with that.

And if that's the situation, then you'd be able to use a contract to help ensure that accessibility is addressed in your site. But if you're using a tool and there's not human developers, human testers, who
are involved in that process, you won't be able to do that. And we can't accept language that says we will guarantee conformance with the ADA or guarantee conformance with the Web Content Accessibility Guidelines, because there's that flexibility in terms of the content that's being created by the customers.

Another reason, too, that we get why we can't say that we will guarantee conformance with the ADA, is that in that case, there's also no technical standards that are yet available for the ADA. There's been guidance that's been provided that WCAG is a standard that, if followed, will allow customers to meet
their obligations under the ADA. But again, this hasn't been fully clarified in terms of courts accepting that.

So conformance with WCAG is the best we can do right now with regard to a standard for meeting the ADA. But if customers were coming to me and saying we want you to put in language to guarantee accessibility and your building that site, I would be looking to specify a specific standard like WCAG as
opposed to the ADA which has just a general language related to accessibility.
So can you require accessibility in a contract? Yes, sometimes. But when you're talking about tools, it gets much more complicated to be able to do that.

So what should vendors do? The main driver that affects web content development products and platform providers is customer interest in accessibility. If we have customers that are asking for accessibility, demanding accessibility, then we're going to be looking at that very, very seriously. Also, we do know that supporting accessibility is morally and the right thing to do, right? It's not that the only way we're going to support accessibility is if there's a law that says we have to or if there's customers that are demanding it.
But accessibility is a topic that is prioritized along with security and other features. So if we have customers who are interested in it and speaking up for support for accessibility, that helps a lot. I can say from a perspective of a company where my team is working to encourage our product teams to
support accessibility, that when customers want something, it is far more impactful than if I and my team want it.

But reporting accurately on accessibility in your products is incredibly important. When we're trying to sell a product to a customer who wants accessibility, we make sure that we have our accessibility conformance reports that says, "This is what you can do, this is what the product does for you, this is 
what the product is not capable of doing" and makes it clear to the customers what they are, what they're purchasing, and what they're taking on as their own responsibilities.
If someone buys AEM thinking that it's going to caption the videos for them, they're going to be disappointed because that's not what AEM does. I'll talk about a product that does do that, but the AEM product is capable of embedding a video within a web page. It's it's capable of providing closed captioning, a link to a closed captioning files that it will display closed captioning, but it's not a
captioning tool.

So making sure it's clear to customers what they can expect is incredibly helpful. And even if a company has an inaccessible tool, you want those customers to be able to make an informed decision to buy something else or to understand what gaps they need to address in their own development process.
And as long as you are reporting accurately and honestly on what your product is capable of, I think that decreases your risk overall of customers feeling like you have not met your obligations.

It may increase your risk of customer switching tools if your product doesn't address accessibility, but at least they're making the decisions based on facts. So I want to provide just one example of something that we do, and this is with Premiere Pro. Premiere Pro, if you're not familiar with it, is a video editing
tool. And for most of its life as a product, it's been used to create videos and closed captioning has been a part of that process for the past several years and we've continued to improve on that.

But initially it was just one tool in a chain. So if you were creating a website that needed to conform with Section 508 or with the ADA or WCAG and you had a video, you could take that video and have it closed captioned through a third party vendor. You could do it by hand with a text editor writing the caption
file.

You could download a free tool to be able to create closed captions for it. So there was other ways that you could produce closed captioning and Premiere was just a tool that didn't do anything about that.

And we had customers that wanted a one-stop shopping basically for their video production process.

They wanted captioning to be included as part of that.

So several years ago, probably like probably ten, over ten years ago, we added in support for closed captioning into Premiere Pro. But recently we've added additional improvements to it, in this case speech-to-text and auto captioning. So Premiere will with the press of a button do speech-to-text to transcribe the content of the spoken content within a video and then it will allow you to automatically
create captions and because it's automatic, there's still going to be some errors that may exist.

But it allows you to go and tweak those captions so that if it misunderstood what someone was saying, you can edit that text right in Premiere, but because it's done so much of the work for you up to that
point, the edits are generally pretty straightforward. So this is a tool that we didn't need in order to conform with the ADA or to conform with any other standard.

We did this because we wanted to make the process easier for customers. We wanted to make Premiere be the tool of choice for people who are using video and wanting to make sure that that video is accessible. So I think that this is really the process that we're going to use and we want to see companies paying attention to. We want our customers to be paying attention to as well.

In terms of letting vendors know what they need. Accessibility is a lot of work for some vendors, for some customers, and vendors need to hear from customers that they want accessibility to be easier.

They want there to be better tools available to make it harder to create inaccessible content. And in the case of videos with Premiere, I think that process has been successful and we've got great tools there.

It's harder for web content because there's so much greater variety in terms of what people can create.

But ultimately by engaging with vendors and understanding what their own responsibilities are, our customers can help move the ball forward more, more quickly by getting the vendors to work with them
to implement better and better support for accessibility.