Forms Are Failing Because Accessibility Stops at the Homepage

Allow me to politely express my frustration, as this is an issue encountered all too frequently. 

When organizations talk about accessibility, the focus almost always lands on the website. Sometimes it goes a step further and lands on just the homepage. Navigation gets reviewed, color contrast on the hero banner is adjusted, a few images get alt text, and it looks like progress has been made. 

But then you click “Apply,” “Register,” or “Request Service,” and suddenly accessibility disappears. 

That’s the problem. 

At the point of data capture (forms) digital experiences stop being informational and start becoming transactional. They are how people apply for benefits, request permits, submit complaints, onboard as employees, open accounts, or access healthcare. In many cases, the form is the service. Yet accessibility efforts frequently stop right before this most critical interaction. 

If accessibility is limited to the homepage, it’s incomplete. And if forms are inaccessible, people are effectively locked out at the exact moment they need to access the most. 

This isn’t just a design gap; it’s a measurable, widespread failure. 

This isn’t a hypothetical issue. The data tells a very clear story. 

Nearly 70% of online forms contain accessibility barriers, meaning most digital forms actively prevent a significant portion of users from completing tasks independently. 

Now consider the scale of who that impacts. 

Globally, approximately 16% of the population, around 1.3 billion people, live with a disability. In the United States alone, more than 20% of adults, roughly 70 million people, identify as having a disability, according to the Centers for Disease Control and Prevention (CDC). These users are not edge cases. They are citizens, customers, employees, students, and patients. 

When forms aren’t accessible, the impact is immediate and tangible. Inaccessible forms lead to abandoned submissions, increased support calls, slower processing times, loss of trust, and delays in essential services. Completion rates drop. Satisfaction suffers. The user experience breaks down at the moment it matters most. 

So, the question becomes: where do we begin fixing this, and how do we do it in a way that actually improves experience? 

To answer that, we need a shared framework for what “accessible” really means. 

The Guiding Hand: Understanding WCAG 

The international gold standard for web accessibility is Web Content Accessibility Guidelines (WCAG). It consists of guidelines that are built around four core, interoperable principles, POUR: Perceivable, Operable, Understandable, and Robust.  

For implementation, WCAG provides testable success criteria that can be objectively evaluated (pass/fail). These criteria are organized into three conformance levels, Level A, Covers the most basic accessibility needs, Level AA, Builds on Level A requirements and addresses the most common real-world accessibility barriers. This is the de facto standard for most legal and policy requirements worldwide, and Level AAA, The highest and most stringent level of accessibility. 

To suit the existing technology space, WCAG produces different versions. The current version of the guidelines is WCAG 2.2, which was published in October 2023. It adds nine new success criteria to the previous version, 2.1. For all new projects and activities, version 2.2 should be used as reference. Generally, aiming for WCAG 2.2 Level AA is the recommended minimum standard for robust and compliant forms. 

Mandates Across Different Countries 

WCAG being international standards, is used by many countries to enforce accessibility. In the United States, the Department of Justice has made it clear that state, local, and federal entities must ensure their digital content, including online forms, meet recognized accessibility standards. Enforcement actions consistently point to WCAG 2.1 Level AA as the expected benchmark.  

In Canada, accessibility requirements are similarly mandated through federal and provincial legislation, including the Accessible Canada Act (ACA) and laws such as Accessibility for Ontarians with Disabilities Act (AODA), which also align to WCAG 2.1 Level AA expectations for web content, documents, and digital forms. 

Across both countries, the message is consistent: accessibility is a civil rights requirement, and an accessible homepage does not meet that obligation if the form itself is inaccessible. And that accessibility is no longer something organizations can postpone indefinitely. The timelines are defined, and enforcement is real. 

The Most Common Accessibility Issues We See in Forms 

Understanding the standard is one thing. Seeing how it fails in practice is another thing. 

To bridge the gap between standards and real‑world experience, here are some of the most common accessibility issues that repeatedly show up in forms, so you can start visualizing these barriers, rather than just reading about them. 

• Missing or unclear labels are frequent problems. Placeholder text alone doesn’t provide enough context for screen reader users. WCAG requires form inputs to have programmatic labels that explain their purpose. 

• Insufficient color contrast is another issue. Text must have minimum contrast ratios, 4.5:1 for normal text and 3:1 for large text, to be readable for everyone, especially users with low vision. 

• Error handling often fails when errors are shown only by color or aren’t announced to assistive tech. WCAG calls for errors to be described in text, linked to the right field, and include instructions to fix them. 

• Keyboard access is another barrier. Forms that require a mouse, have poor tab order, or trap keyboard focus exclude users who rely on keyboards. Invisible focus indicators also make navigation harder. 

• Zoom and reflow issues matter, too. WCAG says forms must work at 400% zoom, maintaining usability without forcing horizontal scrolling and keeping labels and inputs visible. 

  
  

Now that we’ve understood where forms commonly fail, the next question is how to move from awareness to action. A simple, hands‑on approach to testing your own forms can help uncover the most painful barriers users face

Testing Your Own Forms: A Simple Hands‑On Exercise 

Accessibility can feel overwhelming, especially when the scope isn’t clear, and the standards feel abstract. When that happens, the hardest part isn’t fixing issues; it’s knowing where to begin. 

A practical way forward is to narrow the focus. Start with one form, ideally the one that’s most used, most visible, or most critical to accessing a service. Instead of trying to assess everything at once, begin with manual testing, using the approach outlined below. 

To make this tangible, try the following short exercise. It’s designed to help you experience form accessibility the way users do, outside of a visual, mouse‑driven workflow. 

Step 1: Choose a Real PDF Form 

Select one in‑use PDF form, ideally one users rely on to access a service or submit required information. Avoid samples. 

Step 2: Test with a Screen Reader 

Open the PDF using NVDA. Navigate without looking at the screen. 

Focus on: 

• Whether fields and labels are announced clearly 

• Whether instructions are read at the right time 

• Whether required fields are communicated 

• Whether the reading and navigation order makes sense 

  
  

Ask yourself: Could someone complete this form independently using only what they hear? 

Step 3: Run Accessibility Check 

Scan the same PDF in Adobe Acrobat using “Accessibility Check” to identify issues like missing tags, structural problems, language settings, and contrast failures. Remember: passing a scan doesn’t mean the form is usable. 

Step 4: Validate with PAC 

Run the form through PAC to uncover WCAG and PDF/UA issues related to structure, tagging, tab order, and semantics - problems automated tools often miss. 

Step 5: Compare the Results 

Compare what each method revealed: 

• What the screen reader exposed 

• What tools flagged 

• Which issues block form completion 

  
  

This is where a key insight emerges; most accessibility failures sit at the intersection of usability and structure - not just compliance. 

A Sustainable Path Toward Accessible Forms 

Once you’ve seen the issues firsthand, the next step is transforming that insight into steady, sustainable progress. Successful accessibility programs follow a structured roadmap: they begin by defining scope and ownership, then inventorying all forms, whether public-facing, internal, legacy, or embedded. From there, teams prioritize high-impact and high-risk assets, documenting specific gaps to remediate strategically rather than attempting to fix everything at once. To prevent regression, accessibility must be deeply embedded into ongoing workflows, including design, development, QA, and vendor selection. Ultimately, accessibility is not a one-time project; it is a continuous program. 

Where AI Fits into Accessibility Conversation 

Accessibility isn’t only about fixing what’s broken; it’s about improving how people complete tasks. 

AI‑powered voice forms like DARIAN can make form completion more inclusive by allowing users to choose voice or typing, offering intelligent prompts, and integrating seamlessly with existing systems. Instead of forcing users to adapt to rigid form structures, forms adapt to users, reducing errors, lowering abandonment, and improving experience while remaining compliant. 

You Are More Capable Than You Think 

At this point, you already have more power than you may realize. You can test your own forms. You can identify accessibility gaps. You can map issues directly to WCAG success criteria and understand what needs to change. 

Now the question is what you do with that insight. 

If you want to go further, whether that means remediating complex forms, modernizing legacy systems, or exploring AI‑enabled accessibility with DARIAN - that’s where we can help. 

Accessibility starts with awareness. It succeeds with action.