Higher dependence, higher risk: mobile systems as critical service gateways
State and local governments increasingly deliver essential public services through mobile applications and third-party digital systems. In many cases, people must use these tools — not agency-owned websites — to apply for benefits, submit forms, make payments, track case status, or receive time-sensitive updates.
When a service can only be completed through a mobile app or third-party platform, accessibility barriers in that system block access to the service itself.
This creates heightened risk for people with disabilities.
Mobile devices are often a primary or preferred way to access online services, especially as agencies design and promote mobile-first experiences.
As more core workflows move into apps and vendor-controlled platforms, accessibility barriers in those environments have a direct and disproportionate impact on people with disabilities.
At the same time, mobile and third-party systems continue to present persistent accessibility challenges.
Complex interactions, custom interface components, frequent updates, and limited oversight all increase the likelihood of accessibility failures compared to agency-owned websites. Recent research reflects this pattern, finding that roughly 72% of mobile user journeys contain significant accessibility barriers, particularly in navigation, forms, and transactions.
What ADA Title II actually requires of digital services
ADA Title II applies to state and local government entities. It requires them to make sure people with disabilities can access their programs, services, and activities on equal terms.
In April 2024, the Department of Justice clarified that this requirement applies to digital services, including websites, mobile apps, and third-party systems. If a digital system is used to deliver a public service—or if people must use it to complete a task related to that service—it falls under ADA Title II.
What compliance means in practice
Complying with ADA Title II means ensuring that required digital services are accessible to people with disabilities. The DOJ uses the Web Content Accessibility Guidelines (WCAG) to define what “accessible” means.
WCAG is an internationally recognized set of guidelines that has been used for years as the basis for digital accessibility requirements, including under ADA Title III and in accessibility regulations outside the U.S. The DOJ adopted the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA as the standard for Title II compliance.
The rule also establishes clear compliance deadlines:
- State and local governments serving 50,000 or more people must meet the WCAG 2.1 Level AA standard by April 11, 2026
- Jurisdictions serving fewer than 50,000 people have until April 11, 2027
By these dates, any digital system that people are required to use to access a public service—including mobile apps and vendor-controlled platforms—must meet this accessibility standard.
Why agencies often underestimate accessibility risk in mobile and third-party systems
Accessibility risk in mobile apps and third-party systems is often missed not because agencies don’t care, but because these systems fall outside the structures agencies typically use to manage accessibility. Websites usually have clear owners, review cycles, and accountability. Mobile apps and vendor platforms often do not.
Agencies tend to underestimate risk for three main reasons:
- Fragmented responsibility
Accessibility ownership is often split across IT, procurement, program teams, and vendors. When accountability is unclear, issues are easier to miss and harder to address. - Assumed vendor accessibility
Agencies may assume vendor platforms or widely used apps are accessible based on contract language or reputation rather than real-world testing. Over time, updates and integrations can introduce new barriers. - Content and workarounds mask problems
Forms, documents, and workflows created within a platform can introduce accessibility barriers even when the underlying system supports accessibility. Help-desk workarounds do not provide equal access when a digital system is required.
The unique risks of mobile apps and third-party systems
While accessibility remains a challenge across the entire digital landscape, mobile applications and third-party systems often introduce heightened risks that can be easier to overlook. This is not because these systems are inherently less accessible, but because they operate under technical and structural conditions that make consistent accessibility harder to maintain.
I. Mobile environments introduce unique interaction hurdles
Mobile apps rely heavily on custom interface components, gesture-based interactions, and dynamic content that do not always translate smoothly to assistive technologies.
- Complexity of testing – Mobile accessibility testing often requires physical devices and specialized tools.
- Detection gaps – Automated tools detect far fewer accessibility issues in mobile apps than on websites.
- Frequent update cycles – Frequent app updates increase the risk of accessibility regressions.
II. Third-party platforms limit visibility and control
When an agency delivers services through a vendor-controlled platform, accessibility can become a “black box.” Agencies may have limited visibility into how accessibility is tested or maintained as systems evolve.
Common risks include:
- Limited oversight — Agencies often cannot see how vendors test accessibility or whether issues are fixed before updates are released.
- Uneven coverage — Platforms designed for broad markets may meet general standards, but agency-specific configurations can introduce new barriers.
- Limited code access — Unlike agency-owned websites, vendor systems rarely allow direct fixes, leaving agencies dependent on the vendor’s timeline.
III. Disparities in internal ownership
Accessibility risk also increases when responsibility for digital systems is fragmented across multiple teams. Key challenges include:
- Fragmented ownership — Websites may fall under centralized policies, while mobile apps and vendor systems are managed across IT, procurement, and program teams.
- Assumptions of compliance — Agencies may assume platforms are accessible based on contract language or vendor reputation rather than evaluating real user experience.
How accessibility gaps translate into real service barriers
When accessibility fails in mobile apps or third-party systems, the impact appears at the moment people try to complete essential tasks. These are not edge cases — they are routine steps required to access public services.
Common barriers include:
- Applications cannot be completed
If form fields are unlabeled, error messages are not announced to assistive technologies, or submission buttons require touch or visual input, people with disabilities may be unable to submit applications or upload documents. - Required tasks cannot be completed independently
Users may be unable to log in, reset passwords, update information, or complete required steps when interfaces rely on gestures, visual cues, or time-based interactions. - Critical updates are missed
If alerts or status updates are not accessible to screen readers, people may miss deadlines, appointments, or required actions. - Workarounds do not provide equal access
Directing users to call a help desk or email staff introduces delays and removes the ability to access services independently.
“I recently had to reach out to the Governor of my state, and there was a form to contact her. I was able to completely fill out the form, but the send message button was not operable. I could use a screen reader and was completing this with VoiceOver on my iPhone. I also attempted from my computer with a screen reader, and it was still not operable with my keyboard. I had to wait for my husband to get home to get assistance in sending the form.”
- Josh Basile esq.
What agencies should be paying attention to now
As digital accessibility obligations under ADA Title II come into focus, the biggest risk for agencies is not inaction, but looking in the wrong places. Many agencies have improved accessibility on their main websites. Increasingly, risk sits in the systems people are required to use.
At this stage, a few areas deserve particular attention:
Focus on required systems
Mobile apps, vendor platforms, and service portals are often where services are actually completed. If a system is required to access a service, it should be treated as part of that service for accessibility purposes.
Know what is in scope
Agencies often underestimate risk because they lack a clear inventory of which digital systems are required to complete services, which are mobile-first, and which are vendor-operated but still critical to access.
Clearly define ownership
When accessibility spans multiple teams and vendors, it can easily become no one’s priority. Clear ownership helps ensure accessibility is monitored as systems change.
Don’t rely on workarounds
Alternate access by phone or email does not provide equal access when a digital system is the standard service pathway. Over time, these exceptions signal unresolved accessibility gaps.
Where ADA Title II risk now concentrates
ADA Title II is ultimately concerned with whether people can access public services in the way those services are actually delivered. As agencies increasingly rely on mobile applications and third-party platforms to deliver essential services, accessibility in those environments now determines whether programs can be accessed at all.
When required mobile or vendor-controlled systems are inaccessible, people with disabilities are blocked from completing applications, managing accounts, receiving updates, or meeting deadlines. Responsibility for these outcomes remains with the agency, regardless of how the technology is sourced or operated. As service delivery continues to shift toward mobile-first models, ADA Title II risk increasingly concentrates in the systems closest to service completion.
Frequently asked questions about mobile and third-party system accessibility
Q1. What does ADA Title II require for government mobile apps?
A1. Under the 2024 Title II rule, all mobile applications used by state and local government entities to deliver programs, services, or activities must be accessible to people with disabilities. This legal mandate requires that these apps conform to the technical standards of Web Content Accessibility Guidelines (WCAG) 2.1 Level AA.
Q2. Are agencies responsible for the accessibility of third-party vendor systems?
A2. Yes. Public entities are legally responsible for the accessibility of any digital content they "provide or make available," regardless of whether it is hosted on an agency-owned site or a third-party platform. This includes vendor-controlled portals used for utility payments, benefits applications, or public parking.
Q3. When is the deadline to ensure mobile and third-party systems are compliant?
A3. Compliance deadlines are based on the population size the public entity serves. Large public entities (serving 50,000 or more people) must ensure their mobile apps and third-party systems conform by April 24, 2026. Smaller entities (serving fewer than 50,000 people) and special district governments have until April 26, 2027.
Q4. Does the rule apply to "secondary" apps or internal-facing portals?
A4. Title II applies broadly to all digital tools used to deliver government services, whether they are public-facing or student- and employee-facing. This includes internal portals for government employees, learning management systems (LMS) for students, and mobile apps used for campus navigation or emergency notifications.
Q5. Can we provide a phone number as a workaround if an app is inaccessible?
A5. Federal guidance clarifies that public institutions cannot rely on reactive "upon request" models or phone workarounds as substitutes for accessible digital content. Title II requires that digital services be accessible by default upfront to ensure that all users have an equitable and timely experience from the moment they are made available.
Q6. What are common accessibility barriers in mobile government apps?
A6. Common barriers include unlabeled buttons or links (which impact 60% of screen reader users), touch targets that are too small to tap, and the requirement of complex gestures like pinching or drawing shapes. Additionally, apps often fail when they do not support both portrait and landscape orientations or lack clear error-handling messages.
Q7. How should agencies manage accessibility with their third-party vendors?
A7. Agencies should include specific accessibility requirements in all future vendor contracts and Request for Proposals (RFPs). Public entities should request a Voluntary Product Accessibility Template (VPAT) or an Accessibility Conformance Report (ACR) from vendors to document how their platforms align with WCAG 2.1 Level AA.
