PEAT Talks Transcript: How and Why to Make VPATs a Priority

Introduction

Welcome to PEAT Talks. This is our Virtual Speaker series from the Partnership on Employment and Accessible Technology. We hold these every third Thursday of the month, always at 2:00 p.m. Eastern. Our aim in PEAT Talks is to really showcase various organizations and individuals whose work and innovations are dancing successful workplace technology.

My name is Josh Christianson. I'm the Project Director for PEATs, and I'll be hosting today's talk. First, we want to go over a couple of logistics; so if we could move over to that slide, we'll cover that. Just letting you all know that we will definitely have time for Q&A at the end of the talk. So we'll save some time and can answer questions. Please, at any time, feel free to use the Chat pod and pop a question in there. We will moderate that and get those at the end. So use the Chat box for any questions you may have.

Also, if you have any technical difficulties, you can use the Chat box. We'll try our best to resolve them and communicate with you folks there if there's anything we can do to help. You'll be able to download the presentation from PEATworks.org, and we will send out an archived recording to be posted online following today's event.

For those of you on Twitter who want to multitask, we are live tweeting today's webinar from the account @PEATworks, that's at P-E-A-T-w-o-r-k-s. So feel free to join us there, and you can follow along the conversation using #PEATTALKS, that's PEATTalks with two "T's" and an "s" at the end. So you can follow us on Twitter there.

We are very pleased today to have Ted Gies and Jay Nemchik from Elsevier join us. Ted Gies leads the Web Accessibility initiative at Elsevier and their parent company RELX. He co-authored the company's accessibility policy – yay for you, Ted – and developed several learning tools on disability and assistive technology.

Jay Nemchik is a Web Accessibility Specialist at Elsevier. He works closely with developers to achieve compliance throughout the development process, and he evaluates Elsevier's website and applications for accessibility compliance with both Section 508 and WCAG 2.0 International Standards. Today Ted and Jay are here to discuss the business significance of VPAT…why Elsevier makes them a priority and their best practices for handling requests.

With that, I will turn it over to Ted and Jay for the presentation.

Presentation

Thank you, Josh. It's a pleasure to be here today.

Welcome.

I'm Ted Gies, UX and Accessibility Lead for Elsevier. In a little bit you'll hear from Jay Nemchik, Accessibility Specialist. Today we're going to define what a VPAT is, why they're important, what our service package looks like, and what are some of the external trends shaping the way we handle accessibility inquiries.

A little bit about our company, Elsevier, that I have the privilege to work for…our flagship product is the Web Database Science Direct; and it provides access to 3,800 peer review journals and more than 40,000 books. But oh no…we are not just a publisher; we are transitioning to an information analytics company that helps you progress in science, advanced healthcare, and improved performance in a variety of domains.

Elsevier is a prolific publisher in disability and accessibility. We just published a new book called "Creating a Culture of Accessibility in the Sciences," and our accessibility team is highly collaborative. We've worked with a number of different firms, such as my friends from Highsoft, on accessible SVG charts; and we're open to collaborating with a number of firms in the industry.

Let's talk about VPATs, which I think are for both business and measure. The Information Technology Information Council invented the VPAT in 2001 in association with the U.S. GSA, the General Services Administration. The VPAT is a document meant to measure product conformance with the U.S. 508 Accessibility Standards. VPAT in business is a tool the Federal Government Procurement uses to select the most 508-compliant solutions.

VPATs have pretty much become the standard format for many U.S. colleges when inquiring about a product's 508 accessibility compliance. As we know, the U.S. Access Board is the group that manages the U.S. 508 standards; but they don't manage the VPAT. The 508 standards are intended to help improve the access of electronic and information technology to people with disabilities.

Here are some facts and figures on VPATs at Elsevier. Last year, our team completed more than 40 VPATs, which was a record year for us. Our VPATs are commonly created in response to customer inquiries during subscription renewals or campus policy vendor audits. And requests are rising; they seem to be doubling in some years recently.

So where do these VPAT requests come from?

Well, in our company, 70% of them come in through our sales department; about 20% through legal and contracts; and then 10% through a public company accessibility inbox.

So who is requesting VPATs from external groups?

Well, it's a mix; it's not just one kind of role. You have procurement specialists at universities. You have librarians. You have accessibility services and disability services. Even deans of colleges and instructors trying to make sure whatever e-Courses or products they purchase are acceptable.

By the way, 508 – well, customers are using a variety of language in requesting VPATs. They may ask for ADA compliance, 508 compliance, or even WCAG compliance. So I think they all pretty much are asking for the same kind of VPAT document; but just know that there's a variety of language in the requests, which we kind of interpret and deliver an appropriate document back to the customer.

Our VPATs are, on average, about 12 pages in length and can take anywhere from about a day to a week-and-a-half, depending upon the complexity of the site and the number of pages we sample.

So…on to the next slide.

I wanted to talk about some of the challenges we have with managing our great many VPATs. As a large company with…I think we're about 7,000 to 8,000 employees, hundreds of platforms, we have a lot of volume. It's not uncommon to have three or four VPAT inquiries in a week. Occasionally I've seen them in a day…that many. Occasionally we've gotten VPAT requests from a customer for a bundle of 10 eBooks or 10 products at a time, so there's a little bit of unpredictability and spikes.

So how do you manage all that?

And keep in mind, a lot of times we're helping out our friends in sales. Sales folks…they're high energy, usually under tight deadline pressures. Accessibility compliance is just one of many documents needed for a purchase agreement.

Remind me, what is a VPAT again? What does it stand for?

The name isn't all that descriptive, and we have to over communicate in our company to make sure people all kind of realize that this is about Web accessibility. It's about making sure products are usable by everybody…anybody with a disability included. So a lot of our internal stakeholders are not technical people…sales, marketing managers, product managers. Some of them have not heard of VPATs or don't necessarily understand what the legal obligations are for providing accessible solutions. So, yeah, we've had to kind of over educate and communicate.

Finally, some of our platforms utilize third-party software; and, of course, we want to ensure the entire product is accessible. So sometimes we have to chase down a third party, such as a book player, vendor or other plug-in provider; and our suppliers don't always have a current VPAT, so that could be a challenge.

So what are customers really asking for when they request a VPAT?

By the way, it's an acronym. I should have said it's a voluntary product accessibility template, right? That's what the letters stand for.

What customers really want to know is whether the product they are considering purchasing is compliant with the 508 accessibility standards. As we know, this is not a simple "Yes" or "No" answer; 508 compliance for Web applications is a matrix of at least 38 checkpoints across a number of Web pages measured.

This particular slide is a bit of a parody. It shows a graphic of Pinocchio with the deceitful character, Honest Jon, with his arm around Pinoc. Jon is holding a fully-compliant VPAT saying, "Yes, of course, my boy; we are 508 compliant. Our VPAT shows that we are supports all the way."

So…do you really believe Honest Jon's VPAT?

Well, from talking with external folks at universities, two main pain points around 508 compliance and VPATs include, number one, inaccurate or fraudulent VPATs; number two, lack of details for determining conformance to accessibility requirements.

So just from doing some research on the Web, I've seen some very suspicious-looking VPATs where everything is marked as supports, which is basically you pass the checkpoints; and in the VPAT, there are literally no supporting remarks or explanations, which of course you're supposed to complete to give your VPAT some substance, to give it some veracity.

And it looks like the Honest Jon VPATs took about five minutes to throw together. So I'd be curious to know, either in Chat or when we get to Q&A, if anybody else has ever come across an Honest Jon VPAT. Unfortunately, some of the biggest IT companies I've seen are still kind of putting these out there. In my opinion, it reduces the credibility of a product's accessibility overall; and it's really not a helpful deliverable to produce an Honest Jon VPAT.

I'm going to turn it over to Jay, and he's going to help us understand how we answer the 508 compliance question.

Okay, so our best answer to a customer about 508 compliance is a detailed VPAT with an overview of passes and fails. To accompany that, we create a separate table that tallies supports, does not support, et cetera. Due to the Section 508 refresh, we evaluate our product to the WCAG 2.0 standards in almost all circumstances. For each of these sections, a count of "passes," "passes exceptions," "fails" and "not applicable" is provided. Creating a digestible table like allows stakeholders especially to see a product's compliance level at a glance, as well as easily showing where improvements are needed.

Our team has developed a six-part service package around VPATs. We have to determine whether the service package is being used purely for business or measure. We scale it to the type of requests, meaning that a smaller product that will retire in a year will just get a VPAT. The VPAT, or WCAG 2.0 document, is the foundation of the service package and the minimum deliverable. Beyond this, we start treading into for measure territory.

If the product isn't going away and will remediate, we provide a fix list ordered by priority. If the product managers want an online presence to show off their accessibility compliance levels, then we create a public-facing page; if stakeholders want a compliance score or a tool to track progress, a product score card. And if we've created a fix list, we spread knowledge by presenting the findings to the team. It provides direction for immediate remediation; and we also hope product managers and developers on the team will take the findings as a learning experience and apply the knowledge to future projects, which can only help in the long run.

Lastly, and only if a customer asks, we will facilitate the remediation form.

We've already mentioned the challenge of high volume and the unpredictability of inquiries. We have said sometimes we can receive requests that can total up to 10 VPATs at a time; and these can appear whenever, which can interfere with other ongoing projects. Having a streamlined process for dealing with inquiries…no matter the size, scale, importance…makes the process much less painful. Once we're contacted about a new inquiry by one of various channels, such as our sales team, we set priority to it in regard to our other ongoing projects. This would be by revenue involved, as well as any other risk factors, such as whether having the VPAT is a deal breaker for the customer. Highest revenue deals typically would get first dibs on VPAT support for us.

With the knowledge gained from that inquiry, we typically track the data in an annual accessibility spreadsheet. It can be kept for future reference and will be useful in demonstrating the business case for accessibility. Once work is scheduled to begin on the project, we establish the appropriate level of service package, determined by the importance of the product and whether the team is looking to remediate. Ongoing communication with the contact point is necessary in this process.

We determine the site's longevity, and we scale our time and effort based on how long we expect the site to be used. For example, our individual book products are small and have new additions every year. We typically would not spend more than a day or two on a VPAT for it. After a VPAT is complete, we deliver it to the team or customer, along with other parts of the service package. If the findings are to be presented to the product team, we take time to ensure that they understand where and why they need to make fixes.

Last, we make sure that the VPAT is discoverable by posting it on our Internet. We at Elsevier have used SharePoint before and have now used Confluence as a VPAT repository. We want people looking for a specific VPAT to know that there is a shared location where they can easily find them without effort.

We'll now move on to some best practices for the actual creation of VPATs.

We came up with an acronym, "DUTCH," for this, which is appropriate since Elsevier is a Dutch company:

First is Detailed…make sure to fill out the Remarks Section as clearly as possible. Customers appreciate thorough explanations of passes and fails, as they'll often want to know exactly which areas of a product do not comply.

Unbiased…utilize a group of central experts or third parties; don't use sales people for this.

Template…if you have a good one, it will save you time and it will make your document presentable. For example, we have a nicer-looking Word template with nicer fonts, colors to denote supports/does not support, and of course making the document itself accessible. We like to make an effort wherever possible to have the document appear more pleasant. If a document is just a bunch of black and white blocks of text, it can be intimidating to those unfamiliar with VPAT.

Contemporary…make sure to update your VPAT annually, especially for the big earning and high visibility products.

And Honest…show examples of where you do and you do not pass a guideline. Clients appreciate knowing all of the accessibility features of a product. There could be concerns if certain checkpoints are passed when a customer finds that it actually doesn't.

Here we can see an example VPAT and the template that we use. It shows where we support, partially support, and fail. And a very similar approach is taken in our WCAG 2.0 compliance documents as well.

We're actually putting together a new format that we're interested in trying out, where each individual WCAG 2.0 checkpoint is its own PowerPoint slide. We hope that this provides a more digestible viewing experience, as well as allows for a more concise tally of checkpoints, supports, and violations. The "Workarounds and User Tips" section can be used to show some of the best ways for users to utilize certain features in accordance with the product.

You can build your company's reputation externally by producing quality VPATs. It's your chance to show customers that you really do care about accessibility, and it saves them time from having to do their own accessibility testing. Internally, quality VPATs will build your team's reputation as a center of excellence.

Here's a quote that we've received before that shows the respect customers can have for a company that produces robust VPATs.

[Pause]

We like to consider VPATs our friends because when done right, they can help facilitate business for the product you're selling. Disability Services offices like VPATs because they are often the only document available that they can use to help determine if an accommodation is needed. If we look back at our service package, one part included a public-facing page that includes information about a site's accessibility features. The product and marketing managers like us because they can host these info sites around accessibility, like this one that's used for ScienceDirect. These marketing pages give a product's accessibility features an online presence and provide an easy way for users to retrieve a VPAT.

Okay, so Jay talked about how quality VPATs can make your marketing team and product team happy. Well, how about making management happy with cost savings?

You can do that through effectively managing your VPATs through a central Accessibility Team, like we do here at Elsevier. To help grow our Accessibility Team, I did an evaluation of five service providers for VPATs and WCAG 2.0 products. The price range was from $2.5K to $11K USD per review. At the time, our intern cost for the VPAT was one-third of the cheapest consultant.

So what I did was I wrote up a proposal for a full-time accessibility specialist to handle our rising volume. And put on paper, with the data to back it, our management saw the clear value in someone doing this work full time over turning it over to the more expensive consultants.

I am going to go over what is new in the VPAT universe. This is kind of pre-conclusion, so there are three main points here.

First of all, VPATs used to be a check-the-box exercise usually. So customers would ask for a VPAT; we'd send the document through sales. Customers would say thank you very much, check the box, and a lot of times we'd never hear back. This has changed. Increasingly, customers now want to know the timeline for when any gaps are going to be fixed; and that particular timeline and plan is requested, communicated through the Conformance and Remediation Form.

We've had about 20% of our VPAT requests last year involved a Remediation Form request too. This has caused a little bit of heartburn for our team because, of course, the Accessibility Team doesn't own any kind of product roadmap. It's way above our paygrade to make any kind of priority decisions. So we do our best to educate product managers about the Remediation Form concept; in fact, I'm currently working on that this week for a product.

Overall, product managers are unfamiliar with the process of remediation forms…never heard of them. And a lot of times, product folks are reluctant to commit to anything on paper with such a dynamic changing roadmap of features. So what we're trying to do is settle into a system where when Jay and I create VPATs, we get the product teams to also help complete the Remediation Form.

There are three big trends on how we will handle VPATs in the future and kind of external things shaping how we do our work.

Number one…this kind of ties into the last slide…there is much more follow-up by customers. VPATs are being scrutinized now more than ever. Campuses are hiring accessibility coordinators and central IT accessibility experts to request and review vendor VPATs. Customers are taking note of the details we've put into the document and asking about workarounds, scheduling calls with our team to help understand accessibility policies; and overall, I think this increase of communication is a good thing.

Number two, 508 is impacting a larger number of industries; and typically for us, it's been the U.S. Government and colleges that have requested VPATs. But now we're seeing requests from health care companies, even local police departments.

Number three…and this goes back to something Jay mentioned before…508 refresh is now on the Federal Register as of January of this year.

So in short, the WCAG 2.0 A and AA checkpoints replace the old 508 Web accessibility checkpoints. So of course, our VPATs will now need to reflect the new standards. According to the U.S. Access Board, the updated 508 law goes into effect March 20th this year; it already happened. But 508 and, thus, WCAG 2.0 AA compliance is not required until January 18, 2018.

I am sorry about clicking the wrong arrow. Here I go forward.

Okay, so another new thing out there is that there is a VPAT 2.0 (Beta) available on the ITI website. I would love to know…feel free to send a Chat or in Q&A we can talk about this…has anybody seen or used the VPAT 2.0 (Beta) document?

Well, this slide just shows the first page of the VPAT 2.0 (Beta)…first page of 32, mind you. So here are a little bit of points about what's different in VPAT 2.0.

Big change is that the ITI is attempting to create a template that works for both U.S. and European IT procurement. I used to think of VPATs as being synonymous with only U.S. standards, but that is not the case with Version 2.0. So for Web and software, VPAT 2.0 includes the legacy year 2000 – legacy VPAT sections 21 through 41; so it keeps the old sections. But it also tacks on the European Accessibility Standard EN301549.

Also, VPAT 2.0 tacks on Sections A, AA, and AAA of WCAG 2.0. So the bad thing functionally speaking if you're going to use the document is there's lots of repetition between the sections. For example, there are several checkpoints about keyboard operability. And again, it's a long document. Without any data entered, it's 32 pages long compared to the 18-page Version 1.

My first impression in seeing the document was, "Hey, why the heck are we reusing the old 508 criteria for Web?" That didn't make sense to me, especially with the 508 refresh happening. And, wow, there's going to be a lot of table surgery going on if we're going to actually use this template and fill them out.

So I would encourage everyone to review the VPAT 2.0. There's a link at the end of the slides. Earlier this year, the ITI had a survey and wanted to gauge reactions of the public on the new document. I would say go fill it out, but I think they've since taken it down.

To conclude everything off here, VPATs are very useful as a measure of 508 compliance:

Of course, it keeps you from having to answer the "Yes," "No," or "Maybe" to customers' inquiries of whether a product is 508-compliant. We can just directly provide the VPAT.

Having a managed process for dealing with VPATs can help grow your Accessibility Team. You've determined whether the VPAT is being used for business or measure and created a service package that adheres to the VPAT request.

By expanding a VPAT into more than just a list of violations, the team can be trusted, have more impact, and develop into a larger team. It spreads accessibility knowledge to managers and developers, which can benefit future projects and make the compliance process much easier.

We recommend tracking all inquiry data in an annual spreadsheet. It serves as a product inventory of completed projects and shows how money is at stake for each individual inquiry…which goes a long way in demonstrating the business case for accessibility. Customer data has been showing more and more each year how important accessibility is becoming. It's less important than it was before, but it's still sometimes quite necessary to do.

Last, VPATs are very useful for sustaining business, as developing frequent and quality VPATs builds a reputation and keeps customers coming back.

These slides all will be available online. Some of the resources that we brought up in this talk, such as the ScienceDirect Accessibility Page, will be available here.

Q&A

Now, I guess, we'll open it up to some Q&A and discussion.

Thank you, guys. Did we want to start with the poll we had thrown out there? We have a lot of good questions.

Josh, how would you like to do that? Would you like to feed those to us, or would you like us to (multiple voices)?

I'd love to get the people's questions involved that asked them if we can go through those first. If we have some time, we can go through with the poll and other questions. I'm sorry if you've covered some of these; I'm just going to run through them.

We had people asking about the levels of WCAG level you're following…A, AA, AAA…and does Elsevier have an agreement with third-party partners on accessibility?

We evaluate our WCAG level to AA for all of the products that we review. Every once in a while, we've had internal requests just asking for single A. But by the time that we present any external documents on it, it's always to level AA.

And the second part of that question was around supplier agreements…was that right, Josh?

Yeah, they asked if there were third-party partners (inaudible).

I didn't catch the last part of that…around what?

It just says: Does Elsevier have an agreement with third-party partners on accessibility?

Right, so we will, when partnering with a new supplier…and that could be an engineering provider. Maybe they're helping us develop some software or a Web application, or they're providing a new plug-in or content. We have begun to put in supplier screening questions around their commitment to accessibility. Typically, what we do is ask them if what they're producing complies with WCAG 2.0 AA standards. So it's becoming more formal, and that is kind of a parallel effort to the ongoing compliance review work that we do for our own internal development.

Great, thank you. One question was really about when you create the VPAT and curious as to why wait for a request for one as opposed to just creating them as a part of the service release process.

Okay, that's a great question. It depends on the product. For the strategic sites…and I'll define those as sites that are typically big revenue generators, they are primary platforms, new platforms…we do produce VPATs as part of the deliverables after it's released. The problem is we've got a lot of legacy sites out there; I would say hundreds of products; and we just don't have the bandwidth to do reviews for all those hundreds of sites.

Thank you. Next one we have is really around the training of your interns. What is their background, and how long are they with you…so just asking about your intern program?

So I got hired as an intern almost three years ago. My intern process before I became full-time was about 14 months. I had some previous experience. I worked at a consulting sort of agency affiliated with Michigan State University. So I had around almost two years of accessibility and usability experience. So I didn't need much training when I came in. Typically…and Ted might be able to answer this further…if we are able to expand our team again whether we would mainly just try and target somebody that already had experience with this kind of thing.

Is that something that we would probably do?

You know, I'll just say this. Back when we were looking to expand the team, I put a job ad out there for someone with accessibility testing and standards and technical experience. And I tell you, I got 20 resumes for brilliant computer scientists…people who can do things with programming and kind of database-driven technologies. But the skillset of an accessibility specialist…very rare. We hardly got any people putting their name in for that that were really qualified. So that's just an interesting aside.

But, yeah, I think expanding our team, we would definitely want to see experience with the standards, with the assistive technology, understanding of the personas with disabilities. Those are great skills to have to help become an accessibility specialist. And even now that there are certifications out there, like IAAP and 508 Trusted Tester, those are solid things you can find on people's resumes now.

Great, thank you. Another question here: How does Elsevier test and verify their VPAT claims?

We have a pretty large multitude of experience doing some things, and several of our products have been accessibility user tested as well. So in addition to our expertise, instead of just doing the VPAT, we can work very closely with the teams themselves in the remediation process and then supplement those VPAT claims with some accessibility user testing, especially with the more high higher products.

Is there anything else?

Yeah, I'll just mention that we have a Swiss army knife of tools that we employ to verify claims. So we do have years of experience in the field. But in terms of testing and verifying, we might use free website checkers, such as the AInspector Sidebar or the Chrome tool for WAVE. But then we'll also fire up assistive technology, such as JAWS or NVVA…definitely test every single interactive element with keyboard. And we're starting to do more and more voice input testing.

So really, we've got a pretty wide set of testing tools that we apply for each of our websites; and all of those tools are meant to inform on the pass, partial pass, or fail that we assign each WCAG checkpoint.

Great, a question about the test to see whether other programs, like JAWS, are able to navigate through; and I heard you just said that is part of your process, yes?

Another question that came up is really related to the discussion slide we have up there. The fourth bullet is kind of what prompted the question. But they were curious about aren't there independent auditing companies that complete the VPAT. They do these along with letters of conformance for clients because a VPAT is required for their RFP/RFQ process; but it's not the same as an audit or conformance letter.

There are independent auditing companies that produce that. The ones that I have investigated are typically quite expensive. I'm not saying not to use them; but the quality of reports that I have seen from the independent auditors, there's really -- for us, I think there's a lot of top savings involved and that's why we manage our own internally.

And you might say, well, you know, you hire an external auditor and they're going to be completely unbiased because they have no real tie to the company…which is a valid point. But I think that was one of Jay's points on his DUTCH acronym for best practices. We try to be as unbiased as possible when we do our reviews. It's not like we want the company to fail, but we don't want to misrepresent any accessibility checkpoint. That doesn't do any good for the product buyer, and it doesn't do any good for our company because we don't want our product management and engineers to go around thinking we're great on accessibility when actually work needs to be done.

Great, thank you.

I'm going to encourage people to definitely check out the Chat. People are sharing info and resources, so you can look at stuff there. But with the time remaining, I wanted to switch over to the discussion questions we have.

We have one here that may be of interest I'll grab. It says: "What's your perspective on the standardization of VPAT? And are all VPATs not created equal?"

You talked a little bit earlier about the checkmarks, but if you could kind of reiterate your perspective on the standardization of them.

Well, I tell you what; I have seen a great variance in the different kinds of – if you download a VPAT from the ITI website, it's going to look the same as – at least the legacy one – is going to look the same as the one you get from the Social Security Administration. It's going to look the same as you'd probably find from the U.S. Access Board. It's really the same table. The directions and stuff in the beginning…the front matter might be different; but really, word for word they look the same.

So I think the formatting and stuff, to me, is just…there are no rules in terms of, hey, it needs to be laid out this way or that way. I think as long as the standard set is being accurately reflected in your conformance details, I think that's, in a way, the only standardization that needs to happen in my opinion.

As an example, VPATs now, they should be reflecting, at least for Web applications with the 508 refresh, they should be reflecting WCAG 2.0 A and AA checkpoints…the new Web accessibility standards for 508. My feelings are that as long as you are dealing with a Web application, as long as you fill out where you pass and do not pass for each of those 38 checkpoints in describing supporting remarks, where you do and do not pass, you're good. That's my feeling on it.

Thanks, we've got time for another couple of questions if you people want to try and put them in. I'm going to go to the discussion on the board here and maybe combine those two bullets. The first two, we talk about we were curious how firms deal with remediation forms. But then also there's a question connected to it around how you could maybe educate others, especially project managers, to help in the completion of those forms.

Perfect, Josh, I just wanted to check as well. Were you wanting to do a poll at all during this webinar?

Sure, maybe we can go to that one. Why don't we go to that now…pull it up? Folks, you get ready to poll with Adobe and interact there. It's up just now, so hope you can view it. It says: Which team in your company completes VPATs? The question is: Which team in your company completes VPATs?

There are answers there, buttons you can choose. People are punching them in now. The first is user experience team; second is accessibility team; third is the engineering team; fourth is quality assurance; fifth is product management; sixth is sales; then there's marketing, third-party companies, or we have the "other" button. Finally, there's a "No one, we don't do VPAT."

So click the buttons. You can also just chime in if it's easier using the Chat window; you can put your answer in there.

Which team in your company completes VPATs?

User experience, accessibility, engineering, QA, product management, sales, marketing, a third-party company, other, or no one…we don't use VPAT.

So we'll give it another second. Again, use the Chat window if that's easier or better for you.

Why don't we go ahead and close it up, and we'll see what we've got here for discussion. You can see the voting there. Unfortunately, but not surprising, we have the largest amount of answers down there at the bottom…that we don't do VPAT. Unfortunately all too common – otherwise, third-party companies rate highly and the rest are kind of a smattering. I'll open that up for Ted and Jay If you want to have a discussion regarding the poll or if you have any comments on there.

Okay, I'll comment on it. First of all, I'm glad people were able to participate in that. On one hand, I'm happy that the highest amount…50% of folks say that nobody does VPATs. I'm happy in that hopefully they've learned something practical during this webinar, and it will encourage them to start doing VPATs because there are several good things for your users and for your business if you do have a good VPAT. So that makes me happy.

On the other hand, yeah, I think if you're producing digital content or software, you really should take the pulse on where you are for accessibility. I think the VPAT is the perfect vehicle to do that. So I would encourage those folks to create one, yeah.

The other votes were not that surprising to me. I saw a long tail of accessibility team and UX. Didn't see anybody from sales doing it; but I'm pretty sure that the sales people are too busy to attend this webinar, so they're maybe not represented.

Josh, you had mentioned the other question about educating the company. There are some things going on at Elsevier right now to help educate our company, and our team does work with a variety of roles. We're talking about engineering, product management, marketing, sales, legal, corporate responsibility, QA. We don't really work with the financial folks, but…no, no we do. The parent company does an audit on the accessibility work. So it's just pretty amazing how far our collaborative reach goes internally.

To educate the company, there are a couple of things we've been doing. Ever since 2008, we've been providing educational webinars that anyone in Elsevier can sign up to attend. Those invitations are even extended to our parent company relics. So we've done those, and we just this year created what's called an accessibility guild. This is a concept that came out of the company Spotify, and it's a way to develop a center of expertise without having to create organizational structures in your company to necessarily support the guild.

So you could create a guild around accessibility. You could create it around quality assurance, search technology, machine learning…whatever topic is important to your business. But you don't want to rearrange your organizational structure to reflect that. So the guild has over 80 members from across Elsevier enrolled in businesses. Jay and I have presented monthly webinars on how to understand and test for the Web content accessibility guidelines too.

So we got through all 38 checkpoints in about five sessions; and we've recorded those and posted them on a central site so people can learn from them, replay them. We've even had one of our departments make it a mandatory program to go through and review all those webinars, so that's a good thing.

Right now, we're actually developing a couple more things…like a game, where we kind of crowd source accessibility testing on an example website. Actually, this is going to be one of our CSUN 2018 topics…a game to test for accessibility compliance.

There's also like a karate/judo belting system, where we're trying to formalize exactly what it means for a staff to achieve a certain level of knowledge and capability with accessibility. So it's not like you can just show up one day and say, oh, well, I'm a black belt in accessibility specialist. This is kind of like our own sets of ladders for how to progress in the field. So that is something that is in the works and will probably be rolled out formally next year.

Awesome, we have time for one more question. Why don't we go to the concept of kind of like how are teams…or are they already transitioning from the 508 checkpoints to WCAG 2.0? I'm not sure if you addressed that fully in the presentation. But from Elsevier's perspective, how is that manifesting itself?

That's a great question. It's one of those things where I think the switchover should be happening now. Essentially, you've changed the instrument or your scorecard, if you will; you've changed the standard. So 508 Web compliance for Web applications used to mean the old 2000 legacy requirements. They're different now; they're aligned with WCAG 2.0 level AA. So it's not forward thinking anymore; it's contemporary.

I have seen customers...in higher ed, policies are already in place that are asking for WCAG 2.0 AA compliance. So that has become more prevalent. We still get asked for 508 compliance or VPATs without necessarily saying, yes, we need your documents to be WCAG 2.0 and not the old legacy ones. So I think it's just going to be a routine part of campus and Federal Government purchase policies, where they're going to say, yeah, here's the VPAT but make sure you use the newest version or make sure you use WCAG 2.0; don't use the old version.

So, yeah, we've been doing that now…I don't know, Jay, formally we've kind of switched over since…?

March.

Yeah, beginning of the year.

That's great, super.

Conclusion

Well, I want to thank people for their participation and questions as others are doing in the Chat now too. I encourage you to peruse through the Chat. People have been sharing information and asking questions there, which is great.

In conclusion and to wrap up today, I want to do a quick plug before I thank folks. Next PEAT Talks is Thursday, October 19th, 2:00 p.m. Eastern. We'll be featuring Mark Penicook, who is a Senior Manager of Accessibility at Capital One. He's going to discuss how Capital One has worked to integrate accessibility awareness across their internal brand…so within the company…and to establish kind of an enterprise-wide accessibility standards and best practices. So we encourage you all to join us there, ask questions, bring resources, and learn how a large entity has been really ramping up their accessibility knowledge across the board.

Otherwise, again, I really want to thank Ted and Jay for the conversation, for the insight in sharing Elsevier's journey, and your own individual work. It's much appreciated.

Thank everybody for participating in questions and comments. We look forward to more discussions about VPATs and procurements. It's important as related to making sure we get accessible products into the workplace. Thank you both so much.

Have a great rest of the afternoon.

Thank you, Josh. Thank you, Corinne.

Thank you. All right, take care.