Are You Receiving the Accessibility Tips and Tricks?
- Receive tips for making electronic information accessible
- Implement what you learn right away
- Understand how people with disabilities see the world
- Receive our short monthly newsletter packed with news, articles and updates
Creating An Effective Voluntary Product Accessibility Template (VPAT)
When you create your Voluntary Product Accessibility Template (VPAT), it is your chance to let procurement agents know in detail about the accessibility of your product, and show how you differ from your competition. Often times, when your competition offers similar functionality, Section 508 compliance itself can be the only deciding factor. In this article, I will show you how to put together a VPAT which effectively communicates the accessibility of your product. In addition, you can also view and download a blank VPAT that you can fill out yourself.
If you would like to learn more about Voluntary Product Accessibility Templates, please also check the following pages:
- Voluntary Product Accessibility Templates (VPATs) Explained
- Section 508 And Federal Procurement
- VPAT Directory
Why should your VPAT be effective?
Unfortunately Section 508 is often treated as a check box, and not many companies put enough effort into convincing their customers why their products are Section 508 compliant. Similarly, VPATs are often used to show that they do exist, but in many instances, they provide very little information on a products accessibility.
Government procurement agents, however, consider VPATs more and more during their decision making. In certain instances, it is possible that many products meet the functional criteria requirements, and the most accessible/Section 508 compliant one will be purchased. In this case, when procurement agents have an informative VPAT to rely on, you can help make the decision making process much faster. If the competing products do not have VPATs, the government can conduct in-house accessibility reviews of all products, in which case you will have to provide the information that should have been in the VPAT to begin with.
Know your product
It is not enough to understand the functionality of your product, also make sure you know why it is accessible, and how it complies with Section 508. You will see later that it is not enough to claim that your product meets a certain Section 508 standard, but it will benefit you to address what you have done to achieve compliance. Before writing a good VPAT, it is useful to conduct a very thorough accessibility testing on your product.
Download a blank template
Before we talk about the template, obtain one to work with. Here, you can download a MS Word version of a VPAT, it is hosted on The Information Technology Industry Council's web site. Also, download a Word Viewer. Alternatively, you can view an HTML version. After opening it, just save the document, and you will be ready to fill it in with your favorite HTML editor.
The layout of the VPAT
The top section of the VPAT is general information about your product, I only indicated the product name and date. Feel free to modify it according to your needs to include company or contact information.
The rest of the VPAT consists of nine tables. The first is a summary table, listing eight set of Section 508 standards, and the other eight tables are the actual sets of standards.
All tables consist of three columns. The left column is a Section 508 standard, labeled as criteria. The middle column is supporting features, and the last column is remarks and explanations
Completing the VPAT
The first column should be left intact. Only the second and third columns will be filled out, which are currently blank.
The supporting features column describes the extent that the Section 508 standard in the left column is met. This description could be any of the following:
- Supports
- Supports with exceptions
- Supports through equivalent facilitation
- Does not support
- Not applicable
In the third column, you can describe your statement of the supporting features in greater detail. This is where you can claim that your product is accessible, and to describe how you have reached the level of accessibility.
Based on your supporting features selection, you can fill the second and third columns as follows:
Supports
Your product fully meets the requirements of the standard in the left column, without any questions or exceptions. In the remarks column, detail how you have reached full compliance. For example in case of standard 1194.21 (A), do not only say that the product works with the keyboard, but explain if you have provided keyboard shortcuts for different functionalities, as well as you allowed accessing these functionalities from a keyboard navigable menu. You could even include a link to a page listing all the keyboard commands, for the purposes of a VPAT it is not necessary to list those here.
Supports with exceptions
It means that the standard in the left column is met for the most part, but certain exceptions apply. Describe all features in detail which meet the Section 508 standard in the left column. Also, describe where your product does not meet this standard, explain why not, and provide any alternative information on workarounds which can be used, even if it is not Section 508 compliant.
Supports through equivalent facilitation
In certain cases, it is difficult or for some reason not possible to meet the exact requirements of a Section 508 standard. However, when your application is still usable for people with disabilities without more efforts than it is for any other people, you can claim that the standard is supported through equivalent facilitation. Regulations are not very clear here, and it will most likely be decided on an individual basis if the product meets equivalent facilitation. Staying with the keyboard example, of a product is not keyboard accessible and only works with a touch screen, but you provide a voice command system which achieves the same results allowing access to all functionalities, you could claim equivalent facilitation. Do not confuse equivalent facilitation with alternative access. For example, if a product is not keyboard accessible, but you can provide a personal assistant for the user when needed, it would fall into the category of alternative access.
Does not support
A standard is not supported when your product does not comply with a given standard, or it meets a standard on occasion, but for the most part it is non-compliant. Probably this is the hardest thing to detail in a VPAT, because you are essentially establishing the inaccessibility of your product here. However, it is important to describe where your product does not meet the Section 508 standards in such great details that you have used when describing standards which are fully supported. Remember that most likely you are competing with other products, and even if the lack of compliance has to be considered, procurement agents will have an easier time justifying the purchase of your product where your competitor has the same level of non-compliance.
Not applicable
A standard is not applicable when you have established that either a group of standards collectively do not apply to your product, or a given standard is not relevant to the functionality of your product. For example, in case of a web based application, 1194.22 (G) is not applicable if your application does not use data tables.
The different tables
The first table is to provide an overview of your product. This is where you can establish which of the following eight set of standards apply to your product. Use descriptions in the supporting features columns as described above, but it is not necessary to enter detailed information in the remarks column. For example, if your product is a web application, for standard 1194.26 you would fill out the supporting features column as not applicable, and the remarks as the product is not a desktop or portable computer.
Based on which set of standards are applicable from the first table, fill out the tables 1194.21--1194.26 accordingly. You will find that some VPATs only use the applicable tables, and others fill out all tables even if those do not apply. In this case, it is sufficient to say not applicable in the second column, and leave the third column blank, as applicability has already been established in the summary table. Certain agencies will require a fully completed VPAT, and completing all tables also helps looking at your product as a complete information technology solution. It is recommended to use all tables if possible.
In most cases, when your product met the standards, the 1194.31, functional performance criteria will be supported. For example, going back to the keyboard example, 1194.31 (A) is supported both when you provide keyboard functionality, or an equivalent facilitation for a touch screen. However, it does not only apply to the keyboard, but to any other functionality which you have previously described above.
The last table must be filled out, as it is applicable to all products. In ideal circumstances, all standards are supported, as they require you to provide users with alternative formats of documentations, a description of accessibility features, and accessible support services.
What to do if your product is not Section 508 compliant?
After filling out the VPAT, you might find that your product is not fully Section 508 compliant. While you are working on the non-compliance issues, it is a good idea to create an accessibility roadmap, detailing how and when you will bring your product to full compliance. This roadmap can be attached to the VPAT, as it contains related information. When two equally inaccessible products are competing on the market, the one which has a plan for full accessibility tends to have a better success rate.
Conclusion
While VPATs are "voluntary", it is always a good idea to write one for your product, and it might be specifically requested from a government procurement agent. Always be honest about non-compliance issues and explain everything in great detail. It is commonly understood that we do not live in a fully accessible world, and a company which takes accessibility seriously always gets extra credit for it one way or another.
You might have found that some of the terminology or legislation discussed above is not familiar to you. Discussing Section 508 standards is outside the scope of this document.
However, if you have any questions about the VPAT, or you need assistance filling one out, please contact us!








a question regarding this informative article
In creating a voluntary product accessibility template, do you
think it is a good idea to let a group of persons with disabilities use our software first before actually writing down the document?
Testing with people with disabilities
Keith,
You have an often overlooked point here. For the sake of the VPAT, it is not necessary, as you have to detail in the VPAT how your product complies with Section 508. Regardless of testing results, you have a set of standards, which you need to follow, comply with, and explain how your product complies or does not comply with each one of them.
However, separate from the VPAT, it is always a good idea to have different user groups test your product. It is definitely worth having people with different disabilities who use different technologies test it.
If you have an accessibility consultant evaluate your product, they will be able to tell you if it works with different technologies, but the end-user testing should always be performed if you have the resources to do so.
Post new comment