As a background, the Commonwealth’s Information Technology Act requires that all state and public institutions ensure their information and communication technology (ICT) is accessible to people with disabilities.

HB2541 broadens the scope of this Act by, among other requirements, doubling down on accessible technology procurement. More details on the bill’s requirements will be provided in a moment.

First, let’s recognize the significance of this milestone moment:

• The bill’s passage means accessible procurement is not just another box to check. This bill signals that digital accessibility is a procurement requirement.
• The responsibility to create accessible software must be shared by the vendor who is making the software, rather than the buyer solely taking ownership and legal risk.

In this blog, I break down the requirements of HB2541, who the bill applies to, deadlines for compliance, and why it matters.

What Does HB2541 Enact?

HB2541 modernizes Virginia’s approach to accessible technology by significantly expanding the scope of its Information Technology Access Act.

The bill ensures that accessibility requirements apply to all individuals with disabilities, not just those who are blind or visually impaired. It also broadens the definition of ICT to include websites, applications, and other digital services.

To verify compliance, HB2541 requires vendors to provide software Accessibility Conformance Reports (ACRs)—outlining the accurate state of product accessibility. The ACR is built on the Voluntary Product Accessibility Template (VPAT®).

And, where accessibility gaps exist, vendors must go a step further and submit a Vendor Accessibility Roadmap outlining areas of nonconformance, as well as a timeline for planned remediation.

This “product accessibility roadmap” transforms the VPAT from a procurement box to check into a living document—the intended purpose of the VPAT from its creation. 
 
HB2541 also encourages public entities to designate Digital Accessibility Coordinators who will be responsible for policy implementation and barrier remediation.

Finally, the bill introduces formal reporting and oversight mechanisms to help agencies track noncompliant ICT and estimate the resources needed to bring systems into conformance.

Who Must Comply with HB2541?

Covered entities under HB2541 include:

• All Virginia state agencies
• Public school divisions
• Public institutions of higher education
• Local government bodies and special districts

These organizations are now responsible for procuring, developing, and using digital tools that are accessible to all users, including those with disabilities.

The timing of the passing of this bill, which has been in the works for some time, aligns with the recent landmark legal case against West Virginia University, which litigated the issue of blind students not being able to access third-party technology.

HB2541 was created to protect entities, such as West Virginia University, from some of the legal risk by assigning shared responsibility to software vendors.

What Is Required to Comply with HB2541?

For the list of covered entities outlined above:

• ICT procured or developed in-house must conform to federal accessibility standards such as Section 508 of the Rehabilitation Act and the DOJ’s recently finalized Title II regulations under the ADA, which require WCAG 2.1 AA compliance by 2026 or 2027 depending on the size of the entity.
• All new or renewed contracts for software or digital tools must include an accessibility clause.
• If a product isn’t fully conformant (which is highly unlikely to be the case or be expected of these software vendors), a completed VPAT / ACR and a Vendor Accessibility Roadmap must be submitted.
• Each agency may appoint a Digital Accessibility Coordinator and must post contact info online for reporting digital barriers.

For software vendors:

• Be prepared to demonstrate a software’s accessibility status using a current VPAT / ACR (Allyant recommends updating this document at least annually as procuring entities need to report annually to the General Assembly on noncompliant ICT under this bill.)
• Disclose areas of noncompliance and provide a realistic timeline and plan to resolve them.
• Partner with a qualified accessibility subject matter expert or neutral third party to produce reports (Allyant can help).

What Are the Key Deadlines for Compliance with HB2541?

HB2541 includes a phased rollout based on the size and type of entity which aligns directly with the DOJ Title II regulations for these same covered entities:

• April 24, 2026—Applies to:
  • Covered entities with populations of 50,000 or more
  • State public bodies
  • Institutions of higher education
• April 26, 2027—Applies to:
  • Special districts
  • Covered entities with populations less than 50,000

Each new or renewed ICT contract after these dates must include the accessibility certification requirements outlined in the bill’s final text.

Are There Any Exceptions?

HB2541 does include a few exceptions, which include:

• An exception may only be made if purchasing an accessible item would increase the total procurement cost by more than 5%.
  • From my experience, this exception will be extremely difficult to enforce. If this is enacted, most competitive vendors will fall within a 5% window of one another, which will create “contesting” of awards. However, this will also strongly encourage software vendors to build accessibility into their applications, positioning them to win significantly more business in Virginia (and nationally)—not to mention fulfilling the spirit of the legislation, which is to make products that are accessible for people with disabilities
• ICT exclusively used by non-visually impaired users can still be procured and will be exempt from HB2541 requirements.
  • I believe this exception is misaligned with Title II requirements and digital accessibility in general. WCAG and the VPAT / ACR template cover all disabilities, not just non-visually impaired users. For example, it is conceivable that an internal (employee) or external user of a procured software has a physical or motor dexterity disability and relies on keyboard-only navigation because they can’t use a mouse. If the product is not accessible for them, this non-visually impaired user would not be able to leverage the software, and he or she would be excluded.
• Agencies must report exceptions on an annual basis and provide estimates of the costs required to bring noncompliant ICT into alignment.
  • I appreciate that exceptions must be reported. In full transparency, this allows a competitive software vendor who commits to building and deploying accessible software to win business from their competition, which is a win for equal access. However, I also find this exception somewhat misaligned with the overall spirit of this bill’s goal of shifting liability to the software vendor. In most cases, it would be the software vendor that must ensure its product is accessible. This should not increase costs for the procuring entity and should instead be viewed as a cost of doing business. WCAG is nearly 30 years old, and there are global regulations that require conformance, so we have passed the point of software vendors not having time to comply or incorporate accessibility standards into their development lifecycles. Ultimately, competition drives innovation, and, in this sense, accessible software. I’m confident software vendors addressing specific niche product needs will step up and commit to accessibility, ultimately rendering this exception moot.

Why HB2541 Matters, and Why It’s the Right Move

While federal and state-level legislation is moving in the right direction by requiring accessible digital content and ICT, it fails to hold vendors accountable. For example:

• The Department of Justice’s 2024 Final Rule for Title II entities under the ADA requires digital compliance with WCAG 2.1 AA by 2026 or 2027, depending on entity size.
• The U.S. Department of Health and Human Services (HHS) is finalizing similar digital accessibility requirements for healthcare entities.
• HB21-1110 in Colorado mandates accessibility for all state and local government digital resources, with a deadline set for July 1, 2025.

The responsibility of accessibility lies with the procuring entity—who has little or no ability to make the product they’re buying accessible. This presents an unfair pain point for most state and municipal governments, as well as educational institutions—especially when they have no choice because the accessible software they need doesn’t exist.

Pushing Accountability Upstream: A Vendor Wake-Up Call

Virginia’s approach to codifying accessible product procurement—placing greater responsibility on the software creator—will advance accessibility. It will compel the creation of accessible products, providing covered entities with more purchasing options while mitigating compliance risk.

No software will ever be perfect, but that isn’t an excuse for inaction.

By requiring vendors to be transparent, provide accurate VPATs/ACRs, and offer plans for improvement, Virginia is asserting: “Accessibility is a shared responsibility.” This marks a milestone moment for the advancement of accessibility.

What Should Covered Entities Do Now to Comply with HB2541?

If you are a state agency, public school division, or higher education institution in Virginia, time is of the essence. There are two critical steps I recommend to comply with this new regulation in the next 12 months:

Step 1: Start with a risk matrix of every third-party software or other ICT your team has procured.

This matrix should include:

1. Number of users
2. Whether it’s public-facing or internal
3. The purpose of the software
4. Its renewal date
5. The product costs

This simple matrix will help you quickly prioritize the most critical third-party software you have procured. For example, considering the “exceptions” of HB2541, if you have third-party software used by two internal users, this poses a fairly low risk. Alternatively, if you are a K-12 school that has procured software accessed by every student and parent to perform core functions for educational purposes, this presents a very high risk.

Step 2: After mapping out this matrix, I would begin working on process improvements for upcoming purchases or renewals to set the stage for HB2541 compliance:

1. Appoint a Digital Accessibility Coordinator as mandated by the bill.
2. Update procurement processes promptly to request a third-party VPAT/ACR from each software vendor from whom you are procuring or renewing.
3. Establish a centralized inventory and roadmap for digital tools that need improvement, which will be easy for vendors to provide if they work with a reputable third party to perform ongoing product testing.
4. Engage with trusted partners like Allyant to assess software or VPATs/ACRs from vendors you are considering. A trusted partner will provide remediation guidance on the strength and accuracy of these procurement tools to ensure compliance with HB2541.

What Software Vendors Must Do to Comply (and Sell Their Product)

If you’re a software vendor selling into the Virginia public sector, the clock is ticking. But this is just one accessibility compliance deadline you might face—Colorado’s HB21-1110 compliance deadline is July 1, 2025, and the EAA has a compliance deadline of June 28, 2025.

1. Audit your product against WCAG 2.2 AA with expert testers and individuals with disabilities, rather than relying solely on automation. Ensure the testing methodology is clearly outlined on your VPAT/ACR to comply with HB2541.
2. Publish a current VPAT/ACR that reflects transparent findings from this testing, rather than marketing or sales fluff.
3. Develop a Product Accessibility Roadmap to address any identified gaps, which will necessitate using an Accessibility Management Platform.
4. Implement regular retesting cycles, as accessibility isn’t a one-time event. Additionally, you must provide updated VPATs / ACRs annually to comply with HB2541.
5. Prepare your sales and legal teams to speak confidently about accessibility status and timelines, as this will be a necessary part of the purchasing process and must be included in the contract language going forward.

Setting the National Standard

Virginia’s HB2541 is more than just a state-level compliance standard. It demonstrates the leadership public entities have been longing for. It bridges the gap between intent and action in digital accessibility by holding accountable the vendors who develop the tools that agencies purchase and that we all rely on.

I’m hopeful this bill sets a precedent for other states to follow. The reality is that covered entities shouldn’t be left alone to absorb the legal risks of inaccessible software, nor should they bear the brunt and costs of remediating accessibility issues when these are fully out of their control.

If you’re ready to discuss your compliance roadmap—whether you’re a software vendor, a public-sector agency, or another entity, Allyant is here to help. Connect with our team today.

The post Virginia Passes HB2541: A Milestone Achievement for Accessible Procurement first appeared on Allyant.

Although regulatory deadlines and legal pressures will undoubtedly drive action (or reaction), it is always critical to recognize accessibility as a business need and celebrate accessibility wins when achieved.

In this guide, I aim to provide a roadmap to help you plan for the year ahead, highlighting key deadlines, anticipated trends, and practical steps to either rebuild your accessibility strategy or continue expanding on your progress from 2024.

Whether you’re navigating new regulations, enhancing your team’s knowledge, or preparing for the next wave of innovation, 2025 is poised to be a pivotal year for digital accessibility.

Why 2025 Matters for Digital Accessibility

When we think about accessibility, it’s easy to focus on the here and now—meeting today’s requirements or responding to immediate legal challenges.

But 2025 is a year in which I envision a shift in the market.

Forward-thinking planning will pay strong dividends or be realized by those teams that began this in 2024.

Several major regulatory deadlines loom, and the groundwork laid now will determine whether organizations stay ahead of the curve or struggle to keep pace.

Let’s dive into some of these key deadlines and what they mean for your organization.

Key Accessibility Deadlines Shaping 2025

European Accessibility Act (EAA) – June 2025

The EAA is a game changer for businesses selling to European markets. By June 2025, companies must ensure their digital products and services comply with EN 301 549 (based on WCAG 2.1 AA), a standard that ensures accessibility for people with disabilities.

This requirement applies to websites, mobile apps, e-commerce platforms, and even certain physical products featuring digital interfaces.

Non-compliance carries significant risks. This includes exclusion from the EU market of consumers but also legal penalties.

If your organization operates internationally, now is the time to assess your digital properties, identify gaps, and create a roadmap for compliance. Learn more about the EAA and its impact in this in-depth article.

Colorado HB-21 – July 1, 2025

Closer to home, Colorado’s HB-21 is setting a new standard for state-level accessibility legislation. This law requires state government websites, mobile applications, and digital documents to meet the standards of WCAG 2.1.

For organizations working with or within state government, this deadline serves as a clear call to action. The bill’s supporters emphasized that after the 12-month extension granted in 2024, the time to comply is now.

More broadly, HB-21 is a bellwether for other states. As we’ll discuss later, I believe we’ll see similar legislation emerging across the U.S. in the coming years!

Future Regulations: Preparing Beyond 2025

While the immediate focus is on 2025, it’s critical to keep an eye on what lies ahead after a ground-breaking year for accessibility regulations in 2024.

Some of the most significant accessibility regulations (specifically for U.S.-based organizations) have deadlines in 2026, but providing your team with enough time to conform means starting now.

DOJ Title II Regulations (2026)

The long-awaited Title II regulations will set clear requirements for public sector entities (Federal and State Governments and Public Education, for example) to ensure their digital properties comply with WCAG 2.1 AA.

These rules will bring much-needed clarity to accessibility expectations for government agencies, but they also require extensive planning and resources.

The deadline to comply with this regulation for covered entities is April 2026 – less than a year and a half away, which means your team should be well underway with procurement and vendor selection in order to meet the forthcoming deadlines and compliance requirements for your website(s), applications and digital documents. Learn more about how Allyant can help here.

HHS Accessibility Mandates (2026)

Healthcare organizations face their own set of challenges with new regulations under Section 504. As patient care increasingly moves online, ensuring accessible digital experiences and documents isn’t just about compliance—it’s about equity.

The final ruling released in May 2024 outlined a clear scope and timeline for healthcare organizations to comply with these regulatory updates.

Like the Title II regulations, the HHS regulations’ May 2026 compliance deadline is less than a year and a half away. This detailed breakdown explains what is required of healthcare organizations.

AODA Reporting Deadline – December 31, 2026

Canadian organizations must report (for the second time) their accessibility compliance under the AODA by the end of 2026.

However, this deadline is a bit of a misnomer, as many organizations have learned through settlement agreements in 2024. If you’re not already in compliance with the AODA, you’ve missed the mark. For businesses operating in Canada, the time to act is now. Explore our full breakdown of the AODA and Canadian accessibility laws.

Building Knowledge: Where to Learn and Grow in 2025

Accessibility is a constantly evolving field, and staying informed is key to keeping pace with the latest regulations, trends, and innovations.

Conferences and industry events provide not only valuable knowledge but also the opportunity to connect with peers and thought leaders across many sectors.

As any accessibility SME would highlight, the number of conferences or global industry events (e.g., CES and SXSW in recent years) that now include accessibility tracks and sessions has grown exponentially in the past few years.

This growth provides your team with many more opportunities to learn about digital accessibility and build out your internal processes. However, here are just a few standout events I would strongly recommend your team considers attending in 2025:

• CSUN Assistive Technology Conference:
  Held annually in Anaheim, California, this March event is a cornerstone for accessibility and assistive technology professionals. Known for its hands-on exhibits and in-depth sessions, it’s the perfect place to explore cutting-edge technology and practical solutions.
• Disability:IN Global Conference:
  Scheduled for July 2025 in Orlando, Florida, this conference is a hub for corporate accessibility leaders. A significant focus is on accessibility within procurement, hiring and building out internal processes and policies, with sessions and workshops offering practical tools for organizations striving to meet legal and ethical requirements.
• M-Enabling Summit:
  This event, set for October 2025 in Washington, D.C., will examine global accessibility trends and innovative technologies affecting the space. Its focus on enabling inclusive technology solutions across industries makes it a fantastic resource for organizations looking to stay ahead of their competitors and increasing regulatory requirements.

These are just a few of the many fantastic accessibility conferences where you’ll find Allyant in 2025 attending, speaking, and sharing insights across a number of topics.

Stay tuned to our Allyant LinkedIn page for updates on industry events and conferences that your team might want to attend. We’ll keep you informed on opportunities to learn, connect, and grow alongside us!

My Predictions for 2025

Predicting the future is always tricky and perhaps even risky if you take it too seriously. In fact, I’ll admit, I might be completely off on a few of these when we look back 12 months from now!

However, based on the trends our team has seen over the past 6-12 months, here are some developments I think will shape the accessibility landscape in 2025.

These predictions are rooted in experience and emerging patterns, but hey, if the future proves me wrong, at least we’re having a fun conversation!

1. Procurement Accessibility Takes Center Stage

Accessibility is no longer just a check-the-box procurement exercise but has quickly become a strategic priority.

Why? Procurement (and legal) teams are realizing that buying inaccessible technology introduces risks far beyond compliance penalties outlined in the above regulations. Inaccessible tools can exclude employees, limit productivity, and lead to legal exposure. As a result, I predict an even greater demand for updated, third-party verified VPAT ACRs to extend the headwinds on this topic we saw in 2024. Organizations will shift to annual accessibility testing and continuous updates to VPAT documentation due to contract requirements and competition with other vendors prioritizing accessibility.

Our work with leading enterprises shows that procurement decisions increasingly include accessibility as part of the vendor scorecard. Through the work that Disability:IN is doing with Procure Access and organizations like NCADEMI pushing accessible procurement in education, I expect this accessibility topic to continue to drive conversations throughout 2025!

2. WCAG Conformance Becomes a Contract Standard for Digital Agencies

If you’re a digital agency, get ready: WCAG conformance is fast becoming a must-have “feature” in website and application builds.

Lawsuits like Heritage Restaurant Brands v. JT Investment Ventures in Q4 of 2024 have raised the stakes for digital agencies that fail to deliver accessible websites. Clients are now asking for accessibility assurances, and WCAG 2.2 AA is the baseline standard they expect.

For agencies, this shift is both a challenge and an opportunity. Strong accessibility practices aren’t just a risk management tool but rather a strong competitive differentiator when done properly. Agencies that invest in strong accessibility partnerships and testing can win new business and build deeper client trust. Learn more about how your digital agency can pick a strong Accessibility Partner in 2025.

3. Legal Pressure Continues to Drive Action

I would love to say that 2025 is the year when most companies prioritize accessibility solely because it’s the right thing to do. While that is certainly true, I believe that legal pressure and reactive accessibility will remain the primary drivers of digital accessibility for at least another year. Although industry articles and Google searches may suggest that web accessibility legal actions are declining, I find this impression somewhat misleading based on my direct experience and the efforts of Allyant’s Accessibility Claims Teams.

Ultimately, the number of demand letters vs. formal lawsuits has been rising over the past 12 months (a trend that I firmly believe continues), creating an illusion of reduced legal activity related to digital accessibility. However, I would warn your team not to be fooled as the pressure is as strong as ever, and now the number of global regulations that affect ALL verticals (EAA) is increasing.

4. State Accessibility Regulations Gain Momentum

I believe we will look back on Colorado’s HB-21 as the tip of the iceberg. By 2026, I anticipate more states will introduce accessibility legislation, especially on the heels of the noted Title II federal regulations that already mandate many state-funded entities. If I had to guess, based on reading the tea leaves, I anticipate five states (with as many as ten states) introducing some form of accessibility regulation akin to HB-21 by the end of 2025.

This trend indicates that accessibility strategies can no longer follow a one-size-fits-all approach. Specifically, companies selling to state-funded organizations must navigate varying state requirements while aligning with broader standards. This is why we continue to recommend testing to the latest standard, WCAG 2.2 AA. For organizations that embrace accessibility as a core value, this complexity can be transformed into an advantage, presenting a clear opportunity to lead the market and increase revenue in 2025 and beyond.

5. Increased Scrutiny of Mobile Accessibility

Mobile app accessibility has continued to gain focus as mission-critical for many organizations in the public sector. With the EAA regulations, I’m seeing a shift to the private sector as well.

The stats show that consumers interact with brands on mobile devices more than ever, and accessibility expectations are catching up. I predict heightened scrutiny of mobile apps, with audits expanding to include native iOS and Android experiences as part of digital accessibility roadmaps across many sectors.

Through partnerships like the Inclusive App Accelerator by ArcTouch, we’ve seen how intentional design and live-user testing can make or break mobile accessibility. Forward-thinking companies will prioritize accessible mobile experiences to stay competitive while following global regulations that will explicitly mandate this by mid-2025.

Final Thoughts

I have said this for nearly seven years now, but I’ll continue to double down year over year. Regardless of predictions, I’m positive that 2025 will remind us that accessibility is not a destination but a journey. Trends will shift, regulations will evolve, and the bar for inclusivity will continue to rise in 2025 and beyond.

The good news if your team is just getting started is that you don’t have to navigate this alone.

At Allyant, we’re here to help you stay ahead of the curve. Whether through strategic planning, legal and compliance support, training, or even document remediation, we have software and services that can be tailored to your exact requirements.

Here’s to making 2025 a year of progress, innovation, and inclusion!

The post Preparing for 2025: The Digital Accessibility Landscape first appeared on Allyant.

With the compliance deadline of June 2025 quickly approaching, businesses operating in the EU market face substantial risks if they fail to meet accessibility standards outlined in EN 301 549, a set of compliance guidelines derived from WCAG 2.1 AA.

The penalties for non-compliance with the EAA are a bit unique in that they are mandated by specific EU member states. Therefore, there is variance in the penalties, but it can include fines, market restrictions, and even criminal charges in severe cases.

Here are a few examples of noted penalties for non-compliance across a few member states:

• Germany: Fines can reach €50,000 for non-compliant products.
• Ireland: Directors of offending companies who persistently fail to comply may be sentenced to up to six months in prison.
• France: Products found non-compliant may be banned from the market outright, with daily fines for unresolved issues.
• Denmark: Non-compliance can result in fines calculated as a percentage of company revenue, ensuring significant financial impact.

These examples illustrate how enforcement under the EAA isn’t uniform; each member state enacts its own policies for compliance oversight and penalties. Naturally, this variability increases compliance complexity for businesses operating across multiple countries in the EU.

With less than six months to be in compliance, this article is meant to act as a proactive approach to help organizations mitigate legal and financial risks, build ongoing compliance resilience, and create conformant digital experiences.

1. Why the EAA Adds Legal Muscle to Accessibility

Unlike earlier regulation frameworks, the EAA integrates accessibility into consumer protection laws, holding organizations accountable for ensuring accessibility across digital and physical goods.

Compliance should not be viewed as optional for businesses operating in the EU or offering their products and services to consumers there. Starting in June of this year, it is a requirement for market entry and continued operation.

Key Enforcement Mechanisms

• Financial Penalties: As outlined above, these are designed to be substantial and increase for repeat offenses. Thus, they add real teeth to building and deploying inaccessible products. For example, Sweden calculates penalties based on company revenue (like Denmark), while Spain includes additional charges for causing consumer harm.
• Market Restrictions: Non-compliant products can be removed from sale or excluded from public tenders. This could become increasingly relevant in situations where a government contract, for example, could be revoked due to non-accessible software in Italy or France based on their member state enforcement policies.
• Litigation: Companies may face lawsuits from consumer advocacy groups, regulators, or individuals. This is similar to the practices we have seen in the U.S. for many years, with high-volume plaintiffs actively filing lawsuits and demanding letters claiming non-compliance with the ADA. It is not unrealistic to think this same practice might take the EU by storm under the clear-cut compliance requirements outlined by the EAA.

2. Common Risk Areas for Businesses Under the EAA

As has been seen in the U.S. for many years following legal action, compliance with WCAG and, therefore, EN 301 549 is not a box-checking exercise with an easy-button solution. Being accessible requires addressing nuanced challenges across digital operations, and businesses often stumble in the high-risk areas outlined below.

Incomplete Accessibility Implementation

Automated tools, while highly useful for scaling accessibility, only realistically detect about 30% of accessibility issues currently, leaving critical gaps unresolved.

• Example Issue: A dynamic content modal (popup) that is not announced to screen readers may pass automated checks but poses a significant usability barrier for an end-user with a vision disability who relies on screen reader assistive technology.
• Technical Insight: Use live-user testing to verify the accuracy of the ARIA role and ensure that modals are correctly labeled and that focus is appropriately returned to the triggering element after closing.

Untrained Development and Design Teams

Accessibility failures often stem from knowledge or process gaps in design and development workflows. Some examples of this could include:

• Navigation Structure: Designers inadvertently create complex navigation patterns without considering keyboard-only users who cannot operate a mouse to engage a hover-state menu.
• Interactive Elements: Developers deploy third-party widgets or plug-ins (such as sliders or date pickers) that do not meet WCAG compliance, creating compliance and usability gaps while also increasing the business’s legal risk.

Actionable Solutions for Compliance:

1. Perform a manual accessibility audit of key web or mobile user flows and components to provide real-world usability and technical feedback on compliance gaps that your team can then prioritize fixing.
2. Conduct role-specific accessibility training for designers, content creators, and developers to provide your team with the proper baseline knowledge of building and deploying accessible products.
3. Provide teams with access to Knowledge Articles (such as in our Allyant HUB) to act as a repository, for example, use cases and code snippets when building new features or content.

Outdated Procurement Processes

Under the EAA, organizations are directly responsible for ensuring compliance with third-party tools and services they use or deploy internally and externally.

• Example: A retail company procured a non-compliant website chatbot, leading to severe accessibility complaints and requiring the deployment of a new solution. (I would recommend considering Olark!)

Steps to Mitigate Procurement Risk:

I will outline a few key steps below, but I would also recommend this recent article, in which I provide highly detailed best practices for evaluating technology for accessibility in procurement!

1. Request updated VPAT ACRs that explicitly align with EN 301 549 from all vendors – new and existing to at least document some level of compliance review.
2. Conduct lightweight manual accessibility testing on vendor-supplied demos while in procurement or the software you have currently deployed, verifying at minimum in a baseline review:

• Keyboard-only operability.
• Screen reader functionality across major assistive technologies (e.g., NVDA, JAWS, VoiceOver).

1. 3. Establish contractual clauses holding vendors accountable for maintaining compliance with periodic reviews. This should come as no surprise to vendors with the EAA-specific mandates and legal requirements for your business going forward.

3. Building a Roadmap to Avoid Penalties and Ensure Resilience

Compliance isn’t about meeting a deadline but building sustainable processes that adapt to evolving standards. Here’s a structured approach:

Step 1: Conduct In-Depth Accessibility Audits

Comprehensive audits form the foundation of an effective compliance strategy by providing your team with a tangible health assessment of where you stand today and what needs to be improved to meet the WCAG requirements outlined in EN 301 549.

Key Areas to Focus On:

• Digital Properties: Evaluate all websites and mobile apps your team manages and deploys to consumers and the software you provide to organizations or procure as a purchaser. This should be certain to include and document manual live-user testing, so you are testing to the full WCAG success criteria, as well as specifically document testing by people with disabilities to build out your risk mitigation strategy.
• Critical User Journeys: You cannot test every page of a website or application completely, nor is that necessary in today’s software development landscape. Focus on identifying high-traffic user paths (such as purchasing) along with essential templates and components that are replicated throughout your website or application. This includes areas like payment pages, forms, and navigation elements, ensuring they comply with WCAG 2.2 AA.
• Hardware-Software Integration: If applicable, test the accessibility of devices like kiosks or ATMs to confirm compliance with both EN 301 549 and device-specific standards.

Advanced Practice: Use trend-based reporting to visualize progress over time, helping teams stay on track with remediation goals and build out an active risk mitigation strategy. We provide this reporting and key prioritization metrics in our Allyant HUB.

We would be happy to provide a demo to your team on how this would immediately roadmap accessibility compliance with the EAA for your websites and applications!

Step 2: Monitor and Adapt Compliance Efforts

Compliance is an ongoing effort, and accessibility is a journey, not a destination, for any organization or digital product. This is increasingly relevant with global regulations being released consistently, sometimes with nuanced requirements for compliance.

To ensure that your team is constantly monitoring for accessibility and maintaining ongoing compliance with the European Accessibility, your accessibility roadmap should include:

1. Regular Testing: Schedule maintenance audits of core user paths and components at a minimum annually following QA testing of your remediation efforts to ensure ongoing compliance. We also strongly recommend focused accessibility testing for every product or feature update; this way, your team is embedding accessibility testing and real-time remediation into your design and development workflows rather than deploying inaccessible technology.
2. Stay Informed: Partner with experts to monitor regulatory updates and prepare for future requirements. At Allyant, we also strongly encourage our clients to attend our ongoing webinars, read our weekly articles, and follow us on LinkedIn to stay updated with key industry updates.
3. Iterative Improvements: Use feedback loops to capture and address user pain points in real time. I strongly recommend this be done with your consumers and your employees who may struggle with accessibility access and directly impact their ability to perform their roles effectively!

Act Now to Secure Your EAA Compliance

The June 2025 deadline is a critical milestone for digital accessibility – not only for EU companies but also for those across the globe and the U.S. conducting business in Europe. Businesses that start early and build a robust accessibility roadmap with ongoing compliance metrics and policies will reap long-term rewards.

Allyant provides the expertise, tools, and support to guide you through compliance challenges, helping you avoid penalties while building more inclusive experiences.

If your organization needs help with where to start on your journey to EAA Compliance or is looking for a more robust solution to ensure well-documented compliance, contact our team today!

The post Navigating the European Accessibility Act: How to Avoid Penalties and Stay Compliant first appeared on Allyant.

For companies selling products and services in the EU, the stakes are high—not just to meet the legal requirements but to remain competitive in a market that increasingly prioritizes inclusivity.

The goal of this guide is to help you navigate the path to EAA compliance with detailed, actionable insights focusing on real-world lessons we have learned from years of front-line experience helping organizations tackle accessibility at scale.

Understanding EN 301 549 and Its Relationship to WCAG 2.2

At the heart of the EAA lies the European standard EN 301 549. Ultimately, this standard aims to harmonize the accessibility compliance of ICT (information and communication technologies).

Of note, it is unique to the commonly referenced Web Compliance standards built by the W3C, the Web Content Accessibility Guidelines (WCAG).

However, it is also not entirely unique. In fact, EN 301 549 draws from WCAG 2.1 AA but extends into other areas like software, hardware, and telecommunications devices.

With WCAG 2.2 officially adopted in October 2023, EN 301 549 is expected to eventually integrate key aspects of the updated guidelines, further tightening requirements and aligning the EAA standards with other global accessibility regulations.

How EN 301 549 Differs From WCAG

While WCAG focuses primarily on web content, EN 301 549 expands into broader areas that, in some cases, live far outside of website-specific content. These include:

• Hardware accessibility: Requirements for devices such as ATMs, ticketing machines, and mobile devices.
• Non-web software: Standards for desktop and mobile applications beyond web browsers.
• Telecommunications systems: Requirements to ensure accessibility in voice and text communication systems.

Client Use Case

A client we worked with—a global telecommunications provider—initially assumed their WCAG 2.1 compliance efforts for their mobile app were sufficient. However, EN 301 549 introduced additional criteria, such as requirements for alternative input methods and real-time text communication, which could have been overlooked by a strict adherence to WCAG 2.1 AA, which is required under many U.S. and Canadian accessibility regulations. By auditing their software against EN 301 549 and WCAG 2.2 AA, we identified gaps that could have otherwise led to non-compliance specifically relating to the EAA.

Why WCAG 2.2 AA is Globally Relevant

Throughout 2024, WCAG 2.2 AA has slowly become the de facto global accessibility testing standard.

Even with countries like the U.S. and Canada releasing accessibility regulations that point to WCAG 2.1 AA, many enterprise organizations and product teams aim to harmonize their global accessibility efforts and future-proof their products and testing results against the most up-to-date standards for accessibility.

Additionally, on the legal front, most of the high-volume plaintiffs filing demand letters and lawsuits in the U.S. – including against EU-based brands offering their products to the U.S. market – are now referencing WCAG 2.2 AA as a requirement in settlement agreements.

The updated success criteria released in WCAG 2.2 emphasize usability improvements for people with cognitive and motor disabilities. These include new success criteria such as:

• Focus appearance (2.4.11): Ensuring focus indicators are visible for keyboard users.
• Drag-and-drop functionality (2.5.7): Providing alternative methods for users unable to perform drag-and-drop actions.

As an organization supporting a large number of clients worldwide, our team at Allyant recommends that organizations adopt WCAG 2.2 AA universally—not only to meet current regulations but also to future-proof their digital properties against emerging standards like EN 301 549.

Additionally, I have heard from global leaders at various conferences throughout 2024 that part of ‘harmonizing’ the regulations and making it more streamlined for organizations deploying their products across global markets is that the EU regulations could adopt WCAG 2.2 AA as the standard in the not-so-distant future.

Within our Allyant HUB Platform and testing results, we allow your team to quickly filter on various WCAG standards (such as 2.0 vs. 2.1 vs. 2.2), allowing your team to have a full view of all accessibility requirements while still prioritizing the issues in your remediation workflows that are most applicable to the markets and vertical you operate in.

Conducting an Accessibility Audit of Your Digital Ecosystem

A thorough accessibility audit is the cornerstone of any EAA compliance effort. This audit evaluates your websites, mobile applications, digital documents and PDFs, software (including those you procure from a third party!), and other digital assets against EN 301 549.

Short-Term Action Items

Audit Your Digital Products

The first step in building an accessibility roadmap is generally understanding where your products stand against EN 301 459 and WCAG 2.2 AA. The most effective way to grasp this understanding is what I’ve long coined as a “health assessment” (audit) of your website(s), consumer-facing mobile applications, or other digital assets, such as PDFs, that are used to interact with your EU-based customers.

Prioritize Critical Accessibility Gaps

Once you have assessed your products against relevant accessibility standards, the next step is building out a roadmap for tackling remediation. In full transparency, especially on large websites or applications, this will not happen overnight. This is where focusing on high-impact accessibility issues that affect critical user journeys, such as checkout flows or product navigation, becomes extremely important for building ‘quick wins’ among your team and scaling product accessibility as quickly as possible.

When our team delivers auditing results to our clients, we provide two key indicators that help drive efficient remediation planning.

The first is a flag for sitewide accessibility issues that will allow you to make a singular or set of fixes to resolve an accessibility issue across all pages or views of your website/mobile application – such as a Skip to Main Content or issues in your base Menu Navigation.

Second, we provide a “Priority Level” from 1 to 3 for every barrier identified in the testing process. A Priority Level 1 issue, for example, is a complete blocker of a user leveraging assistive technology and would totally prohibit that user from engaging with your brand or product.

This allows your team to focus on fixing the most critical barriers first and move through prioritized issues in a more agile remediation process.

Client Use Case

A global e-commerce retailer came to Allyant with concerns about their European market presence with the pending June 2025 deadline. Our live-user web accessibility audit uncovered several critical issues, including unlabelled buttons on their PDP pages, inaccessible form labels, and an inability for screen reader users to interact with their hover menu throughout the website and checkout process. Focusing on the remediation of the most critical issues not only put them on a path to compliance with the EAA ahead of regulatory deadlines but also opened them up to a potential 15% increase in new customers. This is based on data from the EU-SILC that recently found 15-20% of the population in the EU lives with a disability – a percentage that represents 100 million people!

Embedding Accessibility into Design and Development

Building accessibility into digital products after the design and development phase can be far more expensive. Research our team has done with client projects shows that there can be upwards of a 30% reduction in development cost for accessibility in an accessibility-first design and development process. This does not even factor the downstream effects of the shorter timeline to compliance!

To realize these efficiencies, accessibility must be integrated into every stage of your design and development processes.

Tips for Building an Accessibility-First Mindset:

• One of the strongest practices your team can implement is focused reviews during the Design Phase of projects rather than waiting until the development process and/or after the product is built and put into the market. Allyant offers this for design teams, helping them build accessibility annotations into their design files, discuss design improvements in real time, and bridge the gap between design and development teams.
• Train both design and development teams on the baseline requirements and best practices for building with accessibility and WCAG conformance in mind. Our team offers live, recorded accessibility training tracks for both Designers and Developers to ensure this can become part of your team’s core skillset and also be leveraged as part of employee onboarding for these roles!
• Conduct ongoing usability testing with assistive technology users! This will give your team real-time feedback on the initial state of the products you are building and garner consistent feedback on new features or functions added to websites or applications, helping you maintain accessibility conformance.

Inventory your Digital Documents & PDF Files

The European Accessibility Act (EAA) strongly emphasizes document accessibility. It requires that all digital documents posted or sent after June 28, 2025, comply with accessibility standards.

For businesses operating in or serving the EU, this means now is the time to assess their existing document inventory, evaluate compliance gaps, and implement a structured approach to accessibility remediation.

Without a proactive strategy, organizations risk failing to meet these critical requirements, exposing themselves to penalties, lost business opportunities, and reputational harm.

Easily Inventory Your Document’s Accessibility

Conducting a comprehensive inventory of your PDF and digital documents is the first step toward compliance. With Allyant’s CommonLook Clarity testing tool, organizations can evaluate document accessibility at scale, quickly identifying inaccessible files and prioritizing them for remediation. This ensures your compliance efforts are targeted, efficient, and aligned with the most heavily utilized or customer-facing content. CommonLook Clarity provides an unmatched ability to analyze large document libraries, empowering teams to understand the full scope of work required for accessibility compliance.

Moving from Assessment to Action

Once the assessment is complete, organizations must prioritize the remediation of high-impact documents, focusing on those most frequently accessed by customers, employees, or stakeholders. Allyant’s PDF Accessibility Assessment & Remediation services streamline this process, delivering fully accessible documents with a 100% guarantee that meet global accessibility standards, including WCAG 2.2 and EN 301 549. Our expert-led team ensures compliance while maintaining the integrity and layout of original content, providing organizations with peace of mind and the ability to meet tight deadlines.

Proactive Planning for EAA Compliance

The EAA deadline may seem distant, but the volume of work required to achieve compliance—especially for organizations with large document repositories—makes early action critical. Partnering with Allyant ensures you have the tools, expertise, and processes needed to achieve compliance while minimizing disruption. By leveraging CommonLook Clarity, targeted remediation efforts, and a proven track record of success, Allyant positions your organization to meet the June 2025 requirements with confidence.

Client Use Case

A leading financial institution in North America faced significant challenges in preparing for global accessibility regulations, including the EAA. With a vast repository of legacy documents and the need for ongoing remediation of customer-facing statements, it turned to Allyant for a comprehensive solution. Allyant deployed CommonLook Clarity to assess the accessibility of its document library and identified high-priority files for remediation.

Using the data-driven insights from Clarity, our team worked alongside the client to remediate their most heavily used documents, ensuring compliance across critical customer-facing materials.

In parallel, Allyant established a high-volume remediation process for recurring statements and documents, delivering accessible outputs in alignment with the institution’s branding, communication standards, and client expectations.

This approach enabled the client to achieve compliance with the ADA and AODA and positioned them to comply with other global regulations (such as the EAA) through a highly scalable process for future document management needs.

Accessibility in Procurement: Leveraging VPAT ACRs

One of the most significant impacts of the EAA is the emphasis on accessibility in procurement, with the focus on regulations expanding outside of websites or web content specifically.

Public and private organizations in the EU, similar to growing trends we have seen in the U.S. with the release of updated Title II and HHS regulations, must now ensure that vendors they are selecting to deploy third-party software, and applications are working to comply with EN 301 549 standards.

This has placed VPAT ACRs (Voluntary Product Accessibility Templates) at the forefront of procurement discussions.

Why VPAT ACRs Matter

A well-crafted VPAT ACR is more than a compliance document—it’s a necessary sales tool for vendors and should act as a clear roadmap to a product’s ongoing accessibility effort. However, inaccuracies or outdated information can lead to disqualification or even legal risk. Earlier this year, I wrote about this topic in detail, including how to ensure VPAT ACRs are more than just a procurement checkbox, which you can find here.

Client Use Case

A SaaS provider in the education sector partnered with Allyant after the threat of losing a very large state education client due to not having an up-to-date VPAT ACR for their product. By leveraging our live-user testing process to focus on key product components and the most heavily trafficked product workflows with results deploying in our HUB platform, they received a live, interactive VPAT ACR that not only met Title II and Section 508 requirements but also provided procurement teams with detailed remediation timelines and project roadmaps. This ensured they not only retained their large state education client but 12 months later, they have turned this into a tool to win more business by proactively outlining their accessibility progress and commitment.

This same process is starting to become more prominent in the EU, and we are seeing many EU and U.S.-based software vendors frantically looking to deploy an accessibility process.

Ultimately, large EU-based organizations are beginning to “check” with existing vendors about their product accessibility, ask for a VPAT ACR, and gain a better understanding of their accessibility-focused product roadmaps as the deadline for EAA compliance nears.

Get started on EAA Compliance!

EAA compliance isn’t just a legal obligation—it’s an opportunity to deliver better experiences to all users. By understanding EN 301 549, conducting thorough audits, and embedding accessibility into your processes, you can meet the 2025 deadline while positioning your brand as a leader in inclusivity.

Allyant’s global expertise in live-user testing, compliance strategy, and holistic document accessibility support can get your team started on building your path to EAA compliance. Reach out to our team to speak with our expert consultants on getting started!

The post EAA Compliance Checklist: Key Steps to Meeting 2025 Accessibility Requirements first appeared on Allyant.

The Web Content Accessibility Guidelines (WCAG) have long served as the global benchmark for digital accessibility. Yet, one of the most common questions I hear day in and day out from prospective clients looking to kick off a roadmap to digital accessibility conformance is, “What standard should we comply with?

Can we just be A compliant to start?” – so let’s break down those questions!

With the release of WCAG 2.2 in October of 2023, organizations must understand the nuances between WCAG 2.0, 2.1, and 2.2 and why aiming for WCAG 2.2 AA conformance is the most robust strategy for futureproofing your digital properties.

In this article, I will discuss the specifics of WCAG conformance levels, dispel common misconceptions, and explain why WCAG 2.2 AA should be the target for your web and mobile accessibility initiatives.

Understanding WCAG Conformance Levels: 2.0, 2.1, and 2.2

WCAG 2.0, released in 2008, laid the foundation for digital accessibility. It was the first comprehensive set of guidelines and also busted the most common myth that web accessibility guidelines are “new.” WCAG 2.1, released in 2018, built upon this foundation, introducing new success criteria that addressed the evolving needs of users with disabilities, particularly in mobile and touch-based environments. WCAG 2.2 takes this a step further, adding more success criteria that enhance accessibility for people with cognitive and learning disabilities, among others.

Key Differences and Additions in WCAG 2.2:

• Focus on Cognitive Accessibility: WCAG 2.2 introduces new success criteria aimed at improving the web experience for users with cognitive and learning disabilities. For example, Success Criterion 2.4.11 (Focus Appearance) and 3.3.7 (Redundant Entry) are designed to make web navigation and form filling easier and more intuitive.
• Enhanced Mobile Accessibility: Building on WCAG 2.1’s emphasis on mobile, WCAG 2.2 adds further requirements that ensure better usability on touch devices, such as Success Criterion 2.5.7 (Dragging Movements).
• WCAG 2.2 Webinar: For a full and thorough breakdown of WCAG 2.2, check a full and thorough breakdown of this topic!

Why aim for WCAG 2.2 Conformance?

WCAG 2.2 represents the most current iteration of the Web Content Accessibility Guidelines, reflecting the latest insights into user needs and the evolving landscape of technology. As digital environments continue to advance, so must the standards governing accessibility. WCAG 2.2 is not just an incremental update but a significant enhancement designed to ensure that web content remains accessible to the broadest possible audience, including those with cognitive, learning, and physical disabilities.

Addressing the Latest User Needs

The primary goal of WCAG 2.2 is to close existing gaps in accessibility, particularly for users who were not fully addressed by earlier versions. While WCAG 2.0 and 2.1 laid a solid foundation, WCAG 2.2 introduces new success criteria specifically designed to meet the needs of individuals with cognitive and learning disabilities, as well as those who rely on touch and mobile devices.

Keeping Pace with Technological Developments

The digital world is rapidly evolving, with new technologies and design practices emerging regularly. WCAG 2.2 is designed to keep pace with these changes, ensuring that accessibility standards remain relevant and effective in the face of technological advancement.

Futureproofing Your Accessibility Efforts:

• Responsive Design: As websites and applications increasingly adopt responsive design principles to accommodate various screen sizes and devices, WCAG 2.2 includes criteria that ensure these designs remain accessible. For example, the new guidelines address the needs of users interacting with content on small screens or using touch inputs, ensuring that modern design trends do not compromise accessibility.
• Emerging Technologies: WCAG 2.2 also considers the accessibility implications of emerging technologies such as virtual reality (VR) and augmented reality (AR). While these technologies are still developing, the principles outlined in WCAG 2.2 can be applied to ensure these new digital environments are accessible from the outset.

Adapting to User Behavior:

• Increased Mobile Usage: With the growing reliance on mobile devices for accessing web content, WCAG 2.2 emphasizes mobile accessibility, ensuring that users with disabilities can effectively interact with content on smartphones and tablets. This includes considerations for touch targets, gesture navigation, and content layout on smaller screens.
• Personalization and AI: As digital experiences become more personalized through the use of AI and machine learning, WCAG 2.2 provides a framework for ensuring that they remain accessible. For example, criteria that ensure consistent and predictable navigation are essential as websites and applications become more dynamic and personalized.

The Myth of WCAG A Conformance: Why It’s Not Enough

While WCAG A conformance addresses some fundamental accessibility barriers, it fails to ensure a fully accessible and user-friendly experience for all individuals. This is particularly true for individuals with specific disabilities, which is the overarching goal within the depth of the WCAG success criteria.

WCAG AA conformance builds on A by adding more stringent requirements that enhance usability and accessibility across a wider range of scenarios. Here are some concrete examples that highlight the difference between A and AA conformance and also help explain why aiming for just A conformance should not even be within your team’s consideration:

Color Contrast (1.4.3)

• WCAG A: At the A level, WCAG requires a minimum contrast ratio of 3:1 for text or images of text against their background for large-scale text (18pt or 14pt bold) and graphical elements. However, this ratio may still pose challenges for users with low vision, especially in cases where smaller text or complex backgrounds are involved.
• WCAG AA: AA conformance raises the minimum contrast ratio requirement to 4.5:1 for regular text and 3:1 for large-scale text. This higher contrast ratio significantly improves readability for users with visual impairments, particularly those with conditions such as cataracts, glaucoma, or age-related macular degeneration. For example, text on a light grey background might be readable to some users at A conformance, but increasing the contrast as required by AA ensures that more users can distinguish the text clearly, even under poor lighting conditions or on low-quality screens.

Focus Visible (2.4.7):

• WCAG A: A conformance does not mandate visible focus indicators, which can result in users who rely on keyboard navigation (such as those with motor impairments) being unable to discern which element is currently focused. This omission can cause confusion, as users may lose track of their place within a page, leading to frustration and reduced usability.
• WCAG AA: AA conformance ensures that focus indicators are clearly visible when navigating through a webpage using the keyboard. For example, when a user tabs through a form, AA conformance would require that each form field’s border or background color changes distinctly, making it immediately obvious which field is active. This not only helps users with motor disabilities but also benefits users with cognitive disabilities, who may rely on clear visual cues to understand where they are within a page. This is also a prime example of why teams should view A and AA conformance as a single, unified standard. Without complying to WCAG 2.4.7, you’re team can leave a wide array of users with disabilities with little to no access to your website.

The Challenges of WCAG AAA Conformance: Why It’s Often Unrealistic

While WCAG AAA conformance represents the highest level of accessibility, it is rarely the target for organizations due to the stringent and often impractical nature of its success criteria.

Technical Specifics:

• Success Criterion 1.2.9 (Audio Description (Extended)): Requires extended audio descriptions for all prerecorded video content. While this enhances accessibility for users who are blind, it can be challenging to implement across all content due to the significant time and resource investment required.
• Success Criterion 1.4.8 (Visual Presentation): Demands more advanced control over the visual presentation of text, such as line spacing and justification, which can be difficult to achieve consistently across all devices and platforms.

Why AAA is Not the Legal Requirement

At the time of writing, global regulations do not currently mandate AAA conformance, nor do any legal settlements. However, most legal standards, such as the recently formalized DOJ (Title II) and HHS accessibility regulations in the US or EN 301 549 under the European Accessibility Act, require AA conformance. AAA conformance is considered aspirational rather than a practical legal requirement for almost all organizations.

Why WCAG 2.2 AA Should Be Your Target

Given the limitations of A conformance and the impracticality of AAA as defined in detail above, WCAG 2.2 AA conformance represents the ideal balance. It addresses the most critical accessibility and usability barriers while remaining both highly achievable and sustainable. For organizations looking to create inclusive digital experiences, WCAG 2.2 AA is the standard that ensures a comprehensive and lasting impact.

Legal Standards and Maximizing Your Accessibility Investment

Current Legal Requirements

Many existing regulations, such as the DOJ’s Title II and HHS regulations in the US, as well as EN 301 549, which sets the standards for compliance with the European Accessibility Act and was recently adopted as the standard in Canada, currently point to WCAG 2.1 AA conformance as the legal standard.

However, aiming for, or at minimum testing against, WCAG 2.2 AA conformance offers a strategic advantage. As accessibility standards evolve, legal requirements will likely eventually incorporate or reference WCAG 2.2, just as they previously shifted from WCAG 2.0 to 2.1.

By aligning with WCAG 2.2 now, organizations can stay ahead of regulatory changes, ensuring that their digital properties remain compliant as the legal landscape evolves. This proactive approach not only helps to mitigate future legal risks but also demonstrates a commitment to accessibility and inclusivity.

Maximizing Return on Investment

Auditing and building to WCAG 2.2 AA conformance ensures that your digital properties are equipped to handle both current and future accessibility needs. This strategy provides a full return on investment by incorporating the most up-to-date accessibility feedback from the outset. Here’s why:

• Alignment with Future Roadmaps: By conforming to WCAG 2.2 AA, your organization ensures that any future updates or enhancements to your web and mobile platforms will be built on a foundation that already meets the highest current accessibility standards. This reduces the need for costly rework or additional audits as accessibility requirements evolve, allowing your team to focus on innovation rather than retrofitting accessibility into existing structures.
• Proactive Compliance: Should WCAG 2.2 become the legally mandated standard or an internal roadmap goal, having already conformed to WCAG 2.2 AA ensures that your organization is not caught off guard. Instead, you’re prepared to adapt to new requirements without significant disruptions to your development pipeline or additional expenses. This is particularly important as digital platforms become more dynamic, with continuous updates and new features that must be accessible from day one. Additionally, as outlined above, WCAG 2.2 aims to provide more robust usability in a mobile-first environment, a key focus for many organizations.
• Empowering Development Teams: When your organization commits to WCAG 2.2 AA, it empowers your development and design teams to build with a clear understanding of the latest accessibility standards—even if you only remediate your existing digital properties to WCAG 2.1 AA out of the gate. This awareness fosters a culture of accessibility, where teams continually consider maintaining and enhancing accessibility as they create new content, features, or products. This ongoing commitment to accessibility ensures that your digital properties remain usable and inclusive as they grow and evolve.
• Enhanced User Experience: By aiming for WCAG 2.2 AA, you’re not just meeting a legal standard—you’re creating a better experience for all users. The enhancements in WCAG 2.2, such as improved focus indicators, better color contrast, and easier navigation for users with cognitive disabilities, contribute to a more inclusive and user-friendly experience. This can increase user satisfaction, engagement, and, ultimately, better business outcomes.

Ultimately, WCAG 2.2 AA conformance represents a smart investment in the long-term accessibility and usability of your digital properties. By adopting these standards now, your organization is not only meeting the most up-to-date accessibility guidelines but also ensuring that your digital properties are ready for whatever the future holds. This approach maximizes your return on your accessibility investment by reducing future costs and enhancing the overall user experience.

Allyant’s Approach: WCAG 2.2 AA is our Client Commitment

At Allyant, we recognize the importance of aligning with the most up-to-date standards. That’s why all of our live-user accessibility audits of websites, software, or mobile applications, as well as QA assessments and monitoring re-assessments, are conducted to WCAG 2.2 AA. This commitment extends to our PDF remediation services, ensuring all digital documents conform to the latest accessibility standards.

Why Choose Allyant for your Path to WCAG 2.2 AA Conformance?

• Comprehensive Filtering Capabilities: Our HUB platform allows organizations to filter all testing results by relevant standards, such as WCAG 2.1 AA, while mapping out a roadmap to achieve WCAG 2.2 AA. This flexibility ensures that your accessibility efforts align with current legal requirements and future goals specific to your organization. For example, you may be a healthcare organization that needs to ensure compliance with the new HHS regulations in less than 2 years. These regulations require WCAG 2.1 AA conformance, but should other regulations or legal requirements point to WCAG 2.2 success criteria, or you simply want to provide a more usable and accessible experience to all, your team will have those issues at the ready anytime!
• Live-User Testing: All our assessments include live-user testing by people with disabilities, ensuring that real-world accessibility and usability issues are identified and addressed. This approach is crucial as we now see lawsuits and demand letters referencing WCAG 2.2, highlighting the need for thorough, up-to-date audits.

Conclusion: Aim High, Protect Your Investment, and Stay Ahead

Every organization’s accessibility strategy should aim for WCAG 2.2 AA conformance. This standard offers the most comprehensive protection against legal risks and ensures that your digital properties are accessible to all users. With Allyant’s expertise and tools, achieving and maintaining WCAG 2.2 AA conformance is feasible and a wise investment in your organization’s future.

For more information on how Allyant can help you achieve WCAG 2.2 AA conformance, explore our robust services and learn more about our industry-first Accessibility Claims Team that drives further investment protection for your accessibility budget.

The post From WCAG 2.1 to 2.2: Why AA Conformance is the Optimal Accessibility Goal first appeared on Allyant.

Mobile application accessibility isn’t that unlike web accessibility. It extends the boundaries of the term ‘digital accessibility.’ Ultimately, mobile application accessibility ensures that individuals with disabilities can fully access and interact with mobile applications they would install natively on their devices.

To garner context, we can all assess our own mobile device usage—you might even be reading this blog through a mobile browser!

Now, think about the mobile applications you use daily rather than going to your browser like you would on a laptop or desktop computer. Perhaps you regularly use a banking application to pay your bills, one of those non GamStop casinos to unwind in the evening, a weather app to make your plans for a weekend adventure or a music app to turn on your favorite songs while you relax.

Most of us use an endless number of mobile applications via our personal devices daily rather than relying on opening up our laptops to perform routine tasks.

But what if these applications are not accessible for people with disabilities who might need them as much as anyone to efficiently and effectively engage with vendors, travel, or order food?

Like website accessibility, mobile application accessibility refers to making native applications compatible with assistive technologies like screen readers (e.g., VoiceOver for iOS and TalkBack for Android in this context) and ensuring the app’s design, navigation, and functionality are user-friendly for all.

Accessibility in this context goes beyond compliance with guidelines like WCAG; it includes a focus on usability, ensuring that everyone can effectively perform critical tasks within the app, regardless of ability.

WCAG and Mobile Application Accessibility: Understanding WCAG in the Mobile Context

The Web Content Accessibility Guidelines (WCAG) are the globally recognized standard for web accessibility, and they have extended relevance to mobile applications.

Even though WCAG was originally intended for web content, its principles also apply to the mobile app environment. WCAG 2.1 (released in 2018) and 2.2 (released in 2023) build upon WCAG 2.0, and one of their main goals was to introduce success criteria that are particularly pertinent to mobile devices that were far less heavily used when WCAG 2.0 was released in 2008.

This naturally makes them the go-to frameworks for assessing mobile app accessibility in the current state of regulations, which we will outline further below.

WCAG 2.1 and 2.2: Key Success Criteria for Mobile Applications

WCAG 2.1 brought forward mobile-specific success criteria, recognizing the unique aspects of mobile devices. Here are a few specific examples:

• 1.3.4 Orientation (AA): This criterion requires that apps not restrict their functionality to a single-screen orientation. A map application, for instance, must work equally well whether a user holds their device in landscape or portrait mode, which is especially important for users who mount their device in fixed positions (such as in a wheelchair).
• 2.5.1 Pointer Gestures (A): Mobile apps often rely on complex gestures, such as swiping or pinching. However, this success criterion mandates that all functionality, such as zooming into a product catalog or adjusting a timeline in a media app, be operable with a single pointer. This ensures that users with limited motor skills can still navigate and operate the app without requiring complex multi-touch gestures that may not be possible.

WCAG 2.2 builds on WCAG 2.0 and 2.1 requirements by adding more precise criteria, further enhancing mobile accessibility. There is one specific success criterion that pertains heavily to mobile devices and applications:

• 2.5.7 Dragging Movements (AA): Dragging elements (e.g., dragging files between folders in a mobile file manager) must be operable without requiring the drag-and-drop motion, making these functions usable by individuals who may have difficulty with fine motor skills.

Why WCAG Alone Isn’t Enough for Mobile Applications

While WCAG lays a solid foundation, mobile applications require additional expertise to ensure they are not only legally conformant with accessibility standards globally but also usable for people with disabilities.

For example, mobile devices rely on gestures (pinch, swipe, tap, drag), custom controls, and unique navigation paradigms that WCAG does not fully address.

Of course, the “W” in WCAG refers to “Web,” there are currently no mobile-specific accessibility guidelines that are leveraged at scale or referenced in global regulations. However, the W3C has engaged a Mobile Accessibility Task Force to articulate how WCAG can be applied to mobile applications more effectively.

In the broader context of WCAG, building accessibility into a mobile app that is both compliant and usable requires more than just ticking boxes on a checklist such as WCAG 2.2; it requires careful testing and evaluation by experts who understand how people with different disabilities use mobile technology in the real world.

This is why Allyant maintains a specialized mobile application auditing team. Our experts go beyond mere compliance, conducting thorough evaluations that consider real-world usage scenarios and leveraging their extensive knowledge to identify and mitigate accessibility barriers.

This includes applying the WCAG success criteria by considering how a user with a disability uses a mobile application in a real-world environment and meaningfully applying these success criteria to ensure mobile developers and designers can effectively remediate issues within their applications.

Partnering for Success

Another thing I always stress to clients is ensuring your team is working with third-party mobile development firms that prioritize accessibility through your application build and ongoing lifecycle.

One of the highest accessibility expenses an organization can incur is when they build websites or applications without any consideration for accessibility.

Therefore, when accessibility testing is eventually done, the organization assumes the expense of retrofitting accessibility fixes into an already built application, which in some cases can be difficult, if not impossible, without full feature rewrites—snowballing the cost of accessibility very quickly.

Collaborating with a mobile app development company that prioritizes accessibility through the entire product lifecycles, such as our partner agency ArcTouch, is essential. ArcTouch, for example, prioritizes accessibility in every development phase, from initial design to ongoing updates.

They integrate accessibility considerations into their workflows, ensuring that features are tested with live users from our team and that accessibility is maintained throughout the app’s lifecycle.

This partnership ensures that your mobile application meets WCAG standards and delivers an exceptional user experience for all.

It also saves your organization significant time and resources in building accessibility requirements into your native applications!

Legal Requirements: Does Your Mobile Application Need to Be Accessible?

The legal requirements for mobile accessibility vary across industries and geographical regions. Here’s a deeper dive into the different scenarios where mobile application accessibility is legally required so your organization can.

1. Public Entities and Government Agencies (Title II of the ADA)

If you are a public entity or government agency—yes—your mobile applications need to be accessible with WCAG 2.1 AA.

Public entities, such as state and local governments, are required to make their mobile applications accessible under Title II of the ADA following updated regulations released by the DOJ in April 2024. This includes apps that provide essential public services or communication platforms.

Specific Examples:

• City and Municipal Services: City or County government apps that allow residents to report issues like potholes in roads or pay utility bills must be accessible. For instance, an app used by residents to pay parking tickets or apply for city permits should allow users to navigate via screen readers or other assistive technology.
• Public Transportation: Apps used to book paratransit services or provide real-time schedules for city buses and trains need to be accessible to individuals who are blind, deaf, or have limited mobility. For example, the NYC MTA app, which allows real-time tracking of buses and subways, must ensure that users with disabilities can fully access schedule information and map features.

The Department of Justice (DOJ) has made it clear that any digital content provided by public entities—including mobile apps—must be accessible to WCAG 2.1 AA.

2. Healthcare Organizations (HHS Accessibility Regulations)

If you are a healthcare organization that accepts Medicare or Medicaid—yes—your mobile applications need to be accessible with WCAG 2.1 AA.

Healthcare providers and insurers that use mobile applications for patient interactions are also required to comply with accessibility laws under the Department of Health and Human Services (HHS) that were released in May 2024. These regulations ensure that patients with disabilities can access healthcare services and information via mobile apps.

Specific Examples:

• Patient Portals: A healthcare provider’s mobile app that allows patients to view their medical history, access lab results, or schedule appointments must be fully accessible. Apps like MyChart, which are used widely in healthcare systems, must ensure that all users can easily navigate their medical data using screen readers or other assistive technologies.
• Telehealth Services: With the rise of telemedicine, mobile apps used for virtual doctor appointments must be accessible. This includes ensuring that users can navigate menus, complete registration, and communicate with providers using both voice and visual cues.

The HHS enforces strict regulations, ensuring healthcare-related apps are accessible according to WCAG 2.1 AA by May 11. 2026. A hospital or other healthcare provider’s failure to make their patient communication or services apps accessible could result in a federal complaint or legal action under Section 504 of the Rehabilitation Act.

3. European Union and the European Accessibility Act (EAA)

If your organization is based in the EU or offers mobile applications to consumers in Europe—yes—your mobile application is required to conform to the WCAG Success Criteria.

If your organization is based in the EU or offers mobile applications to EU consumers, you must comply with the European Accessibility Act (EAA). The EAA requires that mobile apps, websites, and other digital services be accessible to all users, including those with disabilities, by late June 2025.

Specific Examples:

• E-Commerce Platforms: A European e-commerce company offering a mobile app for online shopping must ensure that individuals with disabilities can navigate the app, browse products, and complete purchases. For instance, a Clothing Retailer with a mobile app allowing consumers in Europe to shop the brand’s products is required to ensure that all shopping and checkout features are accessible via screen readers and offer alternatives for touch-based gestures.
• Banking and Financial Services: Mobile banking apps used by EU customers must comply with the EAA. Users should be able to transfer money, view statements, and access financial tools regardless of disability. This includes making features such as biometric logins (fingerprint or facial recognition) accessible.

Failure to comply with the EAA could result in legal penalties for companies operating within the EU.

4. Private Entities and B2C Applications

If you are a non-healthcare-based private entity in the U.S. that does not sell or ship to Europe, maybe your mobile applications need to be accessible with WCAG 2.1 or 2.2 AA.

Private companies offering consumer-facing mobile applications (B2C) may find themselves in a legal gray area, but staying proactive is important.

Although lawsuits specifically targeting mobile apps are still relatively uncommon, several have emerged throughout 2024. At least one high-volume plaintiff specifically targeted mobile applications that do not provide equitable access under the ADA (see Jahoda vs. Ralph Lauren Corporation—Case Number: 2:24cv1195).

These lawsuits and demand letters replicate the high-volume activity from several known plaintiffs targeting websites for lack of WCAG conformance. This trend may increase as mobile application requirements brought forth by the Title II and HHS regulations see their compliance timelines arrive in 2026.

Specific Examples:

• Retail & E-Commerce Apps: While not explicitly mandated, e-commerce apps are increasingly becoming the target of litigation as consumers with disabilities demand greater accessibility, like B2C websites. If your app serves a large audience, especially with complex functionalities like in-app purchases or dynamic product displays, it’s critical to ensure it is accessible to avoid future legal issues while expanding your consumer audience.
• Entertainment and Media Streaming: Mobile apps used for streaming media could also be at risk due to high volumes of users. While these apps are entertainment-focused, they often offer essential services to individuals with disabilities, such as closed captions or descriptive audio. They must ensure that all interfaces are navigable by screen readers.

Potential Legal Trends for 2025 and Beyond

While lawsuits targeting mobile applications are still rare compared to those filed against websites, there is growing scrutiny. As referenced, cases have emerged in which plaintiffs filed claims specifically related to inaccessible native mobile apps.

With Title II and HHS regulations explicitly requiring mobile app compliance, I anticipate a growing trend of litigation targeting inaccessible mobile applications over the next two years and beyond.

Furthermore, as more regulatory bodies explicitly mention mobile applications in their rules AND the use of mobile applications becomes more frequent by people living with disabilities, the legal landscape for mobile apps will almost certainly evolve. This will likely lead to more frequent litigation and more regulatory bodies requiring mobile application compliance by as early as 2025.

Like our recommendation for website accessibility, proactive measures in ensuring accessibility can help private entities avoid potential legal challenges and foster a more inclusive user base. Simply put, it is also the right thing to do and will open up your mobile application to a broader audience!

How Allyant Can Help: Bridging the Gap with Live-User Testing

At Allyant, we offer paired live-user testing. In this method, both blind and sighted mobile accessibility engineers collaborate to identify accessibility barriers and map out a clear path to remediate those issues for your team or development agency. This approach ensures that your app is tested in real-world conditions using native technologies like VoiceOver on iOS and TalkBack on Android.

Our Comprehensive Testing Approach Includes:

• Native Technology Utilization: We leverage built-in accessibility features such as VoiceOver for iOS and TalkBack for Android to simulate real user experiences. We identify not only WCAG violations within your application but also potential usability barriers for users with varying disabilities to ensure you are creating highly usable apps for all.
  • VoiceOver is the built-in Screen Reader installed on all iOS devices to provide spoken descriptions of on-screen elements, allowing users with visual impairments to navigate and interact with your native application app efficiently. Our testing ensures that all UI elements are properly labeled, and that navigation flows logically.
  • TalkBack offers similar functionality for Android devices, enabling users to receive auditory feedback and navigate the app using gestures. We ensure that all interactive elements are accessible and that the app responds appropriately to various user inputs.
• Paired Accessibility Testing: Our team includes both blind and sighted engineers who work in a “paired” audit process to uncover and address accessibility challenges from multiple perspectives. This paired process is the only real path to creating an equal user experience. For example, if a blind engineer worked solo, there could be various features or content hidden from a screen reader that they could not properly identify – leaving out a subset of your consumers altogether.
• Real-World Scenario Testing: We conduct testing based on common user tasks and scenarios that users would engage within your specific mobile application to ensure that your app performs reliably and intuitively for all users.
• Agile Feedback Integration: Insights from live-user testing are seamlessly integrated into your development cycle (and JIRA instance if needed), ensuring continuous improvement and adherence to accessibility standards both post-assessment and ongoing as you add or change features downstream

Strategically Deploying Your Accessibility Budget with Allyant:

The recent WebAIM Million Survey highlighted that over 90% of users with disabilities use mobile devices, emphasizing the critical need for mobile application accessibility beyond just the legal and regulatory requirements outlined in this article. At Allyant, we help clients strategically allocate their accessibility budget by focusing on efficiency in the scoping process:

• Critical Use Cases: Based on user needs and usage patterns, identify and prioritize the most impactful areas of your app that require accessibility enhancements.
• Framework Compatibility: Working with shared frameworks such as React Native ensures that accessibility features are consistently implemented across multiple platforms, optimizing resource allocation compared to “requiring” you to audit shared frameworks across both iOS and Android devices wherever possible.
• User-Centric Testing: Incorporating live-user testing ensures that your accessibility efforts are aligned with real-world user experiences, maximizing the effectiveness of your budget to solve the most critical access barriers preventing users from engaging with your brand and mobile applications.

Conclusion & Next Steps for Your Organization

In conclusion, ensuring that your mobile application is accessible and WCAG conformant is not just about compliance—it’s about creating an inclusive experience for all users regardless of their preferred digital path for engaging with your organization.

Whether you are bound by legal requirements or simply striving to provide the best possible user experience, Allyant is here to help you navigate the complexities of mobile app accessibility. Our expertise is focused on ensuring that your mobile application meets the highest standards of accessibility and usability.

For more information on how Allyant can assist you in making your mobile applications accessible, contact us today.

The post Mobile Application Accessibility: Understanding WCAG Conformance and Legal Requirements for Your Native Applications first appeared on Allyant.

Whether in the K-12 education space, healthcare, state/federal government, or other high-risk industries, ensuring the technology you procure is accessible is not just a legal mandate in many verticals—it’s an ethical responsibility.

Accessible technology empowers your end-users, including students, employees, and the public, ensuring equal access for everyone.

This article simplifies the process of evaluating technology in your procurement process by passing on some simple best practices I have learned from many other leaders in the accessibility industry, including the Disability:IN Procure Access Advisory Group.

It will even dive into some six practical tests you or your procurement team can follow when assessing technology for accessibility compliance.

We’ll also highlight why asking the right questions and ensuring vendor accountability is essential—even if accessibility is a new or unfamiliar topic for your organization.

Start by Asking About Accessibility Standards

Before diving in, it’s essential to ask the vendor about their commitment to digital accessibility. At first glance, this might seem like a basic question, but the vendor’s response can tell you a lot. Accessibility cannot be addressed as an afterthought—it’s a fundamental part of ensuring all users can engage with a product, regardless of their abilities.

Why This Matters

Imagine you’re about to embark on a major construction project. Wouldn’t you want to ensure the contractor has all the necessary permits, certifications, and experience before breaking ground? The same applies here.

A vendor’s ability to articulate a clear, actionable commitment to accessibility standards, known in the industry as an Accessibility Conformance Report (ACR) to the Web Content Accessibility Guidelines (WCAG), is a baseline indicator of how seriously they take accessibility.

If they can’t explain their conformance or demonstrate ongoing efforts to meet these standards, it’s like a builder who doesn’t know the safety codes. This is a red flag that their product might fail to meet the needs of all users.

Simple Starter Questions to Ask the Vendor:

• Do you comply with WCAG standards?
• Have you tried to comply with regulations impacting our vertical, such as DOJ Title II regulations, HHS regulations, or the European Accessibility Act (EAA)?

Imagine you’re procuring software for a public school district where students of all abilities need equal access to digital learning tools.

If the vendor can’t confidently speak about how their product aligns with WCAG standards or hasn’t taken steps to comply with regulations like the recently updated DOJ Title II requirements, they’re likely overlooking the needs of students who rely on assistive technologies.

An inaccessible product could mean these students miss out on critical educational opportunities.

By asking these direct questions upfront, you set the tone for accountability and transparency, ensuring accessibility isn’t left to chance.

If They Don’t Know—Red Flags to Watch For

Vendors unfamiliar with WCAG standards or legal regulations affecting your sector may not have considered accessibility at all in full transparency. While smaller vendors might not have everything in place just yet (and this is fine!)—their awareness and willingness to discuss these topics are crucial indicators of their future efforts.

If a vendor seems unaware or unable to provide documentation of their efforts, it’s not just a potential accessibility failure; it’s a signal that their product is likely inaccessible or not on a path to improvement in the foreseeable future, posing risks to your organization’s compliance and your end-user experience.

Why You Need to Request a VPAT ACR

After discussing standards and regulations, the next step is to request a Voluntary Product Accessibility Template (VPAT), which, if done correctly, will provide the Accessibility Conformance Report (ACR) for the product.

A VPAT ACR serves as a product’s accessibility scorecard—it should provide detailed insights into how well the software meets accessibility standards like WCAG 2.2, outlining any areas of non-conformance or why certain success criteria may not apply to the software product.

Why This Matters

Every reputable software vendor should have an up-to-date VPAT ACR in today’s regulatory landscape. It’s not just about checking boxes or having a perfectly accessible product; it’s about transparency and trust. A VPAT provides you with a snapshot of the product’s current accessibility status, but it’s also an indicator of the vendor’s commitment to making ongoing improvements.

However, not all VPATs are created equal. Some vendors will have comprehensive reports backed by live-user testing, while others might only offer superficial or very limited assessments.

Say you are buying a house—you wouldn’t skip the inspection just because the seller assures you that everything is in perfect condition because they lived there.

The VPAT ACR is the inspection, providing you with the necessary details to evaluate the product’s accessibility and likely the areas of non-conformance that can be improved.

Without this transparency, you’re making a highly risky purchase that could result in future legal liabilities or, worse, an unusable product for people with disabilities.

If a vendor is unable or unwilling to provide a VPAT ACR, it should be considered a major red flag in most scenarios. It’s like buying that house without knowing the details of what you are buying.

You have no idea what you’re getting into, and in many cases, the product will fail to meet the accessibility needs of your users.

Due to the energy and resources a vendor would need to expel in order to build an accessible product, I assure you they would show this off through a solid VPAT ACR, as they should!

In sectors like K-12 education, federal and state government, or healthcare, where where inaccessible technology could directly affect people’s quality of life, the risks are too high to leave anything to chance — particularly on large software investments that will be deployed at access points to most, or all, of your students, parents, patients, constituents or others in need of your organization’s goods and services.

Evaluating the VPAT ACR: What to Look For

Now that you’ve requested the VPAT, the next step is assessing its quality. This becomes overwhelming for many organizations because we cannot, and should not, expect procurement teams to be WCAG or digital accessibility experts.

However, a VPAT ACR is only as good as the testing and methodology behind it. This is where I’m hopeful these six simple tests can help your team immensely.

If deployed, these should guide your team through distinguishing between a superficial report and one that genuinely supports accessibility. Think of this as your team’s “VPAT ACR Procurement Quiz” for software vendors you are purchasing or renewing from here on out.

Test 1: Does Everything “Support”?

No product is 100% accessible — full stop. If a VPAT ACR shows that the product “supports” every single WCAG success criterion, this should be concerning for your team. I realize that sounds a bit backward!

Here’s why: Accessibility is a nuanced, ongoing process. Achieving full accessibility isn’t a one-and-done task; it requires constant testing, iteration, and improvement. Realistically, even the best vendors will identify some gaps in accessibility, whether technical barriers or limitations imposed by the platform itself. Again, this is fine. No product is 100% accessible, and for many large and complex software products, this likely should not be the goal as it would never be achieved.

Why This Matters

Think of accessibility like building a bridge—it’s not enough to say that every part of the bridge is strong. You need to know where the weak points are so that you can reinforce them before someone falls through. A vendor that claims “complete support” is likely glossing over potential issues or didn’t have a thorough assessment completed. This could leave you vulnerable to complaints, lawsuits, or simply alienating users with disabilities.

Real-World Context

Imagine a student who cannot use a mouse due to a physical disability trying to access online learning materials, only to encounter a button that can’t be activated with a keyboard. If the product claims to support all accessibility guidelines fully but the student can’t complete their coursework, their VPAT ACR should not show ‘full support.’ By identifying these shortcomings upfront, you protect not only your organization but also the individuals who rely on the product.

Test 2: Is the VPAT ACR More Than 12 Months Old?

Accessibility isn’t static—what was compliant last year might not be today. Technology evolves, new features are introduced, and regulatory changes occur. No set-in-stone requirement exists for how often a VPAT ACR must be updated.

However, based on industry research with other leaders, it is generally recommended that procurement teams request a VPAT ACR that is not more than 12 months old, as it may be outdated.

Regardless, regularly updated VPATs show a commitment to staying ahead of the curve and ensuring ongoing accessibility, and vendors with more up-to-date versions should score much higher on accessibility in procurement reviews.

Why This Matters

A VPAT ACR that hasn’t been updated is like using last year’s map to navigate a constantly changing landscape; even a tiny product update—like a new navigation feature or integration with another tool—can introduce accessibility barriers. An outdated VPAT suggests the vendor may not be actively maintaining accessibility, which can lead to significant issues in future product releases. This can mean you purchase a technically accessible product today. Still, if 24 months of development occurs in a 3-year contract, and accessibility tests are not built into the ongoing product lifecycle, it could fall into a highly inaccessible state during the contract term.

Real-World Example

Consider an agency that procures software to manage health records for a large hospital. A year ago, the software might have been mostly accessible and highly usable, but since then, the vendor has introduced new features without ensuring they meet accessibility standards. A blind doctor using a screen reader might suddenly find the software unusable for critical tasks, potentially delaying patient care or creating an inability for them to perform their job. Regular updates to the VPAT ensure that such risks are mitigated, giving you peace of mind that accessibility has been prioritized throughout the product’s lifecycle.

Test 3: Is the Product Version Listed on the VPAT ACR the Same One You Are Procuring?

It’s easy to overlook, but make sure the product version on the VPAT matches the one you’re planning to purchase. Additionally, ensure the product features are tested on the Accessibility Conformance Report.

The vendor should hopefully provide your team with an outline of the same feature set of the product your team is procuring. Accessibility can vary significantly between versions—specifically those that include major UI or feature enhancement.

Even a minor update could introduce barriers or, conversely, address critical issues that were present in earlier versions.

Why This Matters

Imagine buying a car based on a review of last year’s model, only to discover that the new model has serious safety flaws or is even missing a feature that you needed. The same applies to software accessibility—if you’re relying on an old VPAT ACR, you may miss out on new problems (or improvements) affecting the current version.

Real-World Example

Take, for example, a state government agency procuring a case management system. The system is vital for processing citizen applications, including those from individuals with disabilities. If the version you procure is different from the version listed on the VPAT, there could be accessibility gaps that affect how employees process applications from people who rely on assistive technologies. To avoid operational bottlenecks or exclusions, you need to ensure the VPAT reflects the most current version of the product you’re considering.

Test 4: Was the VPAT ACR Completed by a Third Party?

When a neutral third party conducts a VPAT ACR, you can generally have far greater confidence in its accuracy. In fact, many organizations whom I have spoken with directly, which are seen as accessibility leaders, explicitly require that VPAT ACRs be completed by a third party to be considered in their procurement reviews.

Most vendors conducting VPATs internally may have conflicts of interest or lack the technical depth to test their products thoroughly. There are instances among Fortune 100 organizations where their internal accessibility team is both well funded and extremely knowledgeable, including people with disabilities where an internally completed VPAT ACR will be highly accurate. However, this is an outlier instead of the norm.

Third-party assessments should provide an unbiased, comprehensive view of a product’s accessibility, pulling on the expertise of seasoned accessibility engineers to provide a thorough and honest review of the software vendor’s product.

Why This Matters

Internal evaluations are often optimistic at best and, at worst, overlook critical accessibility issues altogether. Third-party assessments are like having an expert mechanic inspect a used car before purchase. You get an objective view of any flaws, and the vendor doesn’t have the opportunity to downplay or even ignore them for the sake of making the sale to your team.

Real-World Example

Think of a school district evaluating an e-learning platform. If the VPAT was completed by the vendors themselves, they may not have had a proper understanding of the challenges students with disabilities face. Perhaps they relied on automated testing tools only, which often miss crucial issues that real users encounter. Third-party audits should incorporate more rigorous testing methods, including live-user testing, and give you a more reliable picture of the product’s accessibility.

Test 5: Was Live-User Testing Performed?

Live-user testing is critical because it reflects how real people interact with technology—especially those who use assistive technologies like screen readers or keyboard navigation. Automated tools can only catch so much.

To truly ensure accessibility, vendors should include real users with disabilities in their testing process. Their feedback is essential to understanding where barriers exist in the product.

This is where Test 4 and Test 5 somewhat rely on each other. The VPAT ACR you obtain should include details on the type of users with disabilities and specific assistive technologies the third-party vendor included to ensure their report accurately reflects the product’s conformance with WCAG.

Why This Matters

Automated testing is like running spell-check on an essay—it can catch basic errors, but it won’t help with the deeper issues like structure or flow. Similarly, automated tools can identify surface-level accessibility problems. Still, real-world usability issues are often missed without involving live users who are experts in leveraging assistive technology to interact with the digital world.

Real-World Context

Imagine a social services platform citizens use to access important public benefits. A person who is visually impaired may struggle to fill out required forms because an automated tool missed an inaccessible label. This could delay their benefits, causing frustration and stress that should be avoided and unnecessary to an individual who needs it the most. Live-user testing helps vendors find these real-world issues, ensuring a smoother and more inclusive experience for end users.

Test 6: Is the ACR Roadmap a Path to Conformance?

A good VPAT ACR doesn’t just say what works and what doesn’t—it provides a well-defined roadmap for fixing accessibility gaps. Simply said, the best VPAT ACRs include an ACR!

Your team should look for vendors that provide clear steps on how they plan to address the issues identified in their VPAT ACR, complete with timelines and priorities for resolving issues based on their practical impact on the end user.

This shows the vendor is committed to continuous improvement rather than just checking a box for compliance.

Why This Matters

Accessibility is a journey, not a destination. The software you procure may not be fully accessible today, which should not be your request in procurement, as outlined in this article. However, a solid roadmap indicates the vendor’s commitment to getting there and, over the life of a contract, building a more accessible product that will only enhance access for your end-user. Without this, you risk investing in a product that will never meet the needs of your diverse user base, leaving you exposed to both legal risks and valid user frustration.

Real-World Context

Let’s say you’re procuring a student management system for a school district. The system isn’t fully accessible today, but the vendor provides a detailed plan for addressing accessibility gaps. They commit to making critical features accessible within 12 months, with regular progress reports and updates. This transparency and dedication give you confidence that the vendor will follow through, ensuring that students with disabilities can use the system without barriers in the near future.

Six Steps to More Accessibility Products!

One thing I hope everyone reading takes away from the six steps above is the criticality of this final real-world example.

It is important to understand the impact of the honest education vendor with a clearly defined roadmap and honest view of their product’s accessibility — even if there are gaps in their current VPAT ACR. These vendors are far more valuable to your team than the software vendor stating “full accessibility,” which isn’t accurate and blocks your student once you spend thousands of dollars implementing the software.

Or a vendor whose last accessibility review was 18 months ago, with no accessibility progress in the interim, and whose software is regressing at every release.

It helps you and all organizations when these vendors, with a true commitment to accessibility, win your business through a thorough and honest accessibility review of all vendors in a procurement cycle.

Weighting accessibility with high importance and providing vendors with feedback aligned with the six steps above will push more software vendors to show a real commitment to accessibility by improving their product access.

Ultimately, this creates a win for you as a procuring entity but a much larger win for people with disabilities who are forced to use many inaccessible software products every day.

Conclusion

Navigating accessibility during procurement doesn’t have to be overwhelming; it also does not have to be perfect. All aspects of accessibility are a journey, and your team should be focused on small victories and process improvements.

By deploying the six tests above into your software procurement process, your team will be on the path to helping ensure that the technology you procure not only meets today’s accessibility standards but also aligns with your organization’s commitment to inclusion.

Don’t settle for vague promises—hold your vendors accountable and ensure that accessibility remains a priority throughout the product lifecycle!

Allyant’s Role in Helping You Procure Accessible Technology

At Allyant, we know the path to accessibility can be complex, especially in procurement. That’s why our VPAT services go beyond just checking boxes—we perform deep assessments, including live-user testing, and provide software vendors with actionable reports that ensure they can meet your accessibility requirements.

If you are looking to procure a software and the vendor has a vested interest in improving their product but is unsure where to look, have them reach out to our team. We will get them on the path to conformance and pass your Six Step Procurement Quiz with flying colors in no time!

On the flip side, if you need further procurement support or want to help build an even more robust review of all the software products you are procuring or renewing in upcoming contract cycles, we can help you succeed.

Allyant’s ProcureEnsure service simplifies your procurement process by helping you assess the accessibility of potential products with confidence. We work with vendors to provide ongoing progress reports, ensuring that accessibility improvements continue post-procurement.

The post Accessible Procurement Demystified: 6 Best Practices for Evaluating Technology first appeared on Allyant.

As digital spaces expand into every facet of life, ensuring these spaces are inclusive and accessible has become a global priority.

Canada has taken substantial steps in this direction, with pioneering regulations like the Accessibility for Ontarians with Disabilities Act (AODA) and the Accessible Canada Act (ACA) setting high standards for digital accessibility.

While both acts are transformative, they are often misunderstood, particularly regarding their requirements and the organizations they affect.

In this article, we’ll break down the histories of these two landmark regulations, dispel some common myths, and provide a detailed roadmap to compliance—focusing specifically on the digital accessibility requirements.

We’ll also discuss why Allyant’s end-to-end accessibility services are critical for organizations to meet to excel in conforming to these Canadian accessibility obligations.

AODA: Pioneering Digital Accessibility in Ontario

History and Progression of the AODA

The Accessibility for Ontarians with Disabilities Act (AODA) was enacted in 2005 to create a fully accessible Ontario by 2025.

AODA was groundbreaking at the time, representing one of the earliest attempts at legislating accessibility in a Canadian province—or anywhere in the world, quite frankly. The act mandates accessibility across five key areas:

1. Customer Service.
2. Information and Communications.
3. Employment.
4. Transportation.
5. Design of Public Spaces.

The AODA is particularly concerned with the Information and Communications standard for digital accessibility. This standard requires organizations to ensure that their websites, mobile apps, and digital documents are accessible to people with disabilities.

When the AODA was enacted in 2005, conformance standards for web and digital interfaces were largely immature.

WCAG 1.0 was still the only recognized standard until WCAG 2.0 was released in 2008. With this release, the AODA eventually adopted the Web Content Accessibility Guidelines (WCAG) 2.0 Level AA as its benchmark for digital accessibility conformance in 2011 as part of its Integrated Accessibility Standards Regulation (IASR).

Reporting Timelines and Compliance Deadlines

The AODA has established strict and largely clear reporting requirements for organizations based in the province. The most recent reporting deadline was December 31, 2023, for public or private organizations with 20 or more employees.

While 2023 was a critical year for reporting, that has also come and gone, with many organizations fitting into the 20+ employee bucket still not adhering to WCAG conformance across their digital properties and documents.

This brings us to the 2025 “compliance deadline” that is getting so much attention and perhaps pressure across the accessibility industry. If you are not in compliance today, you have failed to meet the AODA’s requirements as outlined by the June 2023 reporting deadline for WCAG 2.0 AA conformance.

However, 2025 has been a long-standing part of the AODA’s broader strategy since its enactment on Day 1.

This is not a new deadline but rather the culmination of the AODA’s 20-year vision to make Ontario fully accessible by 2025. By then, every aspect of an organization’s operations, including its digital presence, must comply with the WCAG 2.0 Level AA standards.

The reality is that if an organization has missed the 2023 reporting deadline, it is at significant legal risk.

I say this not to scare you but purely based on the fact that we have now seen many examples, both on websites and digital documents, of the Ontario Government starting to enforce the AODA.

With the 2023 reporting deadline well in the rearview mirror and the 2025 fully accessible Ontario date on the near horizon, enforcement of this landmark act is starting to take full effect.

Compliance Requirements and Penalties

Organizations subject to the AODA are required to file accessibility compliance reports that outline how they are meeting the accessibility standards.

This report includes details on whether the organization’s websites, mobile apps, and digital documents conform to the WCAG 2.0 Level AA guidelines.

Penalties, in the form of fines from the Ontario Government under the AODA as published, are important for organizations to consider when building out the ROI on digital accessibility.

As documented in the statute language, individuals can be fined up to $50,000 per day, while corporations can be fined up to $100,000 per day. Fines increase until the violations are resolved.

The reality is, for most organizations, a robust digital accessibility plan working with a vendor like Allyant to resolve web, mobile, and document accessibility likely costs less per year than the daily fines under the AODA if found to be in non-compliance, something to consider!

Here are the core requirements for AODA compliance:

• Websites and Mobile Apps: Websites, including new content on websites, must meet WCAG 2.0 Level AA standards per the current state of the regulations (more on our recommendation for 2.2 AA testing below!). This includes having accessible forms, alternative text for images, and navigational aids that make it easier for users with disabilities to access information.
• Digital Documents: PDFs and other digital documents must be fully accessible. This means that they should be tagged, structured, and designed to work with screen readers and other assistive technologies.

It is important to note that the next formal reporting date for all companies with 20+ employees in Ontario is December 31, 2026. Accessibility can take time and be much more cost-effective when built out over a longer development cycle and a backlog of remediation work for both websites and applications, as well as PDF documents.

With that in mind, if your organization has not already started working against your compliance roadmap, you could face legal action for missing the 2023 deadline while also being up against a 2026 deadline that will approach quickly.

Your team can refer to the official Ontario compliance reporting guide for more details on AODA compliance reporting.

The Accessible Canada Act: Digital Accessibility at the Federal Level

History and Evolution of the ACA

Enacted in 2019, the Accessible Canada Act (ACA) aims to make Canada fully accessible by 2040. While the AODA primarily affects organizations within Ontario, the ACA applies to federal organizations and businesses operating across all provinces.

Its scope is national, ensuring accessibility across federally regulated sectors, including government agencies, telecommunications, transportation, banking, and more.

The ACA requires organizations to remove and prevent barriers across seven priority areas, including Information and Communication Technologies (ICT).

This makes digital accessibility a key compliance focus, particularly for websites, mobile apps, and ICT products.

EN 301 549 and WCAG 2.1 AA Adoption in 2024

A critical and recent update to the ACA is the adoption of EN 301 549, a globally recognized accessibility standard, which went into effect on May 31, 2024.

For context, EN 301 549 is a comprehensive accessibility standard for ICT products and services, covering websites, mobile applications, software, hardware, and digital documents like PDFs.

This adoption represents Canada’s alignment with international accessibility standards, specifically WCAG 2.1 AA.

Organizations subject to the ACA must ensure that their digital assets meet WCAG 2.1 AA requirements. To help with the common confusion I often hear, WCAG 2.1 includes all of the WCAG 2.0 success criteria, but it also extends to more stringent and future-proofed standards such as mobile responsiveness and enhancements for users with cognitive disabilities.

This is specifically important to note for organizations based in Ontario, as the AODA standards point to WCAG 2.0 AA, as outlined above. However, with the federal Accessible Canada Act furthering the requirements to WCAG 2.1 AA, this standard should likely be your organization’s minimum requirement goal.

For more details, refer to the ACA’s official adoption of EN 301 549 here.

Scope of Requirements for ICT Products and Digital Documents

Under the ACA, organizations must ensure that their ICT products are accessible. Not unlike other global regulations such as the European Accessibility Act, which also references EN 301 549 as its compliance standard, the ACA includes accessibility conformance for:

• Websites: Must be tested to and conform with WCAG 2.1 AA. This standard introduces additional success criteria for mobile devices, keyboard navigation, and more user-friendly error identification beyond the baseline 2.0 AA criterion.
• Mobile Applications: Mobile apps must also conform to WCAG 2.1 AA, meeting specific accessibility criteria related to navigation, touch gestures, and interactions with assistive technology that can be specific to mobile devices without keyboard or mouse functionality, for example.
• PDFs and Digital Documents: Like the AODA, the ACA mandates that all digital documents must be accessible to assistive technologies. This includes structuring documents properly and tagging elements to ensure compatibility with screen readers.
• ICT Products: Hardware and software must be designed with accessibility in mind, ensuring that users with disabilities can interact efficiently with digital products.

The Importance of WCAG 2.2 AA Compliance

Although the ACA currently mandates WCAG 2.1 AA compliance, which, in my opinion, makes the AODA’s WCAG 2.0 AA compliance outdated, Allyant strongly recommends that organizations prepare for WCAG 2.2 AA. This is the latest version of the Web Content Accessibility Guidelines, which adds further enhancements to address accessibility barriers.

At a minimum, if your organization is just starting its accessibility roadmap and obtaining audits of its website and mobile applications or having a vendor like Allyant remediate its backlog of PDFs, all of this testing and remediation should be done to WCAG 2.2 AA. We do this for every Allyant digital and PDF remediation customer at no additional cost.

Ultimately, by ensuring that digital assets comply with WCAG 2.2 AA, organizations future-proof their investments and avoid the need for extensive updates as regulations evolve.

This can be increasingly important for organizations that have both US and Canadian websites, often sharing a similar code base or web framework.

High-volume plaintiff firms in the U.S. are starting to reference WCAG 2.2 AA as the necessary compliance standard in ADA web accessibility claims since it has been adopted as the most up-to-date standard for over a year.

Common Accessibility Misconceptions Under AODA and ACA

One of the most common misconceptions surrounding AODA and ACA is that achieving minimum compliance is sufficient. Organizations often believe that simply ticking the boxes for WCAG 2.0 or WCAG 2.1 AA compliance is enough to protect them from legal risk.

This could mean simply running an automated testing tool as their only method of assessment (covering roughly one-third of the WCAG success criteria) rather than garnering user feedback through live-user testing by highly trained accessibility engineers with disabilities.

It could also mean installing an accessibility overlay on their website and not performing any other method of digital accessibility testing.

However, digital accessibility is not a one-time project—it requires continuous monitoring, updating, and live-user testing.

This is also why the AODA requires ongoing compliance reporting every three years as part of the statute, which I applaud the Ontario government for as it presses the realization that accessibility must be baked into an organization’s DNA and ongoing processes.

Failing to maintain accessibility standards can expose organizations to:

• Reputational Damage: Failing to meet accessibility obligations can lead to loss of business and a tarnished brand image. I know for certain the AODA and ACA were not built as a means of finding businesses by government entities but were put in place to ensure reasonable access was provided to individuals with disabilities. Ultimately, accessibility is a human right and is simply the right thing to do.
• Lawsuits: Inaccurate or outdated accessibility reports can lead to costly legal actions. Although this has mainly been pursued by high-volume plaintiffs in the U.S., with very clear guidelines and conformance deadlines in Canada and the EU upon us, it is not unreasonable to think this legal activity trickle into other regions in the very near future.
• Fines: As we’ve seen with the AODA recently, now that the Ontario government is reviewing websites and documents with the 2025 vision deadline approaching, penalties for non-compliance can be steep, ranging up to and past $100,000 for organizations.

Why Allyant is the Full-Service Accessibility Partner You Need

A Partner for Holistic Accessibility

Allyant is the only industry leader capable of providing full-service accessibility audits for websites, mobile apps, software applications, and both digital documents as well as printed customer communications. Our expertise in live-user accessibility testing, remediation support, and software procurement allows us to cover every aspect of your organization’s AODA and ACA compliance requirements under a single vendor agreement. Here’s how:

• Web and Mobile Accessibility: We test all digital properties to WCAG 2.2 AA, ensuring future-proof compliance.
• PDF Remediation: Allyant’s best-in-class PDF remediation capabilities allow us to process high volumes of documents at scale, delivering WCAG 2.2-compliant documents with a 100% compliance guarantee with every single document.
• Live-User Testing: Automated testing can only detect a fraction of accessibility barriers. That’s why Allyant integrates live-user testing, including people with disabilities, into our unique paired auditing process to identify real-world issues and go beyond just conformance to create highly usable digital experiences.
• Ongoing Support: Accessibility is an ongoing journey. Allyant offers managed services and compliance programs to ensure continuous accessibility monitoring, testing, and reporting—including ensuring you have the utmost confidence in filling out your 2026 AODA compliance reports!

Conclusion

Navigating the digital accessibility landscape in Canada can be overwhelming for many organizations—but understanding the differences and requirements of the AODA and ACA is the first step toward building your team’s compliance roadmap.

By going beyond just checking the box for accessibility, organizations can mitigate legal risks, enhance their customer experience, and differentiate themselves in an increasingly competitive marketplace.

Partnering with our team at Allyant ensures that your organization meets and exceeds accessibility standards today and in the future.

If your organization has any questions about the Canadian accessibility requirements or needs a partner to put you on the fast track for holistic compliance, reach out to our team today!

The post From AODA to ACA: Understanding Canada’s Digital Accessibility Regulations first appeared on Allyant.

However, this misconception can be costly for software vendors and their clients procuring their software.

When treated merely as a checkbox to satisfy procurement requirements, the VPAT fails to serve its intended purpose, documenting how accessible your product really is.

More importantly, it should guide you in making meaningful accessibility improvements on a regular basis. The VPAT’s real output is an actionable Accessibility Conformance Report (ACR), and its effectiveness depends entirely on how thoroughly your product has been assessed.

Some Myths Regarding VPATs

Let me quickly dispel a few myths and a strong concern I have seen in our industry over the past few months with increased procurement requirements based on U.S. and global regulations for software companies to set up the reasoning for writing this article.

1. You cannot obtain a VPAT in 2-3 business days that you should feel comfortable providing in RFP or contract submissions, and if a business offers this, it should be a major red flag.
2. A business providing you with a completed VPAT without a robust ACR and Audit Report that allows your team to improve your product and show a more accessible product on future VPAT ACRs is wasting your team’s resources.

This article is meant to guide you through why a VPAT is far more than a checkbox for your sales team and how to ensure your ACR is a living document that drives accessibility improvements for your product team, mitigates legal risks, and serves as a competitive differentiator in the marketplace.

Your VPAT Is Not a Box-Check

For many businesses, the temptation to treat a VPAT as a quick checklist is hard to resist.

After all, many procurement processes and contracts have historically required the submission of a “Completed VPAT” to meet accessibility requirements.

However, this can be a superficial approach that ultimately undermines the VPAT’s core intent: to provide transparency and accuracy about the accessibility of a product or service.

By rushing through the process or using boilerplate responses, companies risk producing an inaccurate ACR that satisfies immediate procurement demands but does nothing to enhance the product’s accessibility genuinely.

The real legal risk, however, lies in the fact that such an approach can expose your company to legal challenges if customers or regulators find that your product does not meet the accessibility expectations you claimed.

A properly executed VPAT, on the other hand, provides an authentic foundation for improving the user experience, particularly for individuals with disabilities, and creates a roadmap for ongoing enhancements.

The Critical Role of a Thorough Vendor Assessment

The quality of your VPAT and ACR output depends largely on the vendor you select to conduct your accessibility audit.

Let’s also start with the simple fact that a VPAT ACR is not a static document; it must reflect your product’s actual accessibility status in real-world usage.

This means it cannot be completed accurately without a thorough and rigorous assessment of how your product will be used by your clients and their end-users (consumers or internal employees).

I also feel it is important to note that a VPAT itself is a blank template created by the Information Technology Industry Council (ITIC), designed to provide a detailed analysis of a product’s accessibility conformance to the chosen WCAG Standard (2.0, 2.1, or 2.2). Without substantial testing from trained accessibility engineers, this template is just a shell.

A vendor must possess not only technical knowledge of WCAG 2.2 success criteria but also practical experience in how users, particularly those with disabilities, interact with and leverage your product in order to complete the VPAT and provide your team with an ACR output.

Full stop: vendors that rely solely on automated tools or neglect live-user testing will provide an incomplete ACR.

These “audits” won’t capture the full scope of accessibility issues and leave you with an unreliable picture of your product’s real-world usability.

The key to a successful VPAT process is selecting a vendor who combines automated, manual, and live-user testing by people with disabilities to provide a comprehensive and actionable report.

Allyant, for example, specializes in paired auditing with sighted and blind accessibility engineers, ensuring the full spectrum of accessibility issues are identified.

The VPAT Template: A Blank Form vs. An Actionable Roadmap

Understanding the VPAT structure and overarching goals of this template is crucial to crafting a meaningful ACR. While the VPAT itself is merely a template, an Accessibility Conformance Report (ACR) is where the real value lies for your organization.

The most critical section in the VPAT template is the “Remarks and Explanations” field.

Here, your vendor must provide clear, detailed explanations for each conformance level, such as “Supports,” “Partially Supports,” “Does Not Support,” or “Not Applicable.”

For a robust ACR, this section should contain:

• Descriptions of Test Cases: These are used to evaluate each WCAG success criterion.
• Explanations of Partial Conformance: outlines which aspects of the criteria are met and which are not so you can have an informed conversation with procuring entities.
• Remediation Guidance: recommends steps for improving areas that do not currently meet accessibility standards. Otherwise, your product will simply remain inaccessible, which is not helping anyone.

This depth of analysis not only helps make your product accessible but also instills confidence in your customers, regulators, and partners. A generic or superficial VPAT offers no actionable insights and may fail to address critical accessibility gaps for both your clients and your product development team, which we will break down in the next section.

Generic VPATs Do Not Lead to Accessibility Improvements

A common pitfall is obtaining a generic VPAT and treating it as a one-time effort—or a yearly exercise that you will rinse and repeat next year and not worry about accessibility in between.

Many companies believe this will suffice to meet accessibility requirements.

However, accessibility is not static; it is an ongoing process. An ACR must evolve as your product evolves—whether through feature updates, design changes, or compliance with new accessibility standards such as WCAG 2.2.

For a VPAT to be truly actionable, the ACR output must be treated as a living document. Like any strong accessibility roadmap, your software product must be revisited regularly to ensure continuous improvement.

When clients or partners conduct accessibility reviews during procurement or renewal processes, they should see tangible improvements based on the ACR’s previous recommendations and your current state of compliance.

At Allyant, we support our clients with up-to-date conformance reports and progress on remediation of identified issues through ongoing QA testing exported directly from our Allyant HUB platform.

This ensures our software clients can not only provide highly accurate VPAT ACRs reflective of the current state of their product but also go above and beyond the VPAT checkbox and show their clients real and sustained accessibility progress to exceed contract requirements around accessibility conformance.

Failing to update your ACR regularly means missing out on opportunities to enhance both accessibility and user experience. More importantly, it shows that your commitment to accessibility is ongoing, not a one-time exercise.

The Audit Behind the ACR: Why It’s the Most Critical Step

A VPAT ACR is only as good as the audit conducted to support it. Without a rigorous accessibility audit, the ACR is just another document with no roadmap for improving the product. A thorough audit involves:

• Manual Testing: Done by accessibility experts who fully understand the nuances of the WCAG success criteria. Our team performs all audits to WCAG 2.2 to support global accessibility regulations for our clients.
• Live-user Testing: People with disabilities ensure that the product is not only accessible with WCAG but usable in real-world conditions. This is also documented in the testing methodology for all ACRs we deliver to our clients.
• Automated Testing: A supplemental tool, but it is not the primary means of evaluation.

The most valuable ACRs not only provide a snapshot of your product’s current accessibility status but also offer your product and development team a detailed action plan for remediation.

This makes the ACR an indispensable tool for both your development team, which can improve accessibility barriers within your product, and business decision-makers, who will have the peace of mind that your team is committed to ongoing accessibility conformance.

Live-User Testing: The Human Element in Accessibility Audits

Live-user testing is one of the most critical components of a robust accessibility audit. Automated testing tools are helpful in identifying a certain percentage of WCAG violations, but they can only go so far in driving usability, specifically in complex software applications. True accessibility requires human interaction from assistive technology users with disabilities.

A thorough ACR will include insights from live-user testing, specifying:

• Who participated in the testing (e.g., users with vision, mobility, hearing, or cognitive disabilities).
• What real-world scenarios were tested to simulate actual use.
• What insights were gained, and how they informed the audit’s findings.

Incorporating live-user feedback ensures that your product is accessible not just in theory but in practice. Think about education software that will be deployed in K-12 schools.

If a student is asked to learn course material through this application but leverages a screen reader or has a physical disability that requires them to access through keyboard navigation — failing to replicate these scenarios while outlining WCAG conformance on your VPAT ACR can prevent a school from providing accessible accommodations to a student if the software vendor does not accurately represent the current access barriers in their software.

Treating Your ACR as a Living Document

Accessibility is an ongoing process, whether focusing on a simple website, mobile application, or complex software application, and as your product evolves, so must your ACR. Updating your ACR regularly through ongoing accessibility testing ensures that:

• New features or updates are consistently evaluated for accessibility, and your ACR reflects the current state of your product.
• Your product meets or exceeds the latest WCAG guidelines or regulatory requirements as global regulations evolve.
• You can demonstrate clear, measurable progress to clients, customers, and regulators, arguably the most important aspect of procurement and meeting contract requirements regarding accessibility.

There is currently no legal requirement for how often to update your VPAT ACR, but there are industry best practices we can outline.

Generally, I inform any software vendor that their first VPAT ACR will be their worst—following a thorough accessibility audit for the first time. This is natural, and this is also OK!

A strong ACR and audit report are a health assessment on how to roadmap improving your product’s accessibility.

As your team works through initial accessibility remediation, we closely track a ‘virtual ACR’ in our Allyant HUB Platform to help our clients make informed decisions about updating their VPAT ACR to reflect your team’s hard work and accessibility improvement.

In most cases, this can occur anywhere between 3 and 9 months from issuing the initial VPAT ACR, but these updates also only take a few hours if you are working with a transparent vendor. So, we can easily update your VPAT ACR one time or ten times at a very minimal cost as your product improves!

Once your team has an established accessibility roadmap and strong ongoing testing practices in place, we strongly encourage our software clients to update their VPAT ACR every 12 months.

This ensures that the dates within the completed product remain relevant and as outlined above, the output matches the current state and version of the product they are selling in the marketplace.

A Solid VPAT ACR: Your Secret Weapon for Sales and Competitive Differentiation!

A well-executed VPAT ACR can be far more than just a compliance tool—it can serve as a powerful sales asset and a key differentiator in the marketplace.

As accessibility becomes a priority for both public and enterprise clients, a robust ACR demonstrates your commitment to delivering inclusive digital experiences and allows you to proactively represent this commitment, unlike competitors, whether it is a strict RFP requirement or not.

Working with a reputable vendor like Allyant not only provides you with a reliable ACR but also positions your business as a leader in accessibility.

Allyant goes beyond just producing a document; our team acts as an extension of your sales and marketing team, providing ongoing support in responding to RFPs and RFIs, answering accessibility-related questions, and even joining client calls to explain your product’s conformance, and progress and ongoing accessibility testing practices to ensure your clients are confident in the current and future state of your product.

In this way, a solid ACR and working with the Allyant team to obtain these from an industry-leading third party do more than satisfy procurement requirements—they become a competitive advantage, helping you secure contracts and maintain long-term relationships with clients who prioritize accessibility or require it based on their vertical and legal requirements.

Software vendors who rely on “box-checking” VPATs cannot offer the same level of assurance, leaving you with an inferior product and at risk of losing business to competitors who take accessibility and have a vendor in their corner that sets them apart in honest and actionable responses upon request.

Beware of the ‘Quick VPAT’

Obtaining a comprehensive, accurate VPAT ACR is time-consuming, and any vendor that promises to deliver one in 1-2 weeks is either not honest in their testing process or will provide you with a lackluster VPAT ACR output. A legitimate audit process to complete a thorough VPAT template and provide a detailed ACR output takes time to complete because it involves multiple steps:

• Manual and automated testing to evaluate the product’s compliance with WCAG 2.2 guidelines.
• A live-user audit to ensure that real-world users can interact with the product.
• The findings are compiled into a detailed ACR, complete with a prioritization of issues based on their usability impact and specific recommendations for remediation.

When selecting a vendor, be cautious of those who claim they can deliver a VPAT ACR in an unrealistic timeframe. As I outlined in a recent article, an in-depth accessibility audit will take 4+ weeks, perhaps more for complex products.

If this thorough assessment of all core product features has not been conducted, no accessibility company can provide your team with an accurate VPAT ACR that includes your software’s level of conformance to every WCAG success criteria and a detailed explanation when a success criterion Partially Supports, Does Not Support or is Not Applicable.

If your team or vendor cannot explain in detail the output and next steps relative to the VPAT ACR they are providing, you should not feel confident providing this to your clients in their procurement process for the legal risks outlined above.

By jumping for the cheapest vendor or trying to rush to obtain a box-checking “quick VPAT”, your team may instead end up with an incomplete, inaccurate, or not actionable document—ultimately costing you more time and money in the long run.

The Legal Risks of Inaccurate VPATs

An inaccurate or incomplete VPAT can expose your company to significant legal risks. Government agencies and large enterprises increasingly rely on VPAT ACRs when making procurement decisions. If your ACR misrepresents your product’s accessibility, you could face some obvious contract consequences, including:

• RFP Elimination if the client procuring your software runs a lightweight assessment on the product to validate the accuracy of your VPAT, such as through our ProcureEnsure service. Many federal, state, education, and even private sector businesses are building out accessible procurement processes and ensuring products are tested prior to acquisition. If your VPAT ACR does not reflect the product’s actual state, your team will likely be eliminated from consideration quickly.
• Contract Cancellations if your product fails to meet the expected level of accessibility after being deployed by your client. For example, say a public entity procures your product based on a VPAT ACR that does not accurately reflect the current state of accessibility and then immediately receives a consumer or employee complaint that the product is inaccessible.

As regulations such as the DOJ ADA Title II recommend accessible procurement, the updated HHS accessibility requirements, and international laws like the European Accessibility Act (EAA) continue to drive demand for product accessibility, the importance of an accurate and actionable VPAT has never been greater.

Your ACR should protect your business from legal action and ensure that your product is accessible to the people who need it most.

Why an Actionable VPAT ACR is Essential for Long-Term Success

To recap, if your team is assessing accessibility for the first time because a client or prospect just asked you for your product’s VPAT, it is critical to consider this is far more than just a procurement requirement.

Your team should take pride in your VPAT ACR, which is a tool for achieving true digital accessibility.

A meaningful ACR helps you understand your product’s current state of accessibility, guides future improvements, and minimizes legal risks. Most importantly, it positions you as a leader who provides inclusive experiences for all users.

I would also close with the honest fact that no software product in existence is 100% accessible.

Therefore, no client or prospect should require you to provide a VPAT ACR that shows you “support in full every WCAG success criterion.” Most mature accessibility organizations would actually view this as a red flag and likely assume you obtained a box-checking VPAT!

In fact, if a client requires you to show a 100% perfect VPAT ACR, I would be happy to chat with the client and support your team; reach out below!

To ensure that your VPAT is actionable and not just a checklist, I strongly encourage your team to choose a reputable vendor with vast procurement support experience, such as our team here at Allyant.

Our extensive experience provides a thorough, detailed audit conducted by experts specializing in accessibility and live-user testing. Our reports are comprehensive and actionable, helping you not only meet current standards but also drive long-term improvements in accessibility.

If you’re ready to take your VPAT beyond an accessibility checkbox and start leveraging it as a competitive tool, reach out below. Our team of experts will work with you to provide an in-depth, actionable ACR that satisfies procurement requirements and enhances your product’s accessibility and usability.

Reach out now to schedule a consultation or audit, and let us help you make accessibility a key differentiator for your business!

The post How to Ensure Your VPAT ACR is Actionable, Not Just a Checklist first appeared on Allyant.

We’ll also explore how European businesses must prioritize accessible procurement, ensuring that software vendors are committed to ongoing accessibility improvements.

This is not just about meeting regulatory requirements but about enhancing product usability and expanding market access.

The EAA and Software Companies: Building a Strong Accessibility Roadmap

Software companies, particularly those operating in or targeting the European market, must recognize the significant impact the EAA will have on their business.

The EAA requires that digital products and services be accessible to people with disabilities, aligning closely with the Web Content Accessibility Guidelines (WCAG) 2.2 AA and the EU’s EN 301 549 standards.

Why an Accessibility Roadmap is Essential:

• Regulatory Compliance: The EAA mandates that all digital services provided to European consumers or businesses be accessible. Without a clear accessibility roadmap, software companies risk non-compliance (including putting their customers at risk of legal action), leading to potential legal consequences, including fines and restrictions on market access.
• Market Differentiation: Accessibility is not just a regulatory requirement; it’s a market differentiator. Companies that demonstrate a commitment to accessibility with a clearly defined action plan and success metrics will stand out in a crowded market, attracting a broader customer base, including public sector clients who are bound by strict procurement guidelines.
• Continuous Improvement: The digital landscape is constantly evolving, and so are accessibility standards. A strong accessibility roadmap should include a commitment to continuous product improvement, ensuring that your software remains accessible as new features and updates are released. Accessibility is simply not a one-and-done checkbox, it must be baked in your product and development teams standard practices through continuous testing and training.
• Third-Party Validation: Obtaining third-party VPAT ACRs is a critical component of your accessibility roadmap and long-term success. These reports provide an objective assessment of your product’s accessibility, demonstrating your commitment to compliance and giving customers confidence in your product. Allyant recommends updating these reports at least every 12 months to reflect the current state of your software’s version and accessibility.
  

Key Steps to Develop an Accessibility Roadmap:

• Assess Current Accessibility: Start by conducting a thorough assessment of your software’s current accessibility. Especially for complex software applications, this must include live-user testing with individuals who have disabilities (along with automated testing), to identify and effectively address both WCAG compliance violations and usability issues.
• Create a Long-Term Plan: Develop a detailed roadmap that outlines your accessibility goals, timelines, and milestones as a major step in building confidence with your customers that are bound to complying with the EAA that you are committed to both providing an accessible product and maintaining it through ongoing processes. This plan should include regular updates to your VPAT ACR, ensuring that your software remains compliant with the latest standards and through future software enhancements.
• Engage with Third-Party Experts: Partner with accessibility experts, like Allyant, to obtain third-party VPAT ACRs. These reports are not only valuable for compliance but also for gaining insights into areas of your product that can be improved. In many situations, this is also critical to moving through procurement processes or RFPs as many global organizations are specifically requesting and requiring third-party VPATs as part of their purchasing process.
• Focus on Usability: Accessibility is not just about meeting the WCAG standards; it’s about ensuring that your software is usable by those leveraging it with assistive technology. Incorporate feedback from live-user testing into your development process to continually improve your product is the only way to ensure both ongoing compliance and usability for people with disabilities.
  

European Businesses: The Need for Accessible Procurement

On the flip side, European businesses have a critical role in ensuring that the technology they procure is accessible. Under the EAA, deploying inaccessible software could result in non-compliance, exposing your organization to legal and financial risks.

Building a Strong Accessible Procurement Model:

• Procurement Policies: European businesses must develop procurement policies that prioritize accessibility is both the purchasing and software renewal process for any third-party software or application they are deploying to their consumers or internal employees. This includes requiring that all software vendors provide a third-party VPAT ACR, demonstrating that their products either meet the necessary accessibility standards or they have a roadmap and continuous improvement processes in place to ensure compliance within a reasonable timeframe.
• Continuous Evaluation: Accessibility is not a one-time checkbox. Businesses should implement a process for continuously evaluating the accessibility of the software they procure, ensuring it remains compliant as new updates and versions are released.
• Vendor Accountability: Hold your software vendors accountable by requiring them to demonstrate ongoing accessibility improvements. This can include regular updates (we recommend every 12 months) to their VPAT ACRs and engagement in live-user testing to identify and address potential accessibility barriers. For most software vendors, their first VPAT will be their worst VPAT, and that is ok! However, their should be improvements on these reports overtime for software vendors committed to providing accessible products.
• Guidance and Resources: I would strongly considering utilizing Disability:IN’s Procure Access ToolKit as a resource. This toolkit provides comprehensive guidance (at no cost!) on how to incorporate accessibility into your procurement processes. As a signatory of the Procure Access statement, Allyant is committed to testing all products we procure for accessibility, including live-user testing as a baseline requirement.

How ProcureEnsure simplifies software procurement

• Comprehensive Live-user Procurement Testing: Allyant’s ProcureEnsure service offers European businesses access to the same rigorous testing that we use for our own procurement. This includes live-user testing with people who have disabilities, ensuring that the software you deploy is truly accessible.
• EAA Compliance: ProcureEnsure helps businesses navigate the complexities of the EAA, ensuring that they are not unknowingly breaking conformance by deploying inaccessible software. This service provides peace of mind, knowing that your procurement processes align with the latest accessibility standards and at minimum creating a documented paper trail that you have assessed third-party software vendors and provided them with a notice of non-compliance when applicable. Your team should not assume the legal risk for a third-party software vendor that is not committed to accessibility!

Conclusion: A Collaborative Approach to Accessibility

The EAA is a powerful reminder that accessibility must be at the forefront of both software development and procurement.

For software companies, building a robust accessibility roadmap with a focus on continuous improvement and third-party VPAT ACRs is essential. On the other hand, European businesses must ensure that they are procuring accessible technology, holding their vendors accountable, and utilizing amazing resources like Disability:IN’s Procure Access ToolKit.

By working together, software companies and European businesses can create a more inclusive digital landscape, ensuring that all users, regardless of ability, have equal access to technology. Allyant is here to support both sides of this equation, offering expert guidance, testing, and services like ProcureEnsure to help you navigate the EAA and beyond.

For more information on how Allyant can help your organization meet its accessibility goals, whether through VPAT ACRs or accessible procurement, please reach out to our team.

The post Navigating the European Accessibility Act: Why Software Companies Need a Strong Accessibility Roadmap first appeared on Allyant.