Resources

Practical guidance for accessibility compliance

Case studies, guidance documents, and questions we hear regularly from program managers, procurement teams, IT leads, and compliance officers. If something is not covered here, get in touch.

Guides

Designed to help teams apply accessibility requirements in real work. These guides translate accessibility standards into practical actions for designers, developers, content owners, program managers, and oversight roles responsible for implementation and review.

Compliance

Section 508 and the ADA

A brief explanation of the two primary accessibility frameworks in the United States, who they apply to, and what they actually require.

Read

10 minute read

Digital accessibility compliance in the United States is primarily governed by two legal frameworks: Section 508 of the Rehabilitation Act and the Americans with Disabilities Act. Understanding which applies to your organization, and what each requires, is the starting point for any compliance effort.

Section 508

Section 508 applies to federal agencies and to organizations that receive federal funding or provide electronic and information technology products or services to the federal government. If your organization sells software to a federal agency, publishes content using federal grant funding, or operates as a federal contractor, Section 508 almost certainly applies to you.

Section 508 was updated in 2017 to reference WCAG 2.0 Level AA as its technical standard. In practice, most organizations now target WCAG 2.1 Level AA, which is a superset of 2.0 and the standard referenced by more recent guidance and procurement requirements.

The ADA

The ADA is a civil rights law that prohibits discrimination on the basis of disability. Title II covers state and local governments; Title III covers places of public accommodation, which courts and the Department of Justice have increasingly interpreted to include websites and digital services operated by private businesses.

Unlike Section 508, the ADA does not specify a technical standard by statute. However, the DOJ's 2024 final rule under Title II explicitly adopted WCAG 2.1 Level AA as the standard for state and local government websites and mobile applications, with compliance deadlines phased by entity size.

What this means in practice

For most organizations, the applicable technical standard is the same regardless of which framework applies: WCAG 2.1 Level AA. The key differences are in who is subject to the requirement, what the enforcement mechanism looks like, and what remediation timelines are expected.

Federal agencies and their contractors face the most structured requirements, including specific procurement obligations and program management expectations. State and local governments are now subject to explicit regulatory requirements under the ADA. Private businesses face litigation risk under Title III, which has been a significant source of demand letter activity in recent years.

Not sure which applies to you? The answer is often both. Organizations that serve the federal government, operate as state or local agencies, and conduct public-facing business may be subject to Section 508, Title II, and Title III simultaneously. Each has different enforcement mechanisms but largely overlapping technical requirements.

Program management

How to read an accessibility audit report

Most audit reports are written for developers. This guide explains how to interpret findings, understand severity, and identify what requires your attention.

Read

12 min read

An accessibility audit report can run hundreds of pages and contain thousands of individual findings. For program managers, compliance officers, and others who need to act on these reports without a technical background, the volume and terminology can make it difficult to know where to begin. This guide explains how to approach a report as a non-developer.

What an audit actually measures

Most audits test a product's conformance against WCAG (Web Content Accessibility Guidelines) at Level AA. Each WCAG criterion defines a specific requirement, such as whether images have text descriptions, whether interactive elements can be operated with a keyboard, or whether form fields have clear labels. An audit checks each criterion against the product being tested and records whether it passes, fails, or is not applicable.

What an audit does not usually tell you is why the failures exist, who is responsible for fixing them, or how they should be prioritized. That analysis has to happen separately.

How to read the findings

Start with the summary section if the report has one. Look for the total number of distinct issues, not the total number of instances. A single underlying problem (such as missing image descriptions) may appear hundreds of times across a website, but fixing the root cause resolves all instances at once. Raw instance counts tend to make reports look more severe than they are.

Next, look for any severity classification. Reputable auditors will classify findings by their impact on users with disabilities (e.g., critical, high, moderate, low). Issues classified as critical typically prevent a user from completing a task entirely. These should be your starting point.

What to do with the findings

A common mistake is to hand the report directly to a development team and ask them to start fixing things. Without a prioritized plan, teams often fix the easiest or most recently discovered issues rather than the most important ones.

Before mobilizing a remediation effort, it is worth spending time categorizing findings by their legal exposure, their impact on users, and the effort required to fix them. This is the work of a Roadmap, and it is what separates organizations that make sustained progress from those that repeatedly revisit the same problems.

A useful question to ask: "If we addressed only the findings in this report that carry meaningful legal exposure, what would that list look like?" That shorter list is almost always where to start.

Procurement

What to require from vendors on accessibility

How to write accessibility requirements into RFPs, evaluate ACRs accurately, and hold vendors accountable for what they commit to.

Read

15 minute read

Accessibility requirements are now standard in many procurement processes, but the language used to express them varies enormously in quality. A requirement that says "the vendor shall comply with WCAG (Web Content Accessibility Guidelines) 2.1" sounds thorough but creates almost no accountability on its own. This guide covers what works in practice.

Why most procurement language fails

The most common failure is treating accessibility as a checkbox rather than a verifiable deliverable. Requiring vendors to "support WCAG 2.1 AA" without specifying how conformance will be tested, documented, or maintained means that any vendor can self-certify compliance and satisfy the requirement on paper.

The second most common failure is accepting an Accessibility Conformance Report (ACR) at face value, especially if it is self-reported. An ACR is a document that describes how well a digital product or service meets accessibility standards. Its quality depends on whether the product was tested against each criterion accurately. ACRs can overstate conformance or use vague language to obscure gaps.

What to include in a Request for Proposal (RFP)

Effective procurement language specifies the standard (WCAG version 2.1 level AA is the baseline for most contexts), the testing methodology (automated plus manual testing by a qualified evaluator), the deliverable (an ACR with documented test results, not just a summary), and the timeline (testing should occur on the version being delivered, not a prior release).

You should also require a remediation commitment. If testing reveals issues after contract award, the vendor should be contractually obligated to address them within a defined time frame, and you should have a mechanism to verify that remediation has occurred.

Useful language: "The vendor shall provide an Accessibility Conformance Report (ACR) prepared using the VPAT 2.x template, based on testing conducted against WCAG 2.1 Level AA by a qualified accessibility evaluator. Testing shall be performed on the version of the product delivered under this contract within 90 days of delivery."

How to evaluate an Accessibility Conformance Report (ACR)

When reviewing a ACR, look for specificity. Reliable ACRs include notes on how each criterion was tested and what specific issues were found. Each criterion tested will have a designation of "supports", "partially supports", "not applicable", or "not tested" to provide a high level overview. There must be additional documentation that provides detail about what issues were found and where.

Be skeptical of ACRs that claim full conformance across every criterion. Virtually no complex software product fully conforms to WCAG 2.1 AA without exception. An ACR that shows no issues at all is more likely to be inaccurate than a product that genuinely has none.

Also check the date. An ACR produced two years ago may not reflect the current version of the product, especially if it hasn't been updated since.

Ongoing accountability

Procurement does not end at contract award. Include a requirement for updated ACRs when major product updates are released, and a process for reporting and resolving accessibility issues discovered by your users after deployment. Vendors that take accessibility seriously will not object to these requirements.

Program management

Assigning accessibility ownership

When accessibility is everyone’s responsibility, it can become no one’s. This guide provides a practical framework for assigning clear ownership without creating a bottleneck.

Read

14 min read

One of the most consistent findings in organizational accessibility assessments is diffuse or absent ownership. Accessibility gets treated as a shared value rather than a defined responsibility, which means that when something goes wrong, there may be no one clearly accountable for fixing it or preventing it from happening again.

The three types of ownership organizations need

Effective accessibility governance requires three distinct types of ownership that are often conflated or left undefined. The first is program ownership: someone is responsible for the accessibility program as a whole, maintains the organization's standards, tracks compliance posture over time, and is the point of escalation when questions arise. This is typically a program manager or compliance officer.

The second is functional ownership: within each team or department, someone is responsible for ensuring accessibility requirements are met in their area of work. Designers own accessibility in the design phase; developers own it in the development phase; content authors own it in the content they produce. These are not separate accessibility roles but existing roles with defined accessibility responsibilities.

The third is vendor ownership: someone is responsible for monitoring and enforcing accessibility commitments from third-party vendors This is often overlooked and is a significant source of compliance gaps in organizations that rely heavily on purchased or licensed software.

Common failure patterns

The most common failure is centralizing all accessibility responsibility in a single specialist or team. This creates a bottleneck that cannot scale and a single point of failure when that person leaves. Accessibility work is too broadly distributed across an organization to be managed by one role alone.

The second most common failure is assigning accessibility ownership to QA or testing teams only. Testing can identify problems, but it cannot fix the design and development practices that created them. Ownership needs to exist upstream in the process.

A practical starting point

If your organization currently has no clear accessibility ownership structure, the most useful first step is a simple mapping exercise: for each type of digital content or product your organization produces, identify who currently makes the decisions that affect accessibility and whether they know it. That mapping will show you where ownership is working and where it is absent.

A useful test: If an accessibility issue was discovered in your organization's most public-facing digital product today, could you identify within one business day who is responsible for resolving it? If not, you do not have a functioning ownership structure yet.

Articles

Focused perspectives on digital accessibility strategy, risk, governance, and operational execution. These articles explore recurring challenges, emerging regulatory considerations, and program-level decisions that influence long-term sustainability and risk management.

Technical

The limits of automated accessibility testing

A look at what automated accessibility testing tools can and cannot detect, why scan results alone are an unreliable basis for compliance claims, and what a complete testing program actually requires.

Read

7 min read

Automated accessibility testing tools have improved substantially over the past several years and now form a standard part of many development workflows. Their limitations, however, are less widely understood than their capabilities, and organizations that rely on them exclusively tend to have a false sense of their compliance posture.

What automated tools can find

Automated tools are effective at identifying a specific category of accessibility failures: those that can be detected by analyzing the structure and attributes of HTML without any understanding of context or meaning. Missing image alt text, form fields without labels, insufficient color contrast ratios, and certain keyboard navigation failures all fall within what automated tools handle well.

Studies consistently find that automated tools can detect somewhere between 25 and 35 percent of WCAG 2.1 AA failures. The figure varies depending on the product and the tool, but the ceiling is well below 50 percent for any tool currently available.

What automated tools cannot find

The majority of WCAG failures require human judgment to identify. Whether an image description is accurate and meaningful, whether a complex interactive component is usable with a screen reader, whether the reading order of a page makes sense when navigated non-visually, whether error messages are clear and helpful: none of these can be evaluated by analyzing code alone.

Automated tools also cannot replicate the experience of an actual user with a disability using assistive technology. A form may pass every automated check and still be completely unusable to a screen reader user because of how focus is managed or how dynamic content is announced.

What this means for compliance programs

Automated scanning is a useful part of an accessibility program, particularly for catching regressions early in the development cycle. It is not a substitute for manual testing, and scan results alone should not be used to draw conclusions about a product's overall compliance posture.

Organizations that report scan results to leadership as evidence of compliance are providing an incomplete picture. A product that passes all automated checks may still have significant accessibility failures that expose the organization to legal and reputational risk. Compliance claims should be based on testing programs that include both automated and manual evaluation by qualified reviewers.

A useful benchmark: If your accessibility testing process consists entirely of automated scans, you are evaluating roughly a third of what matters. Manual testing by a qualified evaluator, using assistive technologies, is required to assess the rest.

Risk

The hidden cost of widgets and overlays

Why third-party scripts and embedded tools are often overlooked in accessibility programs, who bears legal responsibility when they fail, and what procurement and review practices reduce that exposure.

Read

8 min read

Most organizations focus accessibility efforts on content and functionality they build and control directly. Third-party scripts, widgets, and embedded tools receive far less scrutiny, and in many cases none at all. This is a significant gap, because legal responsibility for accessibility does not end at the boundary of internally developed code.

What counts as your responsibility

Under both the ADA and Section 508, organizations are generally responsible for the accessibility of their digital properties as a whole, including components provided by third-party vendors. A chat widget that is inaccessible to keyboard users, a cookie consent banner that traps screen reader focus, or an analytics-driven personalization script that disrupts assistive technology: these are your organization's accessibility problems, not the vendor's, from a legal standpoint.

This does not mean organizations are powerless. It means the responsibility for ensuring third-party components meet accessibility standards sits with the organization procuring them, not with the vendor alone.

The most common offenders

Live chat widgets are among the most frequently cited third-party accessibility failures. Many inject DOM elements that interrupt screen reader navigation, trap keyboard focus, or use custom interactive patterns that do not work with assistive technologies. Cookie consent and privacy compliance tools present similar problems. They are often added late in a development cycle by non-technical teams, and tend to receive minimal accessibility review.

Embedded video players, social sharing components, advertising scripts, and A/B testing tools are also frequent sources of accessibility failures. These tools are often chosen for commercial reasons with no consideration of accessibility at all.

A more manageable approach

The most effective approach is to treat third-party tools as subject to the same procurement standards as any other vendor product: require accessibility documentation before integration, test new components before deployment, and establish a process for reviewing accessibility when vendors release major updates.

For organizations with a large existing inventory of third-party scripts, a useful first step is a simple audit of what is running on your pages and whether any of it has been evaluated for accessibility at all. In most cases, a handful of high-traffic, high-interaction components represent the bulk of the risk and are the right place to start.

Legal

Landmark ADA lawsuits and implications

Three key ADA cases, the precedents they set, and what the broader litigation trend means for your organization's exposure.

Read

10 minute read

Digital accessibility litigation has grown significantly over the past decade. Understanding the cases that shaped current expectations can help organizations assess their own exposure and make more informed decisions about where to invest compliance effort.

Robles v. Domino's Pizza (2019)

Guillermo Robles, who is blind, sued Domino's after being unable to order food through their website and mobile app using a screen reader. The Ninth Circuit ruled that the ADA applies to websites and apps that have a nexus to a physical place of public accommodation, rejecting Domino's argument that applying the ADA to digital properties required clearer regulatory guidance from Congress or the DOJ. The case established a durable precedent that private businesses with physical locations cannot treat their digital presence as outside the ADA's reach.

The implication for most organizations: having a physical presence and an inaccessible website is a clear exposure. Domino's eventually settled, and the case has been cited in hundreds of subsequent lawsuits.

Rizzi v. Morgan Stanley (2018)

Albert Rizzi, a blind New York nonprofit founder, sued Morgan Stanley after being unable to access his own retirement accounts through their website using screen reader software. Before filing, Rizzi offered his organization's accessibility services to Morgan Stanley free of charge to fix the issues. They never responded. The case, filed in federal court in Brooklyn, sought $9 million in damages and alleged that the bank's inaccessible online wealth management tools violated the ADA. Morgan Stanley settled, with terms kept confidential.

The case is notable for extending ADA exposure into financial services, where inaccessibility carries consequences beyond mere inconvenience. A client who cannot independently read their own statements or monitor their retirement savings is shut out of managing their financial life entirely.

NAD v. Harvard and MIT (2019-2020)

The National Association of the Deaf sued both Harvard and MIT in 2015 after finding that their publicly available online course content either lacked closed captions or featured captions too inaccurate to be useful. Both universities fought the cases for years, losing multiple motions to dismiss along the way. Harvard settled in 2019 and MIT in 2020, with both consent decrees requiring comprehensive captioning across lectures, live-streamed events, and content hosted on platforms like YouTube and SoundCloud.

The settlements are widely cited as the most comprehensive online accessibility requirements ever imposed on higher education institutions. For any organization that publishes video or audio content publicly, the cases established that the ADA's reach follows that content regardless of where it is hosted.

The broader pattern

ADA Title III website accessibility lawsuits grew from a few hundred per year in the mid-2010s to several thousand per year by the early 2020s. A small number of law firms drive a significant portion of this volume, targeting organizations with inaccessible websites, sending demand letters, and filing suit when organizations do not respond or remediate promptly.

The organizations that navigate this environment best tend to have two things in common: a documented compliance program that demonstrates good-faith effort, and a process for responding promptly and constructively when accessibility complaints are received. Neither requires perfect conformance. Both require treating accessibility as an ongoing organizational commitment rather than a one-time project.

Note: This article is for informational purposes only and does not constitute legal advice. Organizations facing specific legal questions should consult qualified legal counsel.

Glossary

Key terms used in digital accessibility compliance, defined in plain language for practitioners, program managers, and procurement teams.

A B C D E F H I N O P R S T V W

A

Accessibility Conformance Report (ACR)

A document describing how well a technology product meets accessibility standards. Produced by vendors and commonly required during procurement. Quality depends on whether it was based on third-party testing or self-assessment.

See also:

VPAT,WCAG

Americans with Disabilities Act (ADA)

A federal civil rights law prohibiting discrimination against people with disabilities. Title II covers state and local governments; Title III covers most private businesses. The DOJ finalized specific WCAG 2.1 AA requirements for Title II entities in 2024.

See also:

Section 508

Alternative text

Text added to an image in HTML that describes what the image shows or communicates. Screen readers read it aloud for people who are blind or have low vision. Decorative images that add no meaning should include empty alt text so screen readers skip them.

Accessible Rich Internet Applications (ARIA)

ARIA (Accessible Rich Internet Applications) are a set of HTML tags and attributes standardized by the W3C (World Wide Web Consortium) in order to make rich internet applications accessible to assistive technology.

Assistive technology

Hardware or software that helps people with disabilities use digital products. Examples include screen readers, voice control software, magnification tools, and switch access devices. Accessibility compliance means ensuring digital products work reliably with common assistive technologies.

B

Baseline testing

A structured evaluation of a digital product's current accessibility status before remediation begins. It documents existing barriers and serves as the benchmark for measuring improvement over time.

Barrier

Any design, content, or technical feature that prevents a person with a disability from accessing or using a digital product. Barriers can be visual, auditory, cognitive, or motor in nature.

Branded accessibility statement

A public-facing page on a website or app declaring the organization's accessibility goals, known limitations, and contact information for users who encounter barriers. Increasingly required by law in the EU and recommended as best practice elsewhere.

C

Compliance posture

An organization's overall standing with respect to its accessibility obligations. Reflects not just the state of specific products but how well accessibility is managed over time: whether roles are defined, standards applied consistently, and issues resolved reliably.

Conformance

The degree to which a digital product meets a defined accessibility standard. WCAG conformance is assessed at three levels: A (minimum), AA (the standard referenced by most regulations), and AAA (enhanced). Most legal requirements reference WCAG 2.1 Level AA.

See also:

WCAG

D

Defect taxonomy

The classification system used to categorize accessibility issues by type, severity, and impact during an audit or review.

Degradation

The process by which a digital product becomes less accessible over time as new features, content, and third-party components are added without accessibility review. Degradation is one of the most common reasons organizations that once had accessible products find themselves out of compliance.

Document Object Model (DOM)

The structured representation of a webpage that browsers create from HTML. Assistive technologies like screen readers interact with the DOM to communicate page content to users, making its structure critical to accessibility.

E

EN 301 549

A European standard that defines accessibility requirements for ICT products and services. It is the technical basis for the European Accessibility Act and closely references WCAG for web-based content.

European Accessibility Act (EAA)

EU legislation requiring private sector companies to meet accessibility standards for key digital products and services. It became enforceable in June 2025 across EU member states.

F

Fidelity

How accurately a digital product communicates its structure and intent to assistive technologies.

Focus management

The practice of programmatically controlling where keyboard focus moves during interactions, such as opening a modal or navigating a single-page application. Poor focus management is a common barrier for keyboard and screen reader users.

Fragmentation

Inconsistencies across pages, platforms, or devices that create unpredictable experiences for users of assistive technology.

H

Heuristic evaluation

An expert review method where an accessibility specialist assesses a digital product against established usability and accessibility principles. It provides faster, lower-cost findings than a full WCAG audit, though less comprehensive.

HTML semantics

The use of HTML elements according to their intended meaning — such as using a button element for clickable actions instead of a styled div. Semantic HTML is the foundation of accessible web development.

Human-computer interaction (HCI)

The field of study covering how people interact with technology. Accessibility overlaps significantly with HCI research.

I

International Association of Accessibility Professionals

The global professional body for accessibility practitioners. IAAP administers widely recognized credentials including the CPACC and WAS certifications, which are increasingly used by organizations to evaluate the expertise of accessibility consultants and vendors.

Information and communications technology (ICT)

A broad term for digital systems used to store, transmit, or process information. Many accessibility laws and standards — including Section 508 and EN 301 549 — apply specifically to ICT products and services.

Input modality

The method a user uses to interact with a device, such as keyboard, mouse, touch, voice, switch, or eye tracking. Accessible products support multiple input modalities.

N

Narrator

The screen reader functionality built-in to Windows.

Nonvisual Desktop Access (NVDA)

An open-source screen reader developed both by and for blind users.

O

Optical Character Recognition (OCR)

Optical character recognition is a method of recognizing written text and turning it into a digital document on a computer, primarily used by those who are blind and unable to read printed text.

P

Perceivable

One of the four WCAG principles (POUR). Means all content must be presentable in ways all users can perceive.

Plain language

Writing that is clear, concise, and easy to understand. Supports users with cognitive disabilities, low literacy, and non-native speakers.

R

Remediation

Fixing identified accessibility issues in a digital product. Without process changes to prevent new issues from being introduced, remediation tends to be a recurring cost rather than a lasting fix.

Risk tiering

Categorizing accessibility findings by their legal, reputational, or operational consequences. Allows organizations to direct remediation effort toward issues that matter most rather than treating all findings as equally urgent.

S

Section 508

A section of the Rehabilitation Act of 1973 requiring federal agencies to make their electronic and information technology accessible to people with disabilities. Also applies to organizations that receive federal funding or provide technology to the federal government.

See also:

ADA,WCAG

Substantial compliance

A legal concept describing a level of compliance that, while not perfect, demonstrates genuine good-faith effort to meet accessibility requirements. Organizations with a documented program, clear accountability, and active remediation are generally better positioned in enforcement proceedings.

T

TalkBack

The primary screen reader on Android devices

Talon

Talon Voice is speech recognition and voice control software that allows users to operate a computer entirely by voice. It is primarily used by people who cannot, or prefer not to, use a keyboard, mouse, or trackpad.

V

VoiceOver

The screen reader functionality on Apple products

VPAT (Voluntary Product Accessibility Template)

A standardized template used by technology vendors to document how their products conform to accessibility standards. A completed VPAT is called an ACR. VPATs are self-reported; reliability depends on whether the vendor tested their product.

See also:

ACR

W

WCAG (Web Content Accessibility Guidelines)

The primary international standard for web accessibility, published by the W3C. Organized around four principles: content must be Perceivable, Operable, Understandable, and Robust. WCAG 2.1 Level AA is the standard referenced by most U.S. regulatory requirements.

See also:

Section 508,Conformance

Frequently asked questions

Key terms used in digital accessibility compliance, defined in plain language for practitioners, program managers, and procurement teams.

How do we know if we're compliant?

For most regulations like ADA and Section 508, compliance technically means that all of your digital products and services support every WCAG criterion at Level A and Level AA. An audit will tell you where you stand by producing an Accessibility Conformance Report, which documents how well a digital product supports each criterion.

Where should we start if we have no existing accessibility program?

The right starting point is understanding where you stand. Before setting priorities or allocating resources, you need a clear picture of your current compliance posture, where your highest risks are, and whether your organization has the internal structure to make progress. That is what our is designed to provide.

What is the difference between ADA, WCAG and Section 508 compliance?

Section 508 applies specifically to federal agencies and organizations that receive federal funding or contract with the federal government. The ADA is a broader civil rights law that applies to state and local governments (Title II) and most private businesses (Title III). Both frameworks reference WCAG as the applicable technical standard, so the requirements overlap in practice.

How long does a typical engagement take?

It depends on scope and type, but for a rough estimate: An for a mid-size organization can take anywhere from two to six weeks from kickoff to final deliverables. An organizational Checkup can take another four to eight weeks. A Roadmap built on Checkup findings can add two to four weeks. Setting up a Workflow and Training can add several weeks or months, depending on scope. Task-level services like a Review or Correction engagement are generally completed within one to two days per page or screen depending on product complexity. We provide a clear timeline at the start of every engagement.

What is our legal exposure if we are not compliant?

We are not lawyers and this is not legal advice. Generally speaking, organizations with no documented program and no demonstrated good-faith effort face greater exposure than those that can show structured, ongoing work. The existence of a reasonable compliance program is often a relevant factor in enforcement proceedings. We recommend consulting qualified legal counsel for specific legal questions alongside any accessibility assessment work.

Do you work with organizations that already have an in-house accessibility team?

Yes, and often that is where our work is most useful. In-house teams typically have deep technical knowledge but limited capacity for program-level analysis or governance design. We work alongside internal teams to address structural and organizational questions that are harder to answer from the inside. We are not trying to replace internal expertise. We are trying to give it a better operating environment.

How do we know if an Accessibility Conformance Report we received is reliable?

Reliable Accessibility Conformance Reports (ACRs) acknowledge exceptions and provide specific notes explaining what those exceptions are. They identify the testing methodology used and the version of the product tested. Be skeptical of ACRs that claim full conformance across every criterion without exception. Complex software products rarely conform to WCAG 2.1 AA without any issues. Our Verification service is specifically designed to evaluate whether a ACR you have received reflects the actual state of the product.

Why should we prioritize accessibility if we have not had any complaints?

Absence of complaints is not evidence of compliance. Most users who encounter barriers simply leave rather than filing a complaint. From a risk management perspective, no formal complaint to date does not reduce your legal exposure. Organizations that address accessibility proactively are in a significantly stronger position when a complaint or demand letter eventually arrives.

How does Accuity's work compare to other firms?

Many firms typically produce a detailed inventory of what is wrong at the product level. What Accuity focuses on is the organizational question: why problems exist, how to build the structure to address them reliably, and how to sustain that over time. We are often brought in alongside or after a technical audit to help organizations understand what to do with the findings and how to prevent the same issues from recurring.

Accuity is a digital accessibility consulting group using a systematic approach to removing barriers to access and mitigating ADA risk.