A note on the acronyms:
VPAT stands for "." It's the standard document used to demonstrate compliance with听. WCAG compliance is a legal requirement for many organizations, including听. (Note that Quebec's accessibility standard (the听Standard sur l鈥檃ccessibilit茅 des sites Web) is only available in French.)
Technically, VPAT refers to the empty template. Once it's filled out, the appropriate term is ACR (which stands for Accessibility Conformance Report).

In this resource:

• How to evaluate accessibility of licensed products
• How to evaluate accessibility of custom or vendor-built websites or applications
  • How to do an assessment yourself
  • Hiring a consultant to do the assessment

For licensed software projects

If you're working with a听licensed software vendor, it's their responsibility to provide an ACR. If a vendor can't provide one, it means their company or product may not be mature. (This is a sign to find another vendor!)

You should get the听ACR听and review it听before signing your contract. As you review it, here are items to take note of.

You should also consider how each vendor's ACR compares to the other vendors bidding on the contract. In general, you want to see a highly detailed ACR that shows a commitment to finding and resolving issues. This is better than a ACR with few concrete details, even if all criteria are marked as "fully supported." (If a vendor provides an ACR with no remarks or explanations, ask if they can provide you with a more detailed version.)

During your project, keep an eye on whether the company is regularly addressing bugs and accessibility issues. Make sure you always have the latest version of their ACR.

Once you have a demo site or test instance, consider how customizations made for your project could affect compliance. Here are some examples:

• The vendor allows you to customize their product with 91社区's brand colors. This means the colors in the 91社区 version of the application won't match what was tested in the ACR. To address this, find out everywhere customized colors will appear, and听听for appropriate contrast.*
• The base product (evaluated in the ACR) didn't come with video content, but your version will have a video. Make sure the video complies with the applicable WCAG success criteria (including controls and closed captioning). Similarly, if you can add your own images to the tool, you'll need to make sure they're compliant (by adding alt text, for example).听
• The base product had a native form tool, but you'll be linking to a form on another system. This is a good time to verify the other system (and its forms) are compliant.听
• The content comes from your team, so it hasn't been tested in the ACR. To be compliant, your content should听use plain language听and be听properly formatted for accessibility.听

As your project closes, see if you can incorporate some听accessibility-oriented testing activities听(such as screen reader testing, keyboard navigation, and automated scans). This will let you confidently and independently understand how the product is accessible, and where it could be improved. Even after project launch, you should absolutely advocate for accessibility-oriented updates with your vendor. These updates can benefit all the clients (and users) of the software.听

*听Note that if you're using 91社区 red for text or backgrounds, you may see the mention "AA Large" when you test for contrast. To meet this requirement, the text will need to either:

• Use a bold font and display at a physical size of 14 point (this usually means 18.66px), or
• Display at a physical size of 18 point (24px) or larger if using regular or light fonts.

For custom websites or applications

In the case of custom websites, you're responsible for the ACR.听

Before signing a contract, you should make sure the vendor knows that a VPAT will be used to evaluate their work. Ideally, compliance will be part of your contract with them. A reputable vendor will already have an understanding of how to deliver an accessible website and address any issues uncovered in the VPAT assessment. This should not substantially affect project costs. (If your vendor isn't comfortable with web accessibility, or claims it will be very costly, consider finding other vendors to bid on the project.)

Using the听听can accelerate the design and accessibility compliance of your site. Be sure to mention this to the vendor, since it may allow them to reduce their fees or include more features at the same price.

At project kick-off, plan when and how the VPAT assessment will be done.听You can do it yourself (or ask a member of your team to do it), or hire a consultant.听

Do the assessment yourself

First, understand what it means to听make your site accessible.

• Make sure you have a听strong understanding 91社区's Digital Standards, which cover all requirements and best practices applicable to your 91社区 website.
• Take our听WS-106 course听to deepen your understanding of the WCAG success criteria and how to evaluate them.听
• Identify and set up the听tools you'll use to help evaluate accessibility.听

Then, consider when and how you'll conduct your evaluations. This should match the vendor's delivery strategy for the project. Most vendors work iteratively, building discrete units of your project and delivering them one by one.

Here are two possible ways to manage an听iterative delivery and testing听schedule:

1. Test听individual components or templates as they're delivered by the vendor. For example:
   • In test session 1, you might test the header, navigation, and footer.
   • In session 2, you might test the homepage template.
   • In session 3, you might test the different templates in your "news" section.
2. Test听key user flows as they're developed. For example:
   • In test session 1, you might test navigating the homepage and signing up for the newsletter.
   • In session 2, you might test reading an article, commenting on an article, and browsing to a related article.听
   • In session 3, you might test searching for an event, reading the description, and registering to attend.听

Note that the components, templates, or user flows you test will depend on what's relevant for your project - these are just examples!

You should always听do a complete test near the end of your project, when work is finished but not yet launched. This is often called UAT (user acceptance testing), because this is when you'll review the website and formally accept or "sign off" on the project.

If you haven't been able to test things iteratively, make sure you have at least 2 - 3 weeks to complete a full test and allow the vendor time to fix any issues. (If you've tested iteratively, you might be able to do this in less time.) During your assessment, download and fill out the听.听As you complete the report:

• Be sure to use a mix of听automated, manual, and functional testing methods. For example, you might run an automated test, browse the entire site with a screen reader tool, and complete common tasks using exclusively keyboard navigation and 200% zoom.
• 听(available in French only). At the time of this writing, that means WCAG 2.0 at levels A and AA.
• Fill in the "remarks and explanations" column of the success criteria table(s). Include:
  • A short summary of the overall level of performance for the criteria. (For example, "Almost every interactive element and content piece is accessible and operable using a keyboard or keyboard
    emulator.")
  • Any exceptions, where the product doesn't match the general level of performance. (For example, "Exceptions include launching the "filters" window in the search results interface.")
  • Information about which user persona or workflow any issues belong to, if this will help understand the issue and how to fix it.听

When the ACR is complete, notify the vendor of any areas where changes are needed to meet full compliance.

Once the vendor has addressed the issues to the best of their ability, update the ACR and听web.comms [at] mcgill.ca (share it with Digital Communications)听so that we have a record of the project's compliance.听

Hire an independent accessibility consultant

There are a range of possibilities here, from individual consultants to giant accessibility-focused companies. You should do your own research into which companies offer ACR authoring services, and what their rates are. As with nearly every type of web service, we recommend you:

• Get multiple quotes from different companies (at least three realistic options).
• Look for companies that have done work on similar projects in the past.
• Avoid doing business with individual freelancers or students, unless they have a demonstrated track record and impeccable references. (Speak with the references!)
• Make sure the consultant will听.听

Plan for the consultant to do at least two, and maybe three reviews:

1. A complete review of your website or application near the end of the project (when the website is mostly complete, but there's still time to address outstanding issues).
2. A revision of the ACR after the vendor has addressed any issues from the first review.
3. Consider requesting an additional review if the vendor will address outstanding issues after the second revision, or if you make other changes to the site.

Review the ACR after the consultant delivers it. Use the assessment review table above听to guide your review.听

After review, you should have a list of corrections to request from the site vendor, and a sense of their relative importance. After the vendor updates the site, ask your consultant to review the changes so that the ACR can be updated.听

After launch, be mindful of any changes you make to the site. Adding features, modifying colors, changing typefaces, updating plugins, or introducing new types of media can affect your site's accessibility.

Consider training yourself (or a member of your team) to be able to audit and record compliance information. That way, you can maintain and document compliance efficiently and affordably as your site evolves.

You should also keep an eye out for changes to our legal requirements around accessibility. Sign up for the听听and听regularly attend training and events听to help stay current with requirements for your site.听