HomeInsights › The ADA at 36

Accessibility

The ADA at 36: The front door is now a screen.

The Americans with Disabilities Act was signed before the web became part of everyday life. Today, its promise lives in every portal, PDF, platform and technology decision.

On July 26, the Americans with Disabilities Act marked its 36th anniversary.

When President George H. W. Bush signed the ADA in 1990, he signed a federal civil rights law grounded in a straightforward promise: people with disabilities should not be excluded from work, public services, businesses or ordinary participation in American life.

The timing is worth remembering. Tim Berners-Lee had proposed the World Wide Web at CERN only a year earlier. The first web servers and browsers were still being developed, and the web would not begin spreading beyond CERN until 1991.

The ADA was not written as a technology law. It was written as a promise.

Technology has since become one of the primary places where that promise is either kept or quietly broken.

The front door became a screen

For years, accessibility was represented by familiar physical features: a ramp, an elevator, an automatic door, a curb cut or an accessible parking space.

Those things remain essential. But much of the front door has moved.

We apply for jobs online. Students receive assignments through digital platforms. Parents register children using web forms. Residents request permits, pay bills and review public records through government websites. Employees complete benefits paperwork, training and performance reviews through software.

The door is now a login screen.

It is a PDF exported without headings. It is a video without captions. It is an error message that a screen reader never announces. It is a form that cannot be completed without a mouse. It is a multifactor authentication process built around assumptions about how everyone sees, hears or manipulates a device.

Inside an IT department, these can look like technical defects. To the person encountering them, they can determine whether someone can apply, learn, work, participate or receive a public service without asking another person for help.

That is the difference between a software problem and a civil rights problem.

IT did not ask for this role

Most people in IT did not enter the profession expecting to become stewards of civil rights.

They came to manage networks, secure data, build systems, support users and keep organizations running. But technology now mediates so much of public and professional life that IT decisions inevitably shape who gets to participate.

A content management system determines whether editors can add meaningful alternative text. A design system determines whether every new application repeats the same inaccessible components. A document repository can preserve thousands of unreadable PDFs. A purchasing decision can embed an inaccessible platform for five years.

Even the help desk has a role.

When a user reports that a platform does not work with a screen reader, how is the complaint categorized? Is it treated as an unusual compatibility issue, an individual request for accommodation or evidence of a system-level barrier?

The answer reveals how an organization understands accessibility.

Digital accessibility cannot belong to IT alone. Communications teams publish content. Human resources selects employment platforms. Teachers create documents. Vendors write code. Legal teams interpret obligations. Executives decide what gets funded.

But IT is often the only group positioned to see how all of those decisions connect.

Accessibility is a system, not a score

Many organizations begin with an automated accessibility scan. That can be useful. It can also create a dangerous illusion of certainty.

A scanner can identify some missing labels, contrast failures and structural errors. It cannot fully determine whether someone can understand a complicated form, navigate a purchasing process, operate a third-party platform or make sense of a poorly organized document.

Accessibility is not the number displayed at the end of a report. It is whether people with disabilities can complete meaningful tasks with comparable independence, privacy and dignity.

That requires automated testing, manual review and, when possible, testing involving people who use assistive technology. It also requires prioritization. An isolated defect on an archived page is not equivalent to an inaccessible emergency notice, employment application or school enrollment form.

IT teams already know how to prioritize operational and security risks. Accessibility asks them to apply that same discipline to human access.

Artificial intelligence makes this even more important. AI can now generate websites, software, images, videos and documents at remarkable speed. It can also reproduce accessibility barriers at that same speed. A generated interface can still have a broken focus order, and an AI-written document can still lack meaningful headings.

AI does not replace accessibility expertise. It increases the need for people who can recognize when something that looks finished is not actually usable.

Tomorrow’s barriers begin in procurement

Many accessibility problems enter an organization long before anyone uploads a document or writes a line of code.

They enter through a contract.

A vendor may describe its product as “ADA compliant” without providing meaningful evidence. An accessibility report may be outdated, incomplete or based on a narrow test. A polished demonstration may avoid the workflows most likely to expose barriers.

Once the agreement is signed, the organization inherits the problem.

Accessibility therefore has to become part of technology evaluation, contract language, implementation and renewal. Vendors should be asked which accessibility standards they follow, how their products were tested, what known issues remain and how quickly accessibility defects are addressed.

The goal is not to eliminate every imperfect product overnight. It is to stop buying technology without understanding who may be excluded by it.

Fixing accessibility after implementation is almost always more difficult than asking better questions before purchase.

The requirements are becoming more specific

The legal expectations are also becoming clearer.

The Department of Justice’s Title II web and mobile accessibility rule requires covered state and local government entities, including public schools, to make their web content and mobile applications conform to WCAG 2.1 Level AA. The rule gives public entities a specific technical standard for meeting their existing obligations under Title II of the ADA.

Following a roughly one-year extension issued in April 2026, public entities serving populations of 50,000 or more now have until April 26, 2027. Smaller public entities and special district governments have until April 26, 2028.

Those dates matter, but they should not be confused with the beginning of the obligation.

The ADA already prohibits disability discrimination. The new rule provides covered public entities with a clearer standard for websites and mobile applications. It does not mean that people with disabilities deserve digital access only after a compliance deadline arrives.

For an IT leader, the practical questions are immediate.

Who owns accessibility? Which digital services matter most? Are new purchases being evaluated? Can users report a barrier? Are employees being taught to create accessible content? Is the organization reducing its backlog, or adding to it every day?

A deadline can begin a project. It cannot create a culture.

Holding the digital door

The ADA changed the built environment partly by changing what Americans came to expect.

Features once treated as special accommodations gradually became ordinary elements of thoughtful design. Curb cuts support wheelchair users, but they also help parents with strollers, travelers with luggage, delivery workers and children riding bicycles.

Digital accessibility works much the same way.

Captions support people who are deaf and people watching a video in a noisy room. Clear headings help screen-reader users and anyone scanning a long page. Keyboard-accessible controls support people with motor disabilities and people who prefer not to reach for a mouse. Plain language helps people with cognitive disabilities, people reading in a second language and almost anyone trying to understand a complicated process.

Accessibility is not a specialty added after the real work is finished. It is part of doing the work well.

Thirty-six years after the ADA was signed, many of the people holding America’s doors are no longer standing at building entrances.

They are configuring platforms, approving software, building websites, managing documents and responding to support tickets.

That carries responsibility. It also creates an extraordinary opportunity.

IT can make independence possible at scale.

Ryan Thompson is the principal of Mention Group, a Milwaukee marketing and visibility firm that builds for discoverability and accessibility. If your organization needs an honest read on where its digital front door stands, start a conversation.