Whether you’re in the procurement process, remediating your product, or building one for someone else, the VPAT is an extremely effective tool for you to have in your back pocket. But how is it produced and how do I fill it out in a way that makes sense for me when it covers such a broad landscape? Let’s dive in!
Step 1: Fill out your cover page
Arguably the most important part of the VPAT is the first page you see when opening the document, the Product Information page. Although it seems simple, from a purchaser’s perspective this page is the first place they’ll look to make sure they’re viewing the report for the exact product they’re interested in procuring. They also look at the date to make sure isn’t outdated. Since we’re all about user-centered-design here at Taoti, we tend to believe that the Evaluation Methods Used field is easily the most important – if this document was generated using testing methods that don’t correspond to how your userbase actually interacts with the site (i.e., audited using NVDA instead of JAWS screen reader tool), then the data on the proceeding pages is essentially worthless for your procurement efforts as it won’t tell the story you need it to tell. This section also gives a clear way for the recipient to reach out to you should they have any questions.
Step 2: Choose your reporting standard
In the current VPAT template iteration, you have 4 different methods to choose from for evaluation of your product:
- Section 508: Revised Section 508 standards – the U.S. Federal accessibility standard
- Europe & Australia: EN 301 549 – the European Union’s “Accessibility requirements suitable for public procurement of ICT products and services in Europe”
- WCAG: WCAG 2.1 or ISO/IEC 40500 – W3C/WAI’s recently updated Web Content Accessibility Guidelines
- International: Incorporate all three of the above standards¹
Step 3: Get comfortable with conformance level criteria
When filling out your report, you have 5 possible grades (rating values) that you can assess the product against:
- Supports: the product has at least one way to cater to the success criteria – all good!
- Partially Supports: Although it’s close, it’s not quite there yet and the product might have a workaround but needs to be adjusted to be conformant to the specific criteria being reviewed
- Does Not Support: Basic functionality doesn’t provide any reasonable way to account for the criteria and needs work to get the basics out of the way.
- Not Applicable: Doesn’t apply to the product you’re looking at
- Not Evaluated: This is only applicable when auditing for WCAG AAA criteria (2.0, 2.1, etc.). If you or a 3rd party hasn’t reviewed the functionality for AAA compliance, this value can be used.
Step 4: Focus on a representative sample set for review
In the case of a website, it’s unreasonable to assume that this report will be comprehensive of every single page on the site. That said, you do have a responsibility to review at least a sample set of pages of the site that will give an accurate representation of your site from the most basic, to most complex pages. Are there specific integrations you should take into account? A specific web form used only on a hidden page of your site? You’ll need to with your client and development teams to help identify the nooks and crannies of your site so you have a documented approach on where you’re auditing, otherwise this effort will spiral in scope rapidly.
Step 5: Select your tools of choice
Circling back to the evaluation tools guidance from step 1, this is where you’ll need to review your arsenal of tools/browser extensions/software and figure out how you want to complete the report. We generally go with a mix of manual testing, automated testing, and assistive technology review.
- Manual: your keyboard is your best friend and the first line of defense your site has against someone claiming your site isn’t in compliance. Start tabbing, make sure enter & space bar are completing actions on active elements that make sense, do the arrow keys function in a way that makes sense for the component you’re focused on, is there a focus state, etc.
- Automated: there’s a golden rule that automated testing (browser extensions, crawlers, etc.) only pick up about 40% of defects on a site (personally, I think that’s generous). That said, automated tools can be invaluable for identifying that low hanging fruit – skipped heading labels, redundant links, missing alt text, etc.
- Assistive Technology: Go get your hands on NVDA, or invest in JAWS (my personal favorite) to give the site a thorough run-through and make sure the screen reader can pick up all site content from beginning to end.
Step 6: Fill it in!
Once you’ve completed steps 1 through 5, the hard part is over. Now it’s time to sink some time into reviewing your product using the strategy you’ve chosen above and deliver a report on the accessible state of your product.
Good luck, have fun, take it seriously, and always remember that if you need any help with your remediation, compliance reporting, or any other various accessibility needs, please don’t hesitate to head over to our contact page and drop us a line – we’d love to help!
¹ – The Information Technology Industry Council [https://www.itic.org/policy/accessibility/vpat]
