On April 24, 2026, a major federal deadline takes effect. Under a final rule issued by the Department of Justice in 2024, state and local governments must ensure their websites and mobile applications meet WCAG 2.1 Level AA accessibility standards. For agencies managing affordable housing, community development, energy, and disaster recovery programs, this applies to far more than just your homepage. It covers every digital interaction a resident has with a government-funded program.
Accessibility in government technology has been a legal requirement for decades, but enforcement, specificity, and public awareness have all intensified in recent years. If your agency uses software to manage applications, waitlists, inspections, recertifications, or payments, this is a good moment to understand what the standards require and where the gaps are.
What’s Actually Changing
The ADA Title II rule is not brand-new law. Title II of the Americans with Disabilities Act has always required state and local governments to provide equal access to their services. What changed in 2024 is that the DOJ published specific technical requirements for web content and mobile apps for the first time. Until now, there was no formal regulation spelling out which version of WCAG applied or what level of conformance was expected. Courts interpreted the requirements case by case, which created inconsistency.
The new rule removes that ambiguity. State and local governments with populations of 50,000 or more must conform to WCAG 2.1 Level AA by April 24, 2026. Smaller jurisdictions have until April 26, 2027. The rule applies to all web content and mobile apps that a government entity uses to provide services or information to the public.
This arrives alongside continued pressure at the federal level. The GSA’s FY 2025 assessment of Section 508 compliance found that federal agencies themselves still fall short of accessibility obligations, even after years of reporting requirements. The broader signal is clear: digital accessibility is receiving more scrutiny from regulators, advocacy groups, and the courts than at any point in the past.
More Than Just Your Website
When most agencies hear “digital accessibility,” they think about their public-facing website. That’s just one piece of it, for program administrators, the more pressing question is what happens after someone finds your website. Consider the full digital experience a resident goes through when interacting with government-funded programs:
They start by visiting the agency website, then they move into an application portal where they create an account, enter personal information, and upload documents. After that, they check waitlist status through an online dashboard. They receive notifications by email or text about recertification deadlines. They interact with forms for income verification, household composition updates, and inspection scheduling. In some programs, they receive payments electronically or confirm receipt through a digital system.
Each of these touchpoints is a digital service. And under the ADA Title II rule, each one needs to be accessible.
The most common accessibility failures in government software are not dramatic. They tend to be things like form fields without proper labels (so a screen reader announces “edit text” instead of “First Name”), buttons that can’t be reached using a keyboard, PDF documents that are essentially images with no underlying text, and tables that don’t convey their structure to assistive technology. These are the kinds of gaps that exclude people from programs designed to serve them.
What WCAG 2.1 Level AA Actually Requires
WCAG stands for Web Content Accessibility Guidelines, published by the World Wide Web Consortium (W3C). The guidelines are organized around four principles, sometimes remembered by the acronym POUR: content must be Perceivable, Operable, Understandable, and Robust.
At a practical level, WCAG 2.1 Level AA includes requirements like providing text alternatives for images, ensuring sufficient color contrast between text and background, making all functionality available through a keyboard, providing captions for video content, and designing forms so that errors are clearly identified with suggestions for correction. The full standard includes 50 success criteria at the AA level. Some are straightforward to implement. Others require careful attention during design and development.
It’s worth noting that WCAG continues to evolve. Version 2.2 was published in October 2023 and added criteria around things like focus appearance, dragging movements, and consistent help placement. While the ADA Title II rule references 2.1, agencies and vendors building to 2.2 are better positioned for what comes next.
What to Ask Your Software Vendors
For agencies that rely on third-party software to manage their programs, the vendor’s accessibility practices matter just as much as your own. When a resident interacts with a vendor-hosted portal, the agency is still responsible under the ADA for that experience being accessible.
There are a few things worth understanding when evaluating a vendor’s accessibility. A Voluntary Product Accessibility Template (VPAT) documents how a product conforms to accessibility standards. It’s the most common way vendors communicate their compliance status, and agencies should ask for a current one. A VPAT from three years ago may not reflect the current state of the product. Look for vendors who update theirs regularly and who are transparent about known gaps and remediation timelines.
Beyond documentation, ask whether accessibility is built into the vendor’s development process. Products where accessibility is embedded in the Software Development Life Cycle (SDLC) tend to maintain compliance over time, because each new feature or update is tested against accessibility standards before release. Products where accessibility is treated as a periodic audit tend to drift out of compliance between reviews.
Also ask about assistive technology testing. Automated accessibility scanners catch some issues, but research shows they identify only 30–40% of WCAG failures — because automation lacks the ability to interpret meaning, intent, or user behavior. It might check whether a button has a label or if an image has alt text, but it can’t tell you if those labels or descriptions make sense in context. A vendor that tests with actual screen readers (like JAWS, NVDA, or VoiceOver) and verifies keyboard navigation is doing more thorough work than one relying solely on automated tools.
Accessibility and Program Equity Are the Same Conversation
Housing Choice Vouchers, home rehabilitation, emergency rental aid, and disaster recovery programs all exist to reach people in need. If the application process introduces another barrier, the program is working against its own mission.
According to the CDC’s disability and health data, roughly 1 in 4 adults in the United States lives with some form of disability. Among populations served by government assistance programs, rates of disability tend to be higher due to correlations with age, income, and chronic health conditions. An inaccessible digital experience means people who need help the most may not be able to access it.
Agencies that invest in accessibility are also investing in usability for everyone. Clearer form labels, better navigation structure, readable contrast, and logical page flow make the experience better for every resident. There is a large overlap between accessible design and good design.
Looking Ahead
Standards will continue to evolve, assistive technologies will change, and agencies will launch new digital services that need to meet the same bar. The agencies best positioned for this are the ones treating accessibility as an ongoing practice built into how they select, implement, and maintain technology.
For a closer look at how Neighborly Software approaches accessibility, including our WCAG 2.2 standards, VPAT assessments, and development practices, visit our Accessibility page.
