Thank you for coming and bearing with us.
Today is our webinar on how to read a VPAT.
You can go to the URL pz.tt/VPAT, then you get this page here.
You can follow along here. This is not screen reader accessible,
which is something I'm talking to the developers about. This not our product.
There is a PowerPoint you can access here that is fully accessible,
and you can download that. Here are some general links as well.
Sam will put in the chat this page here, so you can follow along with the captions that way as well.
If you'd like to tweet along, our Twitter handle is @accessibilityoz.
If you've been to presentations by me, you will have seen this slide a few times.
This is about about 2/3 of my team. We all met at CSUN. We're a distributed workforce.
We have staff on 3 continents. We get together once a year. We did at CSUN this year.
When I started AccessibilityOz in 2011,
I wanted to support people with disabilities by providing them with employment.
I wanted to make sure that 20% of my staff had some kind of disability,
so that meant we actively hire people with disabilities.
At the moment, 60% of my staff have some kind of major disability.
I've had staff with disabilities including [Reading list of disabilities on slide.]
It's important to remember that it's not just about screen readers
people with visual impairments; it's about people with varying disabilities.
We basically do everything to do with accessibility. [Reading list of services on slide.]
I'm actually chair of a number of committees working on
mobile site and native app testing guidelines.
If you're interested in that, have a look at the Presentations page on our website.
There is a webinar we did a month ago on mobile accessibility. If you happen to be in the San Francisco area
I'm running training on mobile site and native app testing on Friday at Stanford University.
Let me know if you're interested in joining us.
In terms of our products, we have 3 paid products:
OzART, our automated testing tool,
OzWiki, our database of accessibility errors, screen-shots, codes and solutions
and OzPlayer, our accessible video player
We also have 3 free products:
Factsheets, on our website, about how to make categories of content accessible,
Accessibility Voices, a blog of posts by people with disabilities about their accessibility experiences
and CCC videos, a series of 16 videos aimed at developers, on how to make error messages accessible, etc.
About me: I started in accessibility in '98. I spent 6 years with W3C,
contributing to WCAG2. I also spent 6 years at Monash University
I founded AccessibilityOz in 2011, and
I spoke at the UN on the importance of web accessibility in 2015.
Let's talk about VPATs. What is it?
It's an explanation of the accessibility compliance of a product.
It's an overview of the areas exist in that product.
It's owned and often accessed by the product vendor,
so it's not always created by a 3rd party.
It's a little bit like accessibility itself in that it's self-assessed.
It's required by Section 508 and almost all federal solicitations.
You do need to do an accessibility audit of the product to fill out a VPAT,
but a VPAT will not contain every single error. It talks about the errors in general.
But it's important to note that
you can't do a VPAT without conducting an audit.
It's not only for government.
You'll find that higher education institutions, corporations, etc.
all ask for VPATs because they are often useful
in assessing the accessibility compliance of a product.
VPATs are also for things like smart phones, photocopiers, etc.
They are not always accurate. I wish they were,
but that's not always the case.
There are various reasons for this I'll discuss later.
Don't think that just because a VPAT says something is fully accessible that it actually is.
It's not a good indicator of ATAG compliance.
ATAG is the Authoring Tool Accessibility Guidelines.
It basically says if you're providing a system to create content
then the content created must be accessible.
We saw this in a video player VPAT.
Yet, when it comes to the captions, it says they are not offered.
That's true: the video player itself does not offer captions,
but offers the ability for a user to create captions.
If they say they support the captions, and the creation of captions,
they'd have to say they don't support audio descriptions.
Which would have meant their VPAT would look worse.
Some VPAT categories include [Reading list.]
If you're sourcing any of these items, they should have VPATs.
The sections of a VPAT include [Reading sections on slides.]
I'll talk about which of those things you should focus on.
They can be overwhelming when you first see a VPAT,
but you only need to narrow in on a few sections to determine accuracy.
There are a bunch of red flags for VPATs.
If you see one with these things, you should question the accuracy of the VPAT.
Cells without content. Even if something isn't applicable,
such as captions if it doesn't have any video content,
there should always be some text saying why it's not applicable.
Any empty cells in the WCAG2 section are problematic.
Using terminology such as pass/fail or yes/no is not a good idea,
because there is conventional terminology used throughout VPATs
about support, supports with exceptions, partially supports, etc.
If you see pass/fail or yes/no, that indicates that
the person filling it out doesn't know much about accessibility.
If there are a lot of Not Applicables, that's a red flag.
Especially if it's something like "captions are not applicable,"
but you know there is video content on the site.
Absolutely everything marked as "supports."
Yes, there are some products that are fully accessible,
and everything will be "supports." But more often than not,
if absolutely everything is marked "supports," that usually means someone just copy and pasted.
Often VPATs are written by the marketing team,
people who don't necessarily understand accessibility.
There is an asterisk referring to what you should question on the VPAT.
It could be OK, but in most cases it isn't.
Another red flag is one VPAT for multiple products.
You should have one VPAT per product,
and it's a problem to mix products together in one VPAT.
Another red flag is an inaccurate or unclear description of the product.
If the description of the product doesn't include all the features,
that's an indication that the VPAT is not sufficient.
Often, it'll say "we've tested an absolutely vanilla output
with no image galleries, slide shows, or videos, and yes, the VPAT says 'supports.'"
But in reality, if you used any of those features, it'd immediately be inaccessible.
The notes section is an opportunity for the vendor to say that certain things are not covered.
Look at the notes section to see if it explicitly says that essential features aren't covered.
Again, if it says they didn't test the slide show,
or did not include the publication section, for example,
it's often because it's not accessible.
Another red flag is if it's not dated or dated over 12 months.
This isn't an absolute failure, especially for complex products,
but it's reason to question.
The VPAT should be updated whenever a product is updated.
If a product hasn't changed in 12 months, then it's fine if the VPAT is the same,
but how many products are not changed in 12 month?
That's a question you need to ask the vendor.
[Reading slide.]
We all know that only 30% of accessibility errors can be identified through automated testing.
It's a problem if only automated testing is mentioned.
I'd also be wary if there's no mention of testing with assistive technologies.
It's sufficient to test with automated and manual testing,
but if there's no assistive technology testing, that's something that's worth questioning.
Look for contact information to see if you can contact that person.
If that goes to an empty mailbox, or person who no longer works there
that's a red flag that the VPAT isn't up-to-date.
There's also an option to say "not evaluated,"
Any VPAT that has not evaluated in level A or AA is problematic.
You can definitely say "not evaluated in AAA,"
but "not evaluated" is usually code for "it's not accessible,
but we don't want to tell people that."
The best thing you can do is question.
A red flag doesn't mean that it's absolutely incorrect or inaccurate,
but it means you should talk to the vendor to find out what's going on.
For example, if it's 14 months old, say "has the product not been updated in 14 months?"
They may have a good answer. They may say that it's updated daily
and they do an accessibility audit every 16 months
and are in the middle of doing an audit now,
and they'll have the VPAT to you in a month.
The best thing to determine how accurate a VPAT is
is to see how people respond to questions. If they have very vague answers,
or they don't answer at all, that's an indication that the VPAT isn't accurate.
You can ask why they say a section isn't applicable when the product has that feature.
They could have a good answer, like that they wrote the VPAT 6 months ago,
the product didn't have video capabilities, but it does now,
and they are updating the VPAT and it will be in the next version.
Even if Evaluation Methods is filled out, ask what kind of testing they did to ensure compliance,
and see if they give you the same answer as in the Evaluation Methods section.
Another thing to ask at that point, when they give you an answer, is why.
If they say, "We ran it through WAVE and we tested with JAWS," ask why they did that.
They should say that the system is comprehensive, WAVE will pick up warnings and errors,
and they wanted to make sure that it's accessible to a screen reader, and JAWS is the most common.
If they say, "Well, that's what we use," it's a red flag.
There's an option under Evaluation Methods that says "Based on general product knowledge."
A lot of vendors will use that terminology, and that's also a red flag.
It's true -- we have some products, OzART and OzPlayer, etc.
that I could fill out based on my general knowledge of the product;
however, I would still, and I have still, conduct testing of those products
and put that in the evaluation section, even though we've built the products in certain ways.
So, just having the general product knowledge is a red flag.
Another good question is to ask is why they filled out the VPAT internally.
You want to hear that they have an internal accessibility team.
If you find that marketing filled it out, or they don't have any accessibility people,
it's a red flag. As I've said, in order to fill out a VPAT, you need to do an audit.
They either haven't done an audit or those who conducted the audit don't know much about accessibility.
I got an email from someone I hadn't spoken for five or ten years,
saying "I remember you from a previous job. We've got this website.
Can you tell me how to test it for WCAG2 compliance?"
But it's a lot of work to do that. You can't answer that in a one-paragraph email.
Accessibility specialists are skilled and spend their lives learning about it.
It's not something that you would accept for security, or privacy.
You wouldn't give that to your admin assistant to figure out,
but people seem to think you can do that with accessibility.
You certainly wouldn't give it to marketing.
Another question is "why the description omit essential features of the product?"
There might be a good answer, but often, you'll get some kind of obfuscation.
So be careful of VPATs that miss essential features.
Another question is about testing with JAWS or NVDA.
It's worth asking "why you decided to test with only one screen reader?"
Or even, "why did you decide to test with screen readers and not switch, etc."
Again, it's a question to see how they answer.
If they say something like "JAWS is the only screen reader out there,"
you know they don't know what they are talking about.
If they say "We did a survey and 90% of our screen reader users use JAWS,"
that's an excellent answer, and shows that they've thought about it.
That was a bad VPAT. [On screen.]
A good VPAT has these features. [On screen.]
I've also seen "supports with exceptions," and that's fine.
It should stand up to questioning.
The questions aren't necessarily to get this fantastic answer,
but to see how they respond to questions, and if they can validate decisions behind the VPAT.
A good VPAT is often written by someone other than the product vendor.
Now, that's not always the case. Adobe, Microsoft, etc.
They have great accessibility teams, and they write their VPATs in-house.
And they have fantastic VPATs.
But for a small firm that doesn't have any accessibility people,
it shouldn't be written in-house. The product needs to have undergone an audit.
There's an article by Karl Groves about
why you should have a 3rd party write your VPAT. I've added that link.
The product description should be clear. The name only is insufficient.
It needs to include all associated features, especially essential features.
Some VPATs I'm seeing now that say, "This path through the site is what we tested."
That's not testing the compliance of the product; it's testing one path.
Make sure that you're happy with that.
It should refer to existing accessibility testing tools,
unless it's like a two-page web application,
there needs to be some level of automated testing.
There are sections worth looking at.
The place to start is the WCAG2 section. You're probably familiar with WCAG2
and all the success criteria. Each of the different VPATs,
there's one for Section 508, one for EN 301 549, one for WCAG2,
all have WCAG2 within them. If you know that there's accessibility issues with the product,
for example, if you know there's a section that's not keyboard-accessible, is that in the VPAT?
Products aren't always fully accessibility. That doesn't mean it's a terrible product,
but that needs to be in the VPAT. So if you know about accessibility issues,
look for them in the VPAT. If you don't, Google it.
Write the product name and "accessibility issues" or "accessibility,"
and you'll have an idea of its accessibility compliance. Do be careful,
they might be talking about older products, but it's a good place to start.
[Reading slide.]
Read through the evaluation methods. Do they include automated testing tools?
Do they include manual testing? One line or a few words is not sufficient for Evaluation Methods.
[Reading slide.]
There are four noninterference clauses in WCAG2:
Flickering; movement that can't be stopped;
audio that can't be stopped; and keyboard traps.
If the product has any of those, that's a real problem.
These are issues that will either hurt someone or completely block someone's access to the product.
It shouldn't fail any of the non-interference clauses.
But read through the exceptions. If it says, "the navigation is not accessible,"
Think "Hold on, that's a real problem."
The best thing to start with is keyboard 2.1.1. Tab through things.
Press enter to activate. Use the arrow keys.
Can you use the navigation? Can you submit a search?
Can you use the more complicated elements, like an image gallery or slide show?
What a lot of people miss with keyboard testing is when the keyboard disappears.
If you tab to a link, and then you have to tab 3 times to get to the next link,
you're tabbing through content that can't be seen. That's a real problem.
Test, then look at the exceptions to see if they accord.
If it says "support" and there's something like a date-picker, etc.
that's not accessible to the keyboard, there's a problem with the VPAT.
This is one of the noninterference clauses in WCAG2. This is an easy one.
[Reading slide.]
If there's movement in the site, and it says "not applicable," that's a problem.
If there's movement in the site and it says "supports,"
can you pause the feature using the mouse, keyboard, or touch?
Or it needs to stop within 5 seconds.
If that's not the case, then it does not support.
That's an indication that the VPAT's not accurate.
Be wary of "supports with exceptions" when they say all but this one thing,
but there is only one of that thing. For example, if for Pause Stop Hide
it says "supports with exceptions," because you can't pause the slide show on the homepage,
when the only thing that moves is that slide show.
That's an indication that that should be "does not support."
Another good one to test is skip links. [Reading slide.]
In most cases, skip links should be visible at all times,
but WCAG2 does not require that the skip link is visible at all times.
but it needs to be visible when you tab to it. It needs to be
the first thing that appears when you tab into a site. That's easy to test.
Go to the search page, go to random pages, and see if they're everywhere,
and not just on the content pages.
[Reading slide.]
There are 2 requirements in WCAG2 in Level A and AA:
1. Error descriptions, and 2. Error Suggestions.
All errors must have a descriptions and a suggestion. For example,
if you left First Name blank, a good error would be:
"Please enter your first name, for example 'John.'"
You're giving a description of the error, and also a suggestion.
That's all I had to say. I thought there would be lots of questions and made the meeting short.
I'll open it to questions.
I'm going to open the chat.
Yes, we can send a link to the PowerPoint slides.
Any questions - please put them in the chat.
Yes. There is a standard VPAT form. I'll show you where it is. It's linked on the Prezentt file.
If you go to this: How to read a VPAT. The "VPAT - General Services Administration,"
that gives you all the information about the VPATs, resources, etc.
The current VPAT templates are here.
If you go to "Download the current VPAT template,"
it talks about the VPATs, and the actual templates are under Resources.
I can't seem to see the chat.
There we go. Any other questions?
This is a good question. If they came up with a different form, it's not a VPAT.
I'm running on webinar in a month on how to access the accessibility compliance of a product.
I would suggest you attend that. I'll be talking about how to test the accessibility of products.
"Do I use the 508 or WCAG version of the VPAT?" I use the WCAG version.
But if you're dealing with federal government, you must use 508 version.
But Section 508 also includes WCAG2 in it, but there are functional specs that are a little different.
"How long has the VPAT been a standard?" Version 2 was released last year.
It's been around for 9 or 10 years. Someone on the call may know that better than me.
I've only been working in the U.S. industry for about 5 years. It was around when I started.
Good question: VPATs and GPATs. GPATs aren't really a thing anymore.
They are more aimed at government.
Even though VPATs are for government as well, there's a real
expectation that VPATs will be everything. They're kind of the same.
Jacqueline Turner says "I get a lot of pushback from vendors
when I inform them that their product does not conform to 508,
even when I map them to the standards. How do you handle that situation?"
I'll tell this story in my next webinar. This happens all the time.
Whether there's a VPAT or there's not, there's kind of a standard response by vendors.
The first response is often: "We are fully accessible.
Here's a checklist where we've checked everything as accessible."
You then point out that it's not accessible.
Then they say, "No, we don't actually need to be accessible,
because we are exempt for some reason."
The next response is: "You're the first people ever to mention accessibility to us,
You're the only person who wants to do it,
so you have to pay if you want it to be accessible."
The last response tends to be: "We understand it's not accessible.
We'll do some things to try and address that."
Yes, It really is a problem.
Jennifer Horan says: "A GPAT is the Government Product Accessibility Template,
and you can ask for a GPAT in your solicitation as a deliverable."
Carlos Andrews says: "VPAT has been a standard since 2001."
Jennifer says: "It is hard to ask for a Voluntary Accessibility Template
as a deliverable, because it isn't an option or voluntary when you are asking for it as a deliverable."
Yes. There really aren't voluntary, especially if you're government.
Terry Carter asks: "How are there so many companies - particularly in the EU
(which as far as I know is the leader on legal requirements for accessibility) -
still getting by without having a VPAT and creating inaccessible products?"
I could talk about this for hours. We operate in three continents:
Europe, Australia and the U.S. The way people handled accessibility
is very different depending on which continent you're in.
By far, the best continent, in terms of accessibility compliance,
is the U.S. That has to do, not with government requirements or anything like that;
it has to do with the litigation that occurs in the U.S.
If there's an inaccessible product, you can get sued,
and you can get sued for a lot of money.
Target didn't have an accessible website, and
they settled out of court for $6.5 million. Now, Koles, in Australia,
also settled out of court for a similar lawsuit,
and no one knows what they settled for, but it was maybe $100,000.
That's a real incentive for people to address accessibility.
That litigation occurs in the U.S. It occurs a little in Australia.
It doesn't appear to occur in Europe. That's why
there's less incentive for people to deal with accessibility.
John Williams asks: "A vendor I’m currently working with has a product that virtualizes other software.
The vendor claims that they are only responsible for their own product
and not the accessibility of the software their product virtualizes.
I assume that they are responsible for all parts, but what is your opinion?"
That's a good question. Are you able to give me an example of what it virtualizes?
Then, I can probably comment better.
While you are doing that, there is a question about
how to evaluate the cognitive function of FPC on the VPAT.
I will need to get back to you on that. What do you mean by "FPC"?
Carlos - that's a good link, a good website for vendors willing to sell
software or web applications to the U.S. federal government.
I'll put that link in the Prezentt file as well.
So, MySQL being a product that is virtualized -- that's a hard one.
I can definitely imagine that they will say, "It's not our product.
We aren't responsible for it." But in reality,
that's what they're selling you: access to this product.
I would go to them and say, "Whether you own this product or not,
you're responsible for virtualizing it in a way that is accessible."
The VPAT Prezentt file is a good example. If you look at this file,
this feature here, where you open the file and move between slides,
it's a PDF. We all know that PDFs can have accessibility features,
but when you show this PDF, it strips it of the accessibility features within the PDF.
It strips the ALT attributes, the titles, headings, etc.
I don't want to pick on Prezentt, but I will. They can say,
"That's a PDF; we're not responsible for it."
But because of the way they've built it, they've stripped out the accessibility features.
I'd say that they are responsible for at least using the accessibility,
or pushing on the accessibility features within the virtualization.
Hopefully, that answers your question.
What I would say to a vendor like that is, "While you may not be responsible,
but you should at least be talking to the products you're virtualizing
about their accessibility compliance, and you should be handing that information on."
It shouldn't be up to you to chase MySQL, etc. for their accessibility compliance.
If at that point they say, "Well, MySQL does have some accessibility features, but we've stripped them out,"
Then you can say, "Well, that's a problem."
Functional performance criteria:
I'll have to come back to that. I've not looked at it recently.
Look at the WCAG2 stuff. There is a lot of focus on vision impairment.
That's a problem with VPAT, that there's often a focus on vision impairments.
There are some great cognitive criteria in WCAG2.1.
I'll look and send a response out when we send the slides.
John said that another challenge is that several of those tools are open source.
This is definitely a problem. Having said that,
you may be aware of WordPress. The file has links to all the WordPress VPATs.
They created Gutenberg, an editor. They did an accessibility audit of it
and found some major problems. So, just because it's open source,
that doesn't mean that there isn't someone, somewhere, that's responsible for doing some build.
I think it's important that those things are accessible. Well, I think everything should be accessible,
but I think open source is especially important to be accessible.
Any other questions?
Please tune into next month's webinar on how to determine if a product is accessible.
You can sign up by going to the blog on our website.
There was a link. There is no link. There will be in half an hour to that webinar.
We'll send it out with the links as well.
There is a link! Under the title. Thanks, Sam.
We're running it twice, once on September 3rd and 4th [On screen.]
That's to cover Eastern and Pacific time. So please do register,
and send it out.
Also, if you are interested in the mobile workshop, or know anyone who is,
you can get a 50% discount by using FRIENDSOFOZ discount code.
Another question: "Is there a way to automated VPAT evaluation
to assist contracting people who don't know anything about Section 508?"
Big companies like Microsoft automate their VPAT evaluation.
There is a straightforward way to automate
taking your WCAG2 audit results and putting them into the VPAT.
But really, a VPAT evaluation requires --
I see what you mean. Sorry. I thought you were talking about writing the VPAT,
but you're talking about reviewing the VPAT.
No, there's not really an automated way of evaluating the accuracy of a VPAT.
I would suggest you send them this webinar, and they can look for red flags.
Thank you, everyone. Hopefully, I'll see you in one month.
[End of webinar.]