If you build or maintain a WordPress plugin, accessibility has probably come up at some point. Maybe a customer asked about Web Content Accessibility Guidelines (WCAG) compliance, a procurement team requested documentation, or you’ve heard the term “VPAT” and wondered if it applies to your product. For WordPress plugin developers, a VPAT offers a clear, standardized way to communicate the accessibility conformance of your plugins to customers, partners, and procurement teams.
Let’s break down what a VPAT is, why it matters for WordPress plugins specifically, and what the process looks like in the real world.
What Is a VPAT?
A VPAT is a Template
VPAT stands for Voluntary Product Accessibility Template. This is a free template for creating accessibility reports in a standardized format. It was created by the Information Technology Industry Council (ITI), the premier global advocate for technology and a representative of the world’s most innovative companies.
The ITI Voluntary Product Accessibility Template (ITI VPAT®) translates accessibility requirements and standards, such as those in Europe’s EN 301 549 and the United States’ Section 508, into actionable testing criteria for products and services. Because it has a standardized format, using a VPAT to document your WordPress plugin’s accessibility results in reports that are easy for buyers to read and compare across plugins.
An ACR is Your Published Report
As noted above, a VPAT is the template name, not your final accessibility report. When the template is completed, the resulting document is called an Accessibility Conformance Report (ACR).
If a customer asks for a VPAT for your WordPress plugin, what they really mean is an Accessibility Conformance Report in VPAT format.
Accessibility Conformance Reports are the leading global reporting format for helping buyers identify the accessibility level of software and other information and communications technology.
An ACR explains how a product meets recognized accessibility standards, starting with WCAG 2.1 or WCAG 2.2 Level AA or AAA. The base VPAT template generates this WCAG ACR. If you are selling your products to the US federal or state government or government funding entities, there is a 508 VPAT that reports on conformance with WCAG and Section 508. If you sell your plugin in Europe, you want the EU version of the VPAT, which reports on conformance with WCAG and EN 301 549. The most comprehensive version of the VPAT is the International version which includes WCAG, Section 508, and EN 301 549.
An ACR is Not a Promise of Perfection
It’s important to note upfront: a VPAT is not a guarantee of “perfect accessibility.” It’s a transparency document.
For WordPress plugins, an ACR:
- Documents which accessibility criteria are supported.
- Clearly calls out partial support or known issues.
- Explains limitations and dependencies.
- Provides customers with a realistic view of accessibility today.
Your WordPress plugin does not have to be fully accessible or perfect before you use a VPAT to generate an Accessibility Conformance Report. You can create a report at any time for a specific version of your plugin, and update it as you improve your product’s accessibility. When done well, an ACR helps customers make informed decisions rather than guess, as it provides transparency into the product’s accessibility.
Article continued below.
Stay on top of web accessibility news and best practices.
Join our email list to get notified of changes to website accessibility laws, WordPress accessibility resources, and accessibility webinar invitations in your inbox.
Why WordPress Plugins Need an ACR
WordPress plugins are used across government, education, healthcare, and enterprise sites. Many of those organizations are legally required to evaluate the accessibility of the tools they use, not just their own content.
If your plugin handles functionality such as forms, navigation, learning experiences, or e-commerce, or presents core information central to the website visitor’s use or understanding, it must be accessible. Website owners are increasingly facing fines, loss of funding, and lawsuits for having inaccessible websites, and as a result, accessibility is becoming a larger factor in decisions about which plugins to add to their WordPress websites.
In some cases, such as with government websites, they cannot purchase your plugin unless you first provide an Accessibility Conformance Report.
Publishing an ACR for your plugin helps because it:
- Answers accessibility questions from prospective users without requiring them to contact your support team.
- Speeds up procurement and legal reviews.
- Builds trust with agencies and enterprise customers.
- Shows that accessibility is part of your product strategy, not an afterthought.
- Helps customers assess risk realistically or plan which settings to use or avoid.
A well-documented WordPress Plugin VPAT gives customers the information they need to evaluate accessibility without guesswork or lengthy back-and-forth. It saves your support and sales team time and can be used as a marketing tool.
Case Study
Listen to this podcast episode with Taylor Walden, who discusses the significant decrease in support tickets and the positive customer response following LearnDash’s accessibility improvements and ACR publication: Behind the Scenes of LearnDash’s Accessibility Overhaul.
WordPress Plugin VPAT Process
Creating a VPAT for a WordPress plugin isn’t just filling out a form. A meaningful ACR is based on hands-on testing and a solid understanding of both accessibility and WordPress.
A typical process looks like this:
1. Define the scope
The first step in creating a VPAT is clearly defining what the report covers. For WordPress plugins, this usually means identifying which parts of the plugin are in scope, such as frontend output, blocks, shortcodes, widgets, admin interfaces, settings pages, and any bundled templates. Scoping also includes documenting assumptions, like supported browsers, assistive technologies, and WordPress versions.
Being specific here matters because a VPAT is only meaningful if readers understand exactly what was evaluated and what was not.
2. Create a Testing Environment
Once the scope is defined, you need to create one or more testing environments. Give careful consideration to the active theme on the site, as it can introduce accessibility issues that may lead to failures incorrectly attributed to the plugin. We recommend using the most recent core WordPress theme (currently Twenty Twenty-Five) for accessibility testing your plugin, as core themes have already been tested and confirmed accessibility-ready.
The testing environments must include all possible settings and configurations for everything in scope. That means you may need to insert a block or shortcode multiple times, each with different attributes or settings, to show how it looks and functions across different configurations.
You may also need to have demo content on the site, such as fake posts or products for certain blocks or shortcodes to work. Hopefully, you already have this content created for other testing while you’re coding your plugin, but if not, you can use plugins like Test Content Generator or WooCommerce Smooth Generator to quickly create demo content. Be careful when testing to ensure any accessibility issues introduced in the content (like images without alternative text) aren’t tracked as issues caused by your plugin.
If there are global settings that change functionality (for example, WooCommerce has a setting that determines if a message is shown on the same page or if a user is redirected to their cart after adding a product to the cart), then you would need multiple environments — one with the setting enabled and one with it disabled. Alternatively, test with the setting disabled, then enable it and retest the related components or actions.
You don’t need your test environment to look nice or “production-ready,” but you need to ensure you have configured all possible scenarios to support a thorough audit of all in-scope components and pages. Setting up the test environments may be several hours of work in and of itself.
3. Accessibility testing
Once your test environment is set up, you can start testing. Start with automated testing for fast results. Our Accessibility Checker plugin can show you front-end issues. Browser extensions like WAVE or axe can be used in the WordPress admin.
Automated testing will not catch all issues, though, so you’ll also need to manually test for accessibility using keyboard-only navigation, screen readers, zoom, and other assistive technologies to understand how real users experience the plugin.
Manual testing uncovers issues with focus order, labeling, interaction patterns, error handling, and dynamic content that automated testing tools typically miss. For teams looking to build this skill internally, we offer training courses on testing with NVDA and VoiceOver. These courses teach developers, QA teams, and content creators how to confidently screen reader test and provide hands-on experience with the screen readers most commonly used in accessibility evaluations.
If you’re not confident as an accessibility tester, keep the WCAG documentation open and go through each criterion one at a time. Or, you may want to hire an accessibility tester to help with this part of the process.
(Optional) 4. Fix Problems
After auditing, you may want to fix some or all problems before publishing your Accessibility Conformance Report. This is an optional step — you can publish an ACR that says your plugin does not support any success criteria; that would be honest and transparent. Most plugin developers, however, prefer not to publish reports that mostly fail, as it can make them look bad to their customers.
If you prefer to publish an ACR that primarily supports WCAG or other accessibility standards, you’ll want to fix most or all issues, release an update to your plugin, and retest to confirm that all fixes are effective.
5. Document results in detail
While you’re testing, each applicable success criterion is documented in the VPAT with an accurate level of support and detailed notes.
When documenting accessibility in a VPAT, this is how you describe the level of conformance:
- Supports: The functionality of the plugin has at least one method that meets the criterion without known defects or provides equivalent facilitation. You should only choose this if there are no failures anywhere in your plugin for the specific criteria.
- Partially Supports: Some plugin functionality does not meet the criterion. Choose this if the plugin mostly passes, but has a few, limited failures.
- Does Not Support: The majority of plugin functionality does not meet the criterion.
- Not Applicable: The criterion is not relevant to the plugin. For example, most WordPress plugins do not include live videos, so all WCAG success criteria related to live video are not applicable.
- Not Evaluated: The plugin has not been evaluated against the criterion. This can only be used in WCAG Level AAA criteria. All other criteria should be fully evaluated before you publish your report.
For each criterion, choose the level of conformance and then write an explanation of what fails or passes or why the criterion is not applicable.
This is where clarity and honesty are critical. Instead of vague statements or overly optimistic language, a strong VPAT/ACR explains how the plugin behaves, where it meets requirements, and where limitations exist. Customers rely on this information to assess risk, so clear explanations are far more valuable than marking everything as “supports” without context.
Specific details to include:
- If specific settings are required for conformance, list them so your customers know how to configure your plugin for the most accessible output.
- If a component fails due to a critical third-party vendor or library you’re using in your plugin, report the problem upstream, then describe the failure and that it has been reported, so customers are aware of issues outside your control.
- If you have a timeline for fixing an issue in the future or a planned version number, list that information as well.
6. Account for WordPress dependencies
WordPress plugins don’t operate in isolation, and a good VPAT acknowledges that. Themes, user-generated content, third-party integrations, and site configuration can all affect accessibility outcomes.
As you complete the VPAT, ensure you document known dependencies and explain how they affect conformance. For example, a plugin may output accessible markup by default, but theme styles or editor choices could break that accessibility. A common example of this is that your plugin colors may pass contrast minimums by default, but a theme may have poor color choices that override your plugin’s styles and introduce failures.
In the notes section of the VPAT, explicitly state the active theme on the testing website and any other plugins that were active when you tested. Be clear that your results may not apply in other scenarios. We typically include a statement like this:
The scope of this report is limited to the accessibility of front-end user interfaces for [plugin name]. It does not cover the backend WordPress admin interfaces of [plugin name]. It also does not cover the accessibility of any add-on plugins or extensions.
Testing of front-end components was completed on a website utilizing the Twenty Twenty-Five theme (version 1.1) with default settings. As WordPress themes can significantly impact frontend design and accessibility, the conformance levels reported may not apply to websites built with other or customized themes.
Additionally, this report does not cover accessibility in the WordPress content management system as a whole.
Being transparent about your testing site and the impact a theme can have on your plugin’s accessibility helps set realistic expectations for customers.
7. Review and finalize
Before your ACR is published, the report should be reviewed for accuracy, consistency, and usefulness. This includes checking that testing notes align with the documented conformance levels and that explanations are clear to non-technical readers, such as procurement teams or legal reviewers.
If your team is not confident in its knowledge of WCAG, Section 508, or EN 301 549, then it is best to have an external expert review your VPAT. A legal statement can be included at the end of the document, and you may also want a qualified attorney to review or draft this for you.
The final Accessibility Conformance Report should be a defensible, easy-to-understand document that reflects the plugin’s true current state. A thorough review helps ensure your report stands up to scrutiny and serves as a reliable reference for customers.
Example WordPress Plugin ACRs
Want to see some real Accessibility Conformance Reports for WordPress plugins? Here are some examples of reports created from the official VPAT from ITI.
- Accessibility Checker ACR (International Version)
- LearnDash ACR (International Version)
- UW Storytelling Modules (WCAG Version up to AA)
- WooCommerce ACR (International Version)
- Conditional Shipping and Payments for WooCommerce ACR (WCAG Version up to AAA)
- See 20+ more WooCommerce ACRs
Note: Most of these ACRs were created by us.
How Equalize Digital Helps
If you want help completing a VPAT or creating an Accessibility Conformance Report for your WordPress plugin, we’re here to help. We’re proud to be the accessibility auditing team for popular WordPress plugins, including WooCommerce, LearnDash, Kadence, The Events Calendar, GiveWP, Search and Filter Pro, and Termageddon, among others.
We can help you or your dev team through:
- Assisting with or advising on test site setup.
- Manual accessibility audits of your plugin.
- Detailed reports of issues with straightforward recommendations for fixes.
- Accessibility consulting or dev assistance.
- VPAT drafting and Accessibility Conformance Reports backed by our trusted reputation.
When you work with Equalize Digital to create a VPAT / ACR for your WordPress plugin, you also gain the value of our nearly 20 years of WordPress experience and presence on the WordPress core accessibility team.
Unlike other accessibility companies that lack deep WordPress expertise, we can quickly determine whether a problem originates from your plugin or WordPress itself. This means less noise in accessibility reports. Our expertise in WordPress also enables us to provide more detailed, actionable recommendations for fixes and development assistance, if needed.
Start Planning a VPAT for Your Plugin Today
Accessibility transparency is quickly becoming the expectation, not the exception. For WordPress plugin developers, an Accessibility Conformance Report is one of the most practical ways to show where your product stands and where it’s headed. It can help your plugin stand out in a crowded market of more than 60,000 plugins and make your plugin more appealing to government, education, e-commerce, and business websites with budgets to invest in quality solutions.
Now’s the time to get started on a VPAT. The first step is to audit your plugin for accessibility to understand where it stands. Do this now:
- Download the free VPAT template.
- Schedule time on your calendar to start accessibility testing your plugin.
Or, contact us — we’d love to be part of your plugin’s accessibility success story.
