Property managers and landlords generally understand that the Fair Housing Act prohibits refusing to rent to someone because of a disability, and that it requires reasonable accommodations, like allowing a service animal despite a no-pets policy, once a request is made. What gets missed far more often is that the same statute's protections do not stop at the building's front door. The rental application portal, the online form a prospective tenant has to complete before they are ever considered for a unit, is itself subject to the same anti-discrimination framework, and a portal a disabled applicant cannot actually use is a barrier to housing before that person has even been evaluated as a tenant.
The Fair Housing Act, enforced jointly by HUD and the Department of Justice, prohibits discrimination in housing on the basis of several protected characteristics including disability, and one of its core mechanisms is the duty to make reasonable accommodations in rules, policies, practices, or services when needed to give a person with a disability an equal opportunity to use and enjoy housing. An online rental application that a screen reader user cannot complete, or a keyboard-only user cannot submit, functions as a practical denial of that equal opportunity, regardless of whether a human ever explicitly said no.
The Fact: HUD and the Department of Justice jointly enforce the Fair Housing Act's disability protections, which include the duty to provide reasonable accommodations in the policies, practices, and services used to evaluate housing applicants. (Source: HUD, Fair Housing and Nondiscrimination Requirements)
The Overlap With ADA, and Where Fair Housing Goes Further
Most rental application portals are already subject to the ADA as places of public accommodation for the same reasons other consumer-facing websites are, covered in more general terms in our real estate website accessibility guide. The Fair Housing Act adds a second, distinct legal basis on top of that, specific to housing, and it is not merely redundant. The FHA's reasonable accommodation framework is broader than ADA Title III's general accessibility standard in one important way: it is explicitly about equal opportunity to access housing itself, not just general public accommodation, which means an inaccessible application process can be argued as a housing discrimination claim even in edge cases where an ADA Title III argument alone might be weaker.
This double exposure is exactly why property management companies and landlords, especially larger portfolio operators using shared application software across many properties, face compounded risk from a single inaccessible intake form. One broken portal is not one lawsuit risk. It is potentially two separate legal frameworks pointing at the same underlying failure, applied across every property that uses the same application system.
The Specific Failure Points in a Rental Application Flow
Rental application portals share a recognizable set of recurring problems. Income and employment verification steps frequently rely on file upload widgets with no accessible label or instructions, leaving a screen reader user unsure what format or document is expected. Multi-step application wizards, similar to the patterns covered in our multi-step form wizard accessibility guide, often fail to announce progress or errors to assistive technology, so an applicant who makes a mistake on step two has no way of knowing without visually scanning the page for a small red error message that a screen reader never announced. Background check consent forms and e-signature widgets, frequently built by third-party vendors and embedded as an iframe, are a common blind spot because the property manager's own team has no visibility into or control over that vendor's accessibility, yet is still the party facing legal exposure if it fails.
The Inquiry Limits Also Matter Here
The Fair Housing Act generally prohibits inquiring into the nature or existence of an applicant's disability, and a poorly designed accommodation request process, for example, an application form with no clear, accessible way to request an accommodation at all, or one that forces a disabled applicant to disclose more about their disability than necessary just to find where to ask for help, creates its own separate compliance risk distinct from the pure accessibility failure. A well-built application flow needs a clear, accessible path for a prospective tenant to request an accommodation, without that path requiring information the law says should not be requested unless the disability is not obvious and verification is genuinely needed.
What to Check First
For any organization running rental applications online, the highest-value first check is the actual submission path, not the marketing pages describing the property. Can a screen reader user complete every required field, upload a document, and receive their confirmation without sighted assistance? Can a keyboard-only user reach and operate every control, including any embedded third-party background-check or e-signature step? If the application system is licensed from a property management software vendor, has that vendor ever produced real evidence, not just a marketing claim, that its intake flow was tested against WCAG?
If your organization manages rental properties or licenses application software to others in that space, testing the actual end-to-end application flow, not just the listing pages, is the place to start. Our real estate listing accessibility guide covers the broader property-site pattern, including the map-based listing failures that compound this same legal exposure.
Our team can run a free scan of your application portal and flag exactly where a disabled applicant would get stuck. Reach us at experts@wcag.world, or review HUD's Fair Housing guidance and the Department of Justice's Fair Housing Act overview directly for the primary legal framework.
A practical review loop
Start with the task a person needs to complete, not with the score produced by a single automated scan. Write down the entry point, the expected focus order, the announcement a screen reader should receive, and the recovery path when something goes wrong. Then repeat that task with a keyboard and at least one assistive technology setup. This turns a vague accessibility concern into an observable acceptance test.
The useful evidence is specific. Capture the URL, the control label, the keystrokes, the browser state, and the expected result. Separate a defect from a design choice, and separate both from a limitation in the test environment. Give the product owner a short reproduction and a clear severity rationale. A developer can fix a named interaction. Nobody can reliably fix a general instruction to make a page more accessible.
Finally, put the check into the delivery process. Add the scenario to a pull request checklist, retest it after JavaScript changes, and keep a small set of representative pages available for regression testing. That routine protects the people who depend on the workflow and gives the team a defensible record of what was tested, when it was tested, and what happened.
For the next review, use these related resources: map based real estate listings lock out screen reader users.
For the next review, use these related resources: request the relevant WCAG review.