Listen to the podcast  Podbean.

The post The State of Accessibility – Episode 16 appeared first on Vispero.

Dialogs are a fundamental component of modern web interfaces, but ensuring their accessibility requires careful attention to multiple WCAG success criteria. This comprehensive guide will walk you through the essential requirements for validating dialog accessibility under WCAG 2.2, following the structured approach you’d expect from accessibility experts.

Why does dialog accessibility matter?

Dialog accessibility is critical because these components interrupt the normal flow of interaction and require users to complete specific tasks before proceeding. When implemented incorrectly, dialogs can trap users, confuse screen reader users, or become completely inaccessible to keyboard-only users. Speech input users, screen reader users, and keyboard navigation users all depend on properly implemented dialogs to maintain their workflow and complete essential tasks.

What are the validation failures?

Let’s begin with what the common WCAG failures are when validating dialog accessibility.

Dialog lacks proper ARIA roles and properties

When a dialog appears without proper semantic markup, assistive technologies cannot identify it as a dialog, leaving users confused about what has appeared on screen.

Failing example

A pop-up appears visually but lacks dialog semantics:

 
<div class="popup-overlay">
  <div class="popup-content">
    <h2>Confirm Delete</h2> 
    <p>Are you sure you want to delete this item?</p> 
    <button>Cancel</button> 
    <button>Delete</button> 
  </div> 
</div> 

Why This Fails:

• The markup visually looks like a dialog, but assistive technologies do not recognize it as a dialog.
• There are no ARIA roles or properties indicating its purpose.
• Users relying on screen readers may not understand that this is a modal dialog requiring attention, leading to confusion or difficulty closing it.

Passing example:

Using proper dialog role

The dialog should include appropriate ARIA roles and properties:

<div role="dialog" aria-modal="true" aria-labelledby="dialog-title" aria-describedby="dialog-desc"> 
  <h2 id="dialog-title">Confirm Delete</h2> 
  <p id="dialog-desc">Are you sure you want to delete this item?</p> 
  <button>Cancel</button> 
  <button>Delete/button> 
</div> 

Why This Passes:

• The role="dialog" attribute explicitly informs assistive technologies that this element is a dialog.
• aria-modal="true" indicates it blocks interaction with the rest of the page until dismissed.
• aria-labelledby and aria-describedby associate the dialog with its title and description, providing context.
• Screen readers will announce the dialog properly, and keyboard focus can be managed to enhance usability.

Explanation of Success:

• role="dialog": This explicitly informs assistive technologies that the element is a user-focusable, interactive dialog container, triggering the correct announcement (e.g., “Confirm Delete, dialog”).
• aria-modal="true": This is critical. It signals that content outside of this dialog is dimmed and inert (should not be accessible to the keyboard or screen reader) until the dialog is closed.
• aria-labelledby="dialog-title": This links the dialog container to its title (<h2>), providing the primary, concise name for the dialog.
• aria-describedby="dialog-desc": This links the container to its main instructional content (<p>), providing an optional longer description for the user.

WCAG Success Criterion: 4.1.2 Name, Role, Value

Focus is not managed correctly

Focus management failures occur when the dialog opens but keyboard focus remains on the underlying page, or when focus escapes the dialog while it’s open.

Failing example:

The dialog opens, but the focus remains on the trigger button behind the modal overlay, making it impossible for keyboard users to interact with the dialog.

Passing example:

When the dialog opens, focus moves to the first focusable element within the dialog (or the dialog itself), and tabbing is constrained within the dialog until it closes.

Important Note: Focus Return on Close

When the dialog closes, focus should be returned to the element that triggers the dialog.

Warning:

• Ensure that the trigger element still exists in the DOM when closing the dialog.
• If the trigger has been removed dynamically (e.g., through DOM manipulation), attempting to return focus to it can cause errors or focus loss.
• Verify the trigger element is present before setting focus back to it.

WCAG Success Criterion: 2.4.3 Focus Order

Accessible name does not match visible text

Dialog buttons and controls must have accessible names that contain their visible label text to support speech input users.

Failing example

A close button shows “×” visually but has aria-label="Close popup window":

<button aria-label="Close popup window">×</button> 

Passing example:

The accessible name should begin with or exactly match the visible text:

<button aria-label="Close">Close</button> 
 

WCAG Success Criterion: 2.5.3 Label in Name

Focus becomes obscured

WCAG 2.2 introduces new requirements ensuring focused elements aren’t hidden by sticky headers, footers, or other overlapping content.

Failing example:

A focused button in the dialog is completely hidden behind a sticky header when the dialog scrolls.

Passing example:

Focused elements within the dialog remain at least partially visible (Level AA) or completely visible (Level AAA).

WCAG Success Criterion: 2.4.11 Focus Not Obscured (Minimum)

WCAG Success Criterion: 2.4.12 Focus Not Obscured (Enhanced)

Dialog cannot be closed accessibly

Users must be able to close dialogs using keyboard methods, typically the Esc key, in addition to any visible close buttons.

Failing example:

Dialog can only be closed by clicking on a small “×” button with a mouse.

Passing example:

Dialog supports Esc key closure and has clearly labeled close options that work with keyboard navigation.

Exceptions:

There are cases where dialogs cannot be closed with the Esc key, such as legal notices that require user acknowledgment through activating a button before closing.

WCAG Success Criterion: 2.1.1: Keyboard

Step-by-Step Validation Process

1. Verify Semantic Structure

Check for proper ARIA implementation:

• Dialog container has role="dialog"
• Modal dialogs include aria-modal="true"
• Dialog has aria-labelledby pointing to its title
• Dialog has aria-describedby for additional context when needed

2. Test Keyboard Navigation

For focus management validation, check that:

• Focus moves into the dialog when it opens
• Tab and Shift+Tab cycle through focusable elements within the dialog only
• Focus cannot escape to background content while dialog is open
• The Esc key closes the dialog
• Focus returns to the triggering element when the dialog closes
• Background content does not scroll while the dialog is open

3. Screen Reader Testing

For assistive technology validation, check that:

• Screen readers announce the dialog role and title when opened
• All dialog content is available to screen readers
• Error messages and form validation are announced properly
• To ensure coherent screen reader experience, dialog markup should appear near the end of the DOM, and all elements should be in logical tab and reading order.
• Background content becomes inert and unavailable to screen readers

Note: Some screen readers allow users to “escape” modals using virtual cursor mode. While you cannot prevent virtual cursor navigation, ensure that background content is inert and not reachable via tab stops.

4. Label and Name Validation

For speech input compatibility, check that:

• All interactive elements have accessible names that contain their visible text
• Button labels are descriptive and match what users see
• Form controls within dialogs are properly labeled

5. Visual Focus Testing

For focus visibility validation, check that:

• Focus indicators are clearly visible on all interactive elements
• Focused elements are not entirely obscured by other content (Level AA)
• For enhanced compliance, focused elements are not partially obscured (Level AAA)

Notes:

Testing Tools and Methods

Automated Testing

Automated testing tools like ARC Toolkit can identify certain basic structural issues but remember that even the best automated tools can only catch a relatively low percentage of WCAG failures. This is especially true for dialogs.

Manual Testing Methods

• Keyboard-only navigation: Navigate the entire dialog using only keyboard
• Screen reader testing: Test with NVDA, JAWS, or VoiceOver
• Speech input testing: Verify voice commands work with visible labels
• Focus visibility: Ensure focus indicators meet contrast and size requirements
• Scrolling: Confirm that body scrolling is disabled when the dialog is open and re-enabled when the dialog closes.

Usability Testing with Real Users

Include users with disabilities in your testing process, as they can identify issues that technical testing might be missed.

Best Practices for WCAG 2.2 Conformance

Essential Implementation Guidelines

• Use semantic HTML when possible: The native <dialog> element handles many accessibility requirements automatically, including focus management and backdrop behavior.
• Implement proper focus trapping: Ensure users cannot accidentally navigate outside the dialog while it’s open.
• Provide multiple ways to close: Support both Escape key and visible close buttons.
• Design clear focus indicators: Meet WCAG 2.2 enhanced focus visibility requirements.
• Test with real assistive technology: Automated tools alone are insufficient for dialog validation.

Common Validation Scenarios

Marketing/Newsletter Dialogs

These often appear automatically, but they must not violate focus order requirements or trap users unexpectedly.

Form Validation Dialogs

These must announce errors accessible and maintain focus on the problematic field or error message.

Confirmation Dialogs

Confirmation dialogs should clearly describe the action being confirmed and provide obvious ways for users to proceed or cancel.

Conclusion

By following this comprehensive validation approach, you can ensure your dialogs meet WCAG 2.2 requirements and provide accessible experiences for all users. Remember that dialog accessibility is not just about passing automated tests—it’s about creating usable experiences for people who depend on assistive technologies to interact with your content.

Resources

• W3C ARIA Authoring Practices Guide – Dialog Pattern
• Web Content Accessibility Guidelines (WCAG) 2.2

The post Mastering Dialog Accessibility appeared first on Vispero.

Our monthly Employee Spotlight series gives you a glimpse behind the scenes and brings you closer to the people behind the products at Vispero. This month, we are honoring Olga Espínola, a longtime Vispero team member whose work and advocacy have helped shape Braille and math accessibility across our products. Olga retired this past year after a remarkable career dedicated to access, education, and mentorship.  We sat down with Olga to reflect on her journey, her passion for accessibility, and the legacy she leaves behind.

How long were you with Vispero, and what roles did you hold during your time here?

Olga: I joined Freedom Scientific in early 2003. Over the years, I worked in scripting, testing, and accessibility validation, with a strong focus on Braille and math, as well as localization of the languages supported by JAWS.  I spent my first 7.5 years in scripting and my last almost 15 years in the test department, but I regularly collaborated with engineering, documentation, and the teams in the field.

How did you first become interested in accessibility and assistive technology?

Olga: Accessibility has always been part of my life. I was born totally blind due to congenital glaucoma and lost all light perception by the time I was six. For my own education, especially in math and science. There were no formal state or federal laws for persons with disabilities until 1973, and better laws in 1990.

Your career has touched education, finance, programming, and accessibility. What connects all of those experiences?

Olga: Mentorship connects everything. My life has always been about being mentored and mentoring others. Whenever I learned something new, especially about technology, I shared it with the blind community. I believe knowledge grows when it is shared.

What is one area of Vispero’s products that you are especially proud to have influenced?

Olga: Math and Braille accessibility. For many years, advanced math was simply not accessible to blind users. When I first saw a quadratic formula displayed correctly on a Braille display, it was an emotional moment for me. It meant that blind people could once again fully participate in math and science.

Why is Braille literacy still important today?

Olga: Literacy cannot be audio-only. Braille provides structure, spelling, and deeper comprehension. Fewer than five percent of blind people in the United States read Braille today, and that has serious consequences for education and employment. If you want true literacy, especially in technical subjects, you need something under your fingers.

How would you describe your approach to working with teams at Vispero?

Olga: I focus on details and on what truly matters to users. I ask questions, and I push for improvements because accessibility is always evolving. My goal has always been to help Vispero deliver better products for the people who rely on them.

What advice would you give to people working in accessibility today?

Olga: Never stop learning and never be afraid to share what you know. When people share knowledge, everyone grows. That is how we make accessibility better for the entire community.

What would you like people to remember most about your time at Vispero?

Olga: I hope people remember that I cared deeply about users and about doing the work the right way. I wanted to help make products better and to help people grow along the way.

We also had the pleasure of speaking with Ryan Jones, who worked closely with Olga for many years at Vispero, to better understand her impact from inside the company.

How did Olga impact Vispero from your perspective?

Ryan: Olga was a true advocate for Vispero’s users. She consistently pushed the team to raise the bar for Braille and math accessibility and to stay current with the latest tools and standards. Her attention to detail influenced everyone around her and strengthened our products. She positively challenged us and always kept the focus on what mattered most to users.

The post Employee Spotlight – Olga Espínola’s Story appeared first on Vispero.

As a global provider of meetings, events, and hospitality technology, Cvent recognized that accessibility had become a critical factor in customer trust, procurement decisions, and enterprise adoption. As accessibility expectations rose, particularly among regulated industries, Cvent needed a credible, consistent way to validate its progress and clearly communicate accessibility across its platform. The goal was not only to meet procurement requirements, but to make accessibility a visible, measurable part of product quality and customer confidence.

The challenge

Cvent’s accessibility efforts had grown organically alongside its expanding platform, but a combination of rising client demand and shifting regulatory requirements had resulted in varying levels of accessibility maturity across products. Enterprise customers increasingly required formal proof of accessibility during procurement conversations and RFPs, placing pressure on teams to provide clear, trusted documentation. Cvent needed an established accessibility partner to independently validate its platforms and support transparent, standards-aligned communication with customers. Without a consistent validation approach, accessibility conversations risked slowing deals and undermining confidence in product readiness.

The approach

Cvent partnered with Vispero’s Digital Accessibility Services to independently assess key product experiences and document conformance against recognized standards. Vispero conducted targeted audits of priority workflows and produced Voluntary Product Accessibility Templates (VPATs), giving Cvent credible, third-party validation it could confidently share with enterprise customers and procurement teams.

The outcome

Rather than treating VPATs as a one-time procurement requirement, Cvent used them as a catalyst for accessibility maturity, reexamining accessibility issues that needed additional attention, even after the initial audits. Cvent was able to respond more confidently to customer accessibility inquiries, streamline procurement conversations, and create greater internal alignment around accessibility expectations. Accessibility was also embedded into product workflows, redefining the definition of done and establishing accessibility as a core component of product quality rather than a post-release check.

VPATs aren’t just paperwork; they were key milestones for maturing our organization’s accessibility journey.

— Stephen Cutchins, Sr. Manager of Product Management, Cvent

The impact

Cvent’s approach to accessibility achieved more than one-time compliance. Through its partnership with Vispero, accessibility became a consistent, measurable part of Cvent’s digital experiences—supporting sales, reinforcing customer trust, and positioning accessibility as a durable product differentiator rather than a compliance obligation.

The post Cvent: Making Accessibility a Standard Part of Product Quality appeared first on Vispero.

As a public utility serving diverse communities, East Bay Municipal Utility District (EBMUD) realized that inaccessible digital services were not only a compliance hurdle but also a risk to service equity, employee productivity, and public trust. EBMUD was looking for a clear roadmap to delivering and sustaining accessible services—one that went beyond reactive fixes and scaled across the organization.

The challenge

EBMUD started early, conducting an assessment in the summer of 2025 with the goal of meeting Americans with Disabilities Act (ADA) Title II requirements for web content and mobile applications by the April 2027 deadline. Rather than addressing accessibility through isolated remediation efforts, EBMUD wanted to take a forward-looking approach, understanding current organizational capability and defining a sustainable path to improvement across people, process, and technology.

The solution

EBMUD partnered with Vispero’s Digital Accessibility Services to assess its current accessibility maturity and define a practical, organization-wide roadmap. The engagement combined stakeholder interviews, policy and process review, and maturity modeling to establish a baseline and identify priority actions.

The outcome

Vispero developed a multi-year Digital Accessibility Program roadmap designed to guide EBMUD toward a proactive and sustainable accessibility model. The roadmap emphasized focus on six strategic themes to make a lasting impact over time:

• Establish governance and accountability for accessibility
• Prioritize remediation of public-facing digital content
• Embed accessibility into development, content, and procurement workflows
• Build internal knowledge and long-term capability
• Reduce procurement and vendor risk
• Improve transparency and support

The roadmap positions EBMUD to meet ADA Title II requirements while improving equitable access to essential digital services.

The result

While the pending Title II changes can feel overwhelming, especially for smaller organizations, EBMUD demonstrates how a thoughtful, structured approach can transform accessibility from a reactive obligation into a strategic capability. EBMUD now has a clear path to sustainable accessibility: reducing risk, strengthening public trust, and ensuring digital experiences work for people with disabilities today and into the future.

The post Defining a Digital Accessibility Roadmap: East Bay Municipal Utility District appeared first on Vispero.

In this on-demand webinar, accessibility leaders share how to build a complete accessibility program that scales across your organization. You’ll learn how to inventory digital assets, run automated and manual testing, prioritize issues by risk and user impact, and integrate accessibility into design, development, and QA workflows. The session also covers governance (roles, metrics, reporting), vendor and procurement requirements, and how to sustain compliance over time. Whether you’re just starting or looking to mature your accessibility efforts, this webinar gives you a step-by-step framework to embed inclusion into your culture and processes.

The post Building a Complete Accessibility Program: From an Audit to Long-Term Inclusion appeared first on Vispero.

For many state and local governments, their digital services evolved organically: websites were developed, mobile applications added over time, and, as a result, digital accessibility has been an emerging concern rather than a core operational requirement. Because of this piecemeal evolution, many entities have not taken a strategic approach to accessibility, focusing on reactive fixes over time, without designing to standards, and without validating how services work with the assistive technologies (AT) that blind and low vision users rely on.

Recent updates to Title II of the Americans with Disabilities Act (ADA) changed things. Expectations for accessible websites and mobile applications used to provide services, programs, and activities are now clearer. Enforcement attention has sharpened, and many public entities are reassessing their digital environments to understand what readiness actually looks like and how far they have to go to comply with Title II.

Understanding the new requirements, what they apply to, and where compliance gaps exist can help organizations respond deliberately, without unnecessary disruption or panic.

Why organizations are catching up now

When the ADA was signed into law in 1990, the web was in its infancy, so the legislation’s text lacked explicit references to websites, let alone defining requirements for digital accessibility. For many years, public entities approached digital accessibility requirements based on a mix of court decisions, federal and state guidance, and evolving best practices from the digital accessibility field. This led to inconsistent interpretations, with some organizations focusing narrowly on websites, others relying on reactive remediation, or assuming partial Web Content Accessibility Guidelines (WCAG) conformance was sufficient without testing workflows using AT, like screen readers and screen magnifiers.

That ambiguity has now been removed. In April 2024, the U.S. Department of Justice (DOJ) finalized a rule for Title II digital accessibility, defining requirements for public-sector web content, documents, and mobile applications, removing long-standing uncertainty around how the law applies in digital environments. This rule established a clear, uniform expectation for digital accessibility across state and local government services, providing clarity both for public entities and their vendors.

As a result, organizations are now reevaluating accessibility of online services provided through websites, mobile apps, and documents, with increased attention to how people with disabilities access and engage with those services.

What changed for web and mobile accessibility

The updated Title II rule aligns digital accessibility requirements with WCAG 2.1 Level AA, establishing a consistent and internationally recognized technical baseline for evaluation. Importantly, this requirement includes a range of digital resources used to provide programs, services, and activities:

• Web content, including forms, images, video, and audio
• Digital documents such as PDF and Word files
• Native mobile apps

Examples of programs, services, and activities that might be offered through digital channels include:

• Access to public information, including laws and regulations, emergency plans, or voting locations
• Transactions, such as making payments or applying for services
• Access to education provided by public schools, colleges, and universities

The Title II rule also introduces clear compliance timelines. State and local governments serving populations of 50,000 or more generally have until April 2026 to conform, with extended timelines for smaller entities and special government districts. While these deadlines are important, readiness depends less on speed and more on taking a structured, defensible approach.

WCAG conformance provides a technical reference point, but it does not replace the broader Title II requirement to ensure services are usable by people with disabilities in practice. Additionally, when state or local laws establish higher or more specific accessibility requirements, those requirements apply alongside, and may exceed, Title II obligations.

Common gaps organizations discover

As organizations evaluate digital accessibility more comprehensively, several recurring gaps tend to surface, especially when expanding beyond automated scans and the desktop website experience.

Mobile apps overlooked

Mobile apps are frequently excluded from earlier accessibility efforts or assumed to be accessible by default. In practice, many apps are never tested with screen readers or screen magnification, leading to navigation, labeling, and gesture-related barriers that prevent independent use by blind and low vision users.

This gap is significant given how residents access services. According to the Pew Research Center, about 91% of U.S. adults own a smartphone, and many rely on mobile devices as a primary way to access online information and services. The updated Title II rule explicitly addressed mobile apps in part because they were often overlooked in prior accessibility evaluations.

Online form accessibility issues

Form accessibility, including digital versions of paper forms, remains one of the most common sources of accessibility barriers. PDFs with forms are frequently published without proper structure, labels, or reading order, making them difficult or impossible to use with screen readers.

Form issues don’t just affect PDFs. According to accessibility advocates WebAIM, missing or incorrect form labels are among the most common accessibility errors detected across websites, directly affecting usability for blind and low vision users. Nearly half of all homepages contained missing form input labels in 2025, highlighting how overlooked accessibility is in digital documents when not evaluated with AT functionality in mind.

Lack of keyboard and screen reader support

Interactive elements that require the use of a mouse, have inefficient or illogical focus order, rely on visual cues, or lack alternative text for images can block access entirely for users navigating with keyboards or AT like screen readers. These failures often surface in multi-step workflows, menus, and custom components rather than on individual static pages, particularly when users attempt to navigate or complete tasks using AT.

Overreliance on automation

Automated testing tools are helpful for identifying certain defects, but they cannot evaluate usability or task completion. Even with advances in AI, automated tools still identify only a portion of accessibility issues in a web page or document, leaving many potentially high-impact barriers undiscovered without human review.

Why accessibility must be sustained

A common misconception is that accessibility work is completed once initial conformance is achieved. In reality, digital services are constantly changing, and accessibility can regress over time if it is not maintained and baked into internal processes.

The reality is that public-sector digital environments evolve continuously:

• Content is added or updated; new functionality is introduced
• Vendor-supplied functionality and content changes
• Platforms and frameworks used to build websites and mobile apps evolve
• Operating systems, browsers, and assistive technologies change

Each change can introduce new accessibility barriers if accessibility is not embedded into ongoing processes. Even small updates can disrupt how AT interprets content, navigation, or workflows. To maintain compliance with ADA Title II and to continue to provide equal access for people with disabilities, accessibility must be an operational responsibility, not a one-time remediation effort. Compliance is tied to how services are delivered and maintained over time, including how updates, new content, and system changes are managed.

Sustainable accessibility practices help organizations maintain compliance and optimize user experience while reducing the cost, disruption, and risk associated with repeated retrofits. When accessibility is integrated into regular operations, teams are better positioned to adapt as digital services evolve.

Catching up without panic

The good news is that organizations do not need to fix every issue at once. A pragmatic approach should focus on a clearly defined, strategic commitment to progress, prioritizing the task of assessing and addressing current accessibility barriers while investing in improving processes, tools, and knowledge and skills amongst staff responsible for digital resources.

The most effective path forward starts with understanding the scope and applicability of Title II, inventorying current digital assets, evaluating accessibility through expert-led audits, testing with AT, and prioritizing remediation based on service impact and risk. This approach reflects how regulators evaluate accessibility in practice: by focusing on whether people with disabilities can access and use digital services using AT, not how many tickets were closed.

By focusing on progress, usability, and sustainability, organizations can align with ADA Title II requirements while steadily improving access for constituents and staff. A structured, phased approach helps teams move forward with clarity, without unnecessary disruption or last-minute remediation pressure.

Further reading: Usability testing with people who rely on assistive technology helps ensure digital services are not just technically conformant, but truly usable in real-world scenarios. Learn how usability and accessibility work together by exploring accessibility-focused UX design.

Assess your ADA Title II readiness

For many organizations, the challenge with ADA Title II readiness is knowing where to get started. An accessibility partner can streamline the compliance process, helping organizations navigate complex regulatory rules with confidence.

With over 30 years of experience in AT and accessibility implementation, Vispero’s Digital Accessibility Services help public entities assess current-state accessibility, identify high-impact barriers, and prioritize remediation aligned to ADA Title II requirements. Our expert-led approach supports sustainable accessibility across websites, applications, and digital content, helping agencies reduce risk while improving access for constituents and staff.

Learn how Vispero’s Digital Accessibility Services support ADA Title II readiness for public sector organizations.

The post Catching Up with ADA Title II for Web and Mobile Accessibility appeared first on Vispero.

The post ADA Title II Digital Accessibility Readiness Checklist appeared first on Vispero.

Digital access is a foundational part of access to public services. For state and local governments, websites, mobile apps, and other online services are often the primary way residents interact with agencies, apply for benefits, receive services, pay bills, access critical information, and participate in society.  The Americans with Disabilities Act (ADA) Title II establishes a clear legal requirement that state and local government services and programs must be accessible to people with disabilities. While Title II has been law for decades, the Department of Justice (DoJ) final ruling of 2024 clarified how these obligations apply to digital services, prompting many public entities to reassess what compliance requires and how to demonstrate usable digital accessibility programs.

Why ADA Title II matters now

Digital services are no longer supplemental to government programs. When these services are inaccessible, residents with disabilities are effectively excluded from participation, even if an agency technically offers the service.  Imagine a blind or low vision resident attempting to pay their taxes via an online portal. If the forms collecting information are not labeled correctly, they may be unable to fill in the form, creating an accessibility barrier. The result is a digital service that is available and usable to sighted residents, but fails to provide equal and effective access under Title II.  For blind and low vision users, access to digital services depends on assistive technologies (AT), such as screen readers and screen magnifiers. These tools translate digital content into speech, Braille, or magnified visual displays, allowing users to independently navigate websites and interact with online services. When digital services are not designed to work reliably with assistive technologies (AT), access breaks down. Under Title II, independence and equal access are not optional outcomes; they are core obligations.

What ADA Title II covers in digital environments

Title II applies to all programs, services, and activities provided or funded by state and local governments, regardless of how those services are delivered, not just buildings or individual web pages. As government entities increasingly move interactions online, this obligation extends fully into digital environments.  That includes:

• Public-facing websites providing information

• Mobile apps that deliver services, information, or notifications

• Digital documents, such as PDF and Word files, application forms, reports, meeting minutes, and public notices

• Applications supporting transactions, providing portals to services and activities, and other self-service tools

These digital properties are often interconnected, and a single service may rely on multiple systems, document types, and workflows. Under Title II, accessibility is evaluated across the entire digital experience a service or program provides, and is not restricted to a page or document in isolation. As a result, Title II compliance is not assessed at the feature level, but programmatically, based on whether the service as a whole is accessible. If a disabled resident cannot independently complete a required task, such as submitting an application, accessing time-sensitive information, or paying a fee, the service itself may be inaccessible under Title II, even if individual pages or components appear to meet technical guidelines.  This standard is especially relevant for large government ecosystems, where accessibility gaps often occur at transition points between systems, documents, and workflows rather than within a single page.

Programmatic access and effective communication

Title II requires public entities to provide effective communication and equal access to services for people with disabilities. In digital environments, this requires ensuring that content, workflows, and documents work reliably with screen readers and magnification tools and support real-world use by people who are blind or have low vision. The DoJ has consistently emphasized that effective communication is a core Title II obligation, not a best practice.  At a baseline, effective digital communication includes ensuring that:

• Screen reader users can navigate content and workflows in a logical order

• Screen magnifier users can zoom, pan, and navigate content without loss of information, functionality, or context

• Information is available without relying on color perception

• Interactive elements such as forms can be completed and submitted using the keyboard alone

• Documents are structured so information is conveyed through identifying headings, lists, and table headers using appropriate document styles

• Status messages, notifications, error alerts, and confirmations are available to AT users

Under Title II, accessibility is a service-level obligation, meaning users must be able to use digital services as intended, without unnecessary barriers or workarounds. This distinction is why organizations relying solely on automated testing often struggle to demonstrate Title II readiness. Instead, organizations must evaluate digital accessibility in the context of how services are actually used, not just how components are coded.

How WCAG fits into ADA Title II compliance

To provide clarity for digital accessibility expectations, the DoJ’s final rule specifies that covered websites and mobile applications must conform to Web Content Accessibility Guidelines (WCAG) 2.1 Level AA.  Developed by the World Wide Web Consortium (W3C), WCAG provides a shared technical framework for identifying common accessibility barriers in digital content. Under Title II, WCAG 2.1 Level AA serves as a baseline for evaluation, but it does not replace the broader obligation to ensure services are accessible in practice. Conformance helps identify technical issues, while AT testing and task validation help determine whether services actually work for users with disabilities.

How ADA Title II compliance is evaluated in practice

ADA Title II does not mandate specific tools or technologies. Instead, compliance is evaluated based on outcomes: whether people with disabilities can effectively access and use digital services.  This is where many organizations run into trouble. Automated accessibility checkers can be helpful for quickly catching many accessibility issues. However, they cannot evaluate context, meaning, or usability. This can result in surface-level conformance, creating experiences that don’t hold up to scrutiny or work in real-world settings.  In practice, effective evaluation includes:

• Manual accessibility audits led by accessibility experts

• AT testing with screen readers and screen magnifiers

• Validation that users with disabilities can independently complete critical tasks from start to finish, using assistive technologies as needed.

Why prioritization matters under ADA Title II

Most government digital ecosystems are large and complex. Websites, subdomains, documents, and third-party systems often span departments and vendors. Additionally, many government entities leverage a mix of cloud, on-premises, and legacy systems, which can easily create accessibility gaps. As a result, accessibility issues can number in the hundreds or thousands.  The Government Accountability Office (GAO) has highlighted the extent of the challenge. In a 2025 review, GAO identified 11 federal legacy IT systems maintained across 10 agencies that remain in critical need of modernization. While these findings are from the federal level, which is subject to separate accessibility regulations, they highlight the risk of outdated systems and fragmented architectures complicate efforts to modernize digital services in a prioritized, risk-based way.  Responding to ADA Title II requirements extends beyond identifying how many issues exist to implementing a strategy for addressing issues in a prioritized manner. Effective prioritization considers:

• Impact on people with disabilities

• Criticality of the service or task

• Frequency of use

• Effort to fix

• Legal and operational risk

This approach helps organizations focus limited resources where they matter most, reducing risk while improving access in meaningful ways.

From awareness to action

Understanding ADA Title II is the first step toward readiness. For state and local governments, compliance is not a one-time project. It is an ongoing responsibility tied to how digital services are delivered, maintained, and evolved over time.  Organizations that take a structured, user-centered approach grounded in expert-led audits, usability testing, and strategic prioritization of remediation efforts are better positioned to deliver and maintain accessible services and demonstrate good-faith compliance.  While private companies are not covered by ADA Title II, state and local government entities should assess the risk posed by vendor-supplied digital resources that may not meet Title II accessibility requirements. And, in turn, vendors providing digital tools to state and local government entities should be ready to ensure their tools meet Title II requirements.

Explore digital accessibility services

Digital services have become synonymous with public access, but making them sufficiently accessible to meet ADA Title II compliance can seem overwhelming. An accessibility partner can streamline the compliance process, helping organizations navigate complex regulatory requirements with confidence.  With over 30 years of experience in assistive technology and accessibility implementation, Vispero’s Digital Accessibility Services help public entities assess current-state accessibility, identify high-impact barriers, and prioritize remediation aligned to ADA Title II requirements. Our expert-led approach supports sustainable accessibility across websites, applications, and digital content, helping agencies reduce risk while improving access for constituents and staff.  Learn how Vispero’s Digital Accessibility Services support ADA Title II readiness for public sector organizations.

The post Understanding ADA Title II and Digital Accessibility Requirements appeared first on Vispero.

The post Getting Started with Section 508 Digital Accessibility appeared first on Vispero.

The post Assistive Technology: Go Beyond Compliance to Foster Productivity, Retention, and Scale appeared first on Vispero.

A foundational part of a well-managed online presence is ensuring that all users can access your information and services. For people who are blind or have low vision, this access often hinges on how well creators and developers understand and apply accessibility laws and standards.

Depending on the industry, you may have to comply with multiple accessibility standards, which can seem overwhelming. This guide provides a high-level overview of the U.S. accessibility laws and standards and how they translate into real access for blind and low-vision users.

Why digital accessibility matters

Imagine being unable to access a government website to renew your driver’s license, order online, or read the news because the platform wasn’t designed for you. Unfortunately, this is the reality for blind and low vision users when digital spaces are not accessible.

According to the World Health Organization, approximately 2.2 billion people worldwide have some form of vision impairment, millions of whom live in the United States. Beyond legal mandates tied to disability rights and reasonable accommodations, there are clear operational and public-service benefits to creating conformant, accessible digital experiences, and clear legal consequences when websites and services are inaccessible:

• Expanded Market Reach: Tap into overlooked, underserved residents and constituents with immense purchasing power, including users with different types of disabilities.
• Improved Usability for Everyone: Accessible design, clear structure, logical navigation, readable content, appropriate font choices, and clean, semantic HTML benefit all users.
• Reduced Legal Risk: Aligning with federal accessibility requirements helps reduce exposure to costly complaints, settlements, and litigation under the ADA and related federal law.

In the U.S., digital accessibility is formalized through federal law, with specific statutes and standards governing how digital access must be provided.

What are the key U.S. accessibility laws?

In the U.S., two primary pieces of legislation form the bedrock of accessibility for blind and low-vision individuals: the Americans with Disabilities Act (ADA) and Section 508 of the Rehabilitation Act, as enforced by agencies such as the U.S. Access Board.

The Americans with Disabilities Act (ADA)

Enacted in 1990, the Americans with Disabilities Act (ADA) is a landmark civil rights law that prohibits discrimination against individuals with disabilities in all areas of public life, including employment, education, transportation, and public and private places open to the general public.

The ADA is a broad umbrella that covers both physical and digital spaces. While the original text didn’t explicitly mention the internet, both courts and the Department of Justice (DOJ) have consistently interpreted the ADA to apply to websites, mobile devices, and other digital platforms when they act as places of public accommodation or government services. For people who are blind or have low vision, the ADA ensures equitable access to public spaces and information:

• Physical Access: Public places like stores, restaurants, hospitals, and government buildings must provide accessible features. This could include tactile signage, accessible routes, and assistance for those with visual impairments.
• Information Access: Perhaps most crucially in the modern era, the ADA requires information provided by public entities to be accessible. This is where digital accessibility comes into play. If your website is the primary way citizens interact with a government agency, that website must be accessible to screen readers and other assistive technologies used by people with disabilities, including support for alternative formats.

The key takeaway for the ADA is if you offer goods or services to the public, or if you’re a state or local government entity, the ADA applies to you and your digital presence.

ADA Title II and Title III

While the ADA as a whole is crucial, Title II of the ADA specifically applies to state and local government entities, including city halls, public libraries, state universities, and other public institutions. For blind and low-vision individuals, Title II establishes a legal requirement for programmatic access and effective communication across digital services, not just physical buildings:

• Programmatic Access: Not just the physical building, but the programs and services offered must be accessible. For example, if a city offers an online portal for paying utility bills, that portal must be screen reader compatible.
• Effective Communication: Title II mandates that state and local governments must ensure effective communication with individuals with disabilities. For people who are blind or have low vision, this could mean providing information in accessible electronic formats, large print, or Braille, or offering qualified readers. It also means websites and digital content must be accessible.
• Self-Evaluation and Transition Plans: Entities covered by Title II were required to conduct self-evaluations of their services, policies, and practices and make necessary modifications. If structural changes were needed to achieve program accessibility, they had to develop transition plans.

In 2024, the DoJ finalized ADA Title II regulations that explicitly require state and local government websites and mobile applications to conform to WCAG 2.1 Level AA. This rule establishes a clear federal accessibility requirement for digital services and removes long-standing ambiguity around online compliance. The finalized rule also requires covered state and local governments to comply by April 24, 2026, with extended deadlines for smaller jurisdictions.

ADA Title III, which applies to private businesses open to the public, has been consistently interpreted by courts to require accessible websites and digital services when those platforms are essential to accessing goods or services. Many ADA Title III cases involving blind users center on screen reader failures, inaccessible forms, or keyboard barriers.

Section 508 of the Rehabilitation Act

While the ADA is broad, Section 508 of the Rehabilitation Act of 1973 is much more specific, focusing on information and communication technology (ICT) developed, procured, maintained, or used by the federal government, consistent with guidance from the U.S. Access Board. Section 508 was enacted to ensure that all of this digital infrastructure is accessible to federal employees and members of the public with disabilities.

Key aspects of Section 508 include:

• Focus on ICT: It explicitly covers websites, software, hardware, video, multimedia, and electronic documents.
• Government-centric: It primarily applies to federal agencies and any vendors or contractors doing business with them. If you’re a private company selling software to the Department of Defense, your software must be Section 508 compliant.
• Specific Standards: Unlike the ADA, which is interpreted to apply to digital accessibility, Section 508 has very specific technical standards that agencies and their vendors must meet. These standards have evolved, with the latest update harmonizing significantly with the Web Content Accessibility Guidelines (WCAG). This harmonization is a benefit, as it means alignment with Section 508 will also improve your overall ADA compliance.
• Procurement Power: A significant driver of Section 508 compliance is its procurement clause. Federal agencies are legally required to purchase ICT that is accessible, unless doing so would result in an undue burden or a fundamental alteration.

In essence, Section 508 acts as a specific, detailed rulebook for the federal government’s digital interactions.

The role of WCAG in accessibility compliance

WCAG is not a law; it’s a set of technical guidelines developed by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C). As an internationally recognized benchmark for web accessibility, WCAG is widely referenced by legal bodies, including the Department of Justice, as the de facto standard for ADA compliance and is directly incorporated into Section 508.

At the heart of WCAG are four foundational principles, often remembered by the acronym POUR: Perceivable, Operable, Understandable, and Robust. Each principle is centered around concrete, testable success criteria to ensure that web content is accessible to people with disabilities:

1. Perceivable: Can users perceive the information presented?
2. Operable: Can users interact with the interface and navigate the content?
3. Understandable: Can users understand the information and the user interface?
4. Robust: Can the content be interpreted reliably by a wide variety of user agents, including assistive technologies?

WCAG offers different levels of conformance, allowing organizations to set goals based on their resources and legal obligations. Levels A, AA, and AAA each represent a higher degree of accessibility.

• Level A: This is the lowest level of conformance. It addresses the most fundamental and critical accessibility barriers.
• Level AA: Level AA conformance strikes a good balance between achieving significant accessibility for the widest range of users and being technically feasible for most organizations to implement. It includes all Level A criteria plus additional guidelines that address common and significant barriers, often without requiring fundamental changes to content or design.
• Level AAA: While aspirational, AAA is often neither realistic nor required for entire websites or applications. Many organizations aim for AAA for specific, critical components, such as accessibility statements or help sections, but stick to AA for broader content.

WCAG 2.1 Level AA remains the version most directly referenced in U.S. accessibility enforcement, including Section 508 and the ADA Title II rule. WCAG 2.2 builds on 2.1 by adding success criteria that improve usability for users with cognitive and motor disabilities, without changing existing requirements that affect blind and low-vision access.

How compliance translates into access for blind and low vision users

U.S. accessibility laws define legal requirements, but they do not prescribe specific technologies. Instead, compliance is evaluated based on whether users can independently access digital information and services, including content delivered in accessible formats and alternative formats.

For blind and low-vision users, that access is delivered through assistive technology (AT). To meet the needs of a diverse population, AT isn’t one-size-fits-all; each tool has unique features, with some overlap, allowing users to choose the tools that fit the level of vision loss they are currently experiencing.

Screen readers enable blind users to navigate digital content by converting on-screen information into speech or Braille. If websites are not labeled or structured correctly, screen readers cannot interpret them, effectively denying access and violating accessibility standards.

Low vision users may choose to use their remaining vision and rely on screen magnification software rather than a screen reader. For these users, content must remain readable and functional when enlarged or visually adapted. If layouts break, text loses clarity, or information is conveyed only through color or visual cues, users may be unable to complete tasks independently.

Keyboard navigation underpins both screen readers and magnification tools. When users cannot navigate or operate content using a keyboard alone, they lose access to core functionality. Because of this dependency, keyboard barriers frequently appear in both ADA and Section 508 enforcement actions.

Together, screen reader compatibility, visual adaptability, and keyboard access form the functional baseline for equal access. If any of these fail, blind and low vision users are unable to complete tasks and access information independently—placing organizations out of alignment with accessibility requirements and disability rights protections under federal law.

Common Pitfalls and How to Avoid Them

Even well-intentioned organizations can make mistakes on the path to accessibility. Awareness of common missteps can save time and resources.

Assuming visual impairment is a monolith

One mistake is treating blindness or low vision as a single, uniform condition. There is no set path to vision loss, and users rely on different AT and strategies. Guidelines like WCAG help address a broad spectrum of disabilities, enabling organizations to create digital experiences optimized for more users.

Over-reliance on automated testing tools

Automated accessibility checkers are fantastic for quickly catching obvious errors. However, they cannot evaluate context, meaning, or usability. Manual testing with AT is essential to understand how real users experience digital content. The end goal is to focus on why an accessibility gap creates a barrier for users, not just that a tool flagged it.

Neglecting user testing with disabled users

Testing with blind and low-vision users is one of the most effective ways to uncover accessibility gaps that are not obvious during design or development. From a legal perspective, enforcement actions increasingly focus on whether users can independently complete tasks. Digital experiences that are technically compliant but unusable with screen readers have repeatedly been cited in ADA complaints and settlements.

Building accessibility in, not on

Finally, many organizations treat accessibility as something to retrofit after a product launch. This approach is costly, inefficient, and risky. From a compliance perspective, U.S. accessibility laws focus on whether users have timely, effective access—not whether barriers were addressed only after complaints or legal action.

Turn accessibility compliance into confident, usable access

Navigating accessibility laws and standards doesn’t have to be overly complex. Having the right partner can streamline the accessibility implementation process, turning compliance from a challenging regulatory landscape into a scalable, sustainable program that grows with your organization.

Vispero has over 30 years of experience in assistive technology and accessibility implementation. We partner with organizations across industries to help them meet accessibility requirements, reduce risk, and deliver digital experiences that allow blind and low vision users live, work, and connect with confidence.

Interested in learning more? Reach out to one of our accessibility experts to learn how Vispero can help you strengthen and scale your accessibility program with confidence.

The post Your Guide to U.S. Accessibility Laws and Standards for Blind and Low Vision Access appeared first on Vispero.