Why a hospital’s accessibility deadline now sits in its vendor contracts

Federal health regulators gave hospitals and other funded providers one more year to make their websites and apps usable by people with disabilities. Since vendors build most of what patients touch online, the smartest use of that year is the contract file.

Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.

Two-minute summaryThe dek and the first sentence of each section, quoted from the article

Federal health regulators gave hospitals and other funded providers one more year to make their websites and apps usable by people with disabilities. Since vendors build most of what patients touch online, the smartest use of that year is the contract file.

  1. The week On May 7, 2026, the HHS Office for Civil Rights, the part of the Department of Health and Human Services that enforces civil rights law in health care, issued an interim final rule pushing back the deadline for making hospital websites and apps accessible.
  2. What “accessible” means for a patient portal A website or app is accessible when people with disabilities can use it independently, getting the same information and finishing the same tasks as everyone else, with roughly the same effort.
  3. Why the hospital owns the problem even when a vendor wrote the code Section 504 attaches to the organization that receives federal financial assistance.
  4. Layer one: content the hospital writes This layer includes the public website, service-line pages, patient education handouts, intake and consent forms, financial assistance policies and price transparency pages.
  5. Layer two: platforms the hospital configures The patient portal, online scheduling, telehealth and the mobile app are built by vendors but configured, branded and extended locally.
  6. Layer three: services a vendor runs on the hospital’s behalf The third layer is the least visible.
  7. The duties and costs that did not wait An extension is not permission to wait, on several fronts.
  8. How the stronger programs are run Strong programs share a few traits.
  9. Twelve months, three tracks Return to the regional health system described above.
  10. With hindsight The comment period closed in July, and the extended dates stand as HHS published them, as far as we have seen.

The week

On May 7, 2026, the HHS Office for Civil Rights, the part of the Department of Health and Human Services that enforces civil rights law in health care, issued an interim final rule pushing back the deadline for making hospital websites and apps accessible. An interim final rule takes effect before the public has had its say, with comments gathered afterward. This one was effective the same day and was published in the Federal Register, the government’s official daily journal of rules, on May 11.

The deadline concerns failures like this one. A patient who is blind tries to pay a hospital bill online. Her screen reader, software that reads a web page aloud, reaches the payment form and goes silent, because the boxes have no labels it can announce. She calls the billing office, waits on hold, and spends an afternoon on something a sighted neighbor finishes in two minutes. Federal disability law has long said that should not happen at organizations that take federal health money.

The rule pushed back by one year the web and mobile accessibility dates in HHS’s 2024 rule under Section 504 of the Rehabilitation Act, the long-standing law that bars disability discrimination by anyone receiving federal financial assistance. Recipients with 15 or more employees, which had faced a May 11, 2026 date, now had until May 11, 2027. Smaller recipients moved from May 10, 2027 to May 10, 2028.

What did not move matters just as much. The technical standard stayed the same: WCAG 2.1 Level AA, the widely used checklist of what makes a website or app usable by people who are blind, deaf, have limited dexterity or have cognitive disabilities. Other Section 504 duties, including the duty to make reasonable modifications, such as offering a patient another way to get something done, were not extended.

HHS said it was aligning with the Justice Department’s April 2026 extension of the parallel dates for state and local governments under Title II of the Americans with Disabilities Act. It took public comments through July 6. For hospitals, health centers and other funded providers, the practical upshot was a year of breathing room, granted only days before the original date arrived.

The Justice Department’s April extension covered state and local governments. The HHS rule covers a different population, and its practical meaning differs too. A county mostly publishes its own content. A health system mostly buys its patient-facing estate. The portal, the scheduling tool, the bill-pay page, the telehealth app and the check-in kiosk usually come from vendors, each with its own release cycle. Section 504 responsibility stays with the funded provider regardless of who wrote the code. That makes the extra year a contracting year more than a remediation year.

A leadership team can split the problem into three layers, each with its own owner and its own tool. First, what digital accessibility actually means, and why responsibility for it sits with the hospital even when a vendor does the work.

What “accessible” means for a patient portal

A website or app is accessible when people with disabilities can use it independently, getting the same information and finishing the same tasks as everyone else, with roughly the same effort. That covers a wide range of people. Someone who is blind may use a screen reader, which reads the page aloud and lets them move through it with keyboard commands. Someone with a tremor or a repetitive strain injury may not be able to use a mouse at all and needs every button reachable by keyboard. Someone with low vision may enlarge text to four times its normal size and needs the page to still make sense. Someone who is deaf needs captions on a video visit or a recorded education module.

WCAG, short for Web Content Accessibility Guidelines, is the international checklist that turns those needs into testable requirements. Version 2.1 at Level AA, the target in the HHS rule, includes things like: images carry a short text description; form fields have labels a screen reader can announce; text has enough contrast against its background; nothing works only with a mouse; and a user is not trapped inside a pop-up window. It works much like a building code: headings, labels and keyboard paths do the job that ramps, door widths and elevator buttons do in a physical building.

Two features of the standard trip up executives. First, conformance is never a one-time certificate. A page that conforms today can fail tomorrow when someone uploads a new image without a description or a vendor ships an update. Second, much of it cannot be checked by software alone. Automated scanners catch missing labels and poor contrast well, but they cannot tell whether a description of an image is accurate or whether the order a screen reader follows makes sense. Human testing, ideally including people who use assistive technology every day, is part of the job.

Why the hospital owns the problem even when a vendor wrote the code

Section 504 attaches to the organization that receives federal financial assistance. In health care, that is the hospital, the health center or the provider group, and not the software company it hires. If a vendor’s scheduling widget cannot be used by a patient who relies on a keyboard, the patient’s complaint goes to the provider, and so does the regulator’s attention. A good contract can move the cost of fixing that defect to the vendor. It cannot move the legal duty.

The extra year matters so much in this sector for that reason. Take a regional health system whose public website is built in-house. Its patient portal comes from its electronic health record vendor. Online scheduling and telehealth come from two other companies. Billing statements and the online payment page are run by an outsourced revenue cycle firm. Appointment reminders go out through a texting service, and the lobbies have check-in kiosks from yet another supplier. The system writes perhaps a fifth of what patients see. Everything else arrives under a contract, and most of those contracts were signed before anyone thought to ask about accessibility.

A hospital’s digital estate splits into three layers with different owners: content the hospital writes, platforms the hospital configures, and services a vendor runs on its behalf. Each needs a different instrument. Together they cover everything a patient touches online.

Layer one: content the hospital writes

This layer includes the public website, service-line pages, patient education handouts, intake and consent forms, financial assistance policies and price transparency pages. It is the only layer the hospital fully controls, and it usually holds the largest backlog. Documents are the hard part. Marketing, nursing education, revenue cycle and compliance each publish PDFs, often from scanned originals or design tools that strip the structure screen readers depend on.

PDFs are troublesome for a specific reason. A well-made PDF contains hidden “tags” that tell a screen reader what is a heading, what is a table, which order to read the columns in, and what each form field is for. A scanned PDF is just a photograph of paper; to a screen reader it is a blank page. Many design tools produce PDFs that look perfect but carry no tags, or tags in the wrong order, so a two-column brochure is read across both columns line by line, producing nonsense.

The workable approach is to fix content where it is made. That means accessible templates in the office suite staff already use, a short pre-publication check owned by each publishing department, and a content inventory with an owner and a disposition for every item. Much of what is posted on hospital websites is stale, and retiring it is cheaper than repairing it. Forms deserve priority over brochures. An inaccessible financial assistance application blocks a benefit, while an inaccessible brochure blocks information that may exist elsewhere.

Remediation tools have improved, including automated tagging of PDFs. Automated output still needs human review of reading order, alternative text and form labels before anything clinical or financial is published. A realistic budget pays for that review as well as for software. A useful measure is the share of patient-facing PDFs that have passed a manual check, reported alongside the scan results.

Measurement keeps the layer honest. A monthly scan of new pages and documents, reported by publishing department, shows where new debt is being created. Pairing it with a quarterly manual test of the highest-traffic patient tasks, such as finding a clinic, paying a bill or requesting records, catches what scanners miss. Both results belong in the same governance forum that approves web content, rather than in a separate IT report.

Layer two: platforms the hospital configures

The patient portal, online scheduling, telehealth and the mobile app are built by vendors but configured, branded and extended locally. When one of them fails a patient, the cause could lie with either party.

Failures here have two sources. Some sit in the vendor’s code: a date picker that cannot be operated by keyboard, or a video visit window that traps screen reader focus. Others are introduced by the hospital: custom questionnaires, images uploaded without descriptions, low-contrast brand colors and embedded third-party widgets.

Contracts should split those responsibilities explicitly. The vendor should warrant WCAG 2.1 AA conformance for the base product. It should supply a current accessibility conformance report for each major release and fix defects within defined times by severity. The hospital should own its configuration, with an accessibility test inside its own change process.

An accessibility conformance report is a document in which a vendor lists each requirement of the standard and states whether its product supports it, partly supports it, or does not. It is useful, but it is a vendor’s claim. The agreement should let the hospital or an independent tester verify it, and should oblige the vendor to disclose known defects without waiting for complaints.

Release cadence matters as much as initial conformance. Large portal and EHR vendors ship updates several times a year, and an update can undo a fix. A sound clause ties regression testing, meaning a re-check that old fixes still work after a change, to each release and gives the hospital notice before patient-facing changes go live. Health systems on the same platform can also pool effort. User groups can test common workflows once, share results and press the vendor together on a single defect list.

Layer three: services a vendor runs on the hospital’s behalf

The third layer is the least visible. Statements from an outsourced billing company, payment pages from a processor, text reminders and surveys, after-hours answering services, chat assistants and lobby kiosks are often run end to end by a third party. Patients experience them as the hospital. The logo on the bill is the hospital’s, and so is the reputation when the bill cannot be read. Many of these contracts were signed by revenue cycle, patient experience or facilities teams rather than IT, and few mention accessibility at all.

The first task here is discovery. Procurement and accounts payable records can show which vendors deliver anything a patient sees or hears; the finance system knows about every supplier the hospital pays, including the ones IT has never heard of. Each should be asked for conformance evidence and a remediation plan. The gaps can then be ranked by how many patients a service reaches and whether it gates care or payment.

Kiosks need particular attention. A check-in device that cannot be used independently pushes patients to a staffed desk that may not exist at every site or every hour. A patient who uses a wheelchair and cannot reach the screen, or who is blind and gets no audio guidance, is effectively turned away from the front door of the clinic.

Renewal dates set the pace. Many of these agreements run for one to three years, so an extra year gives most hospitals at least one renewal in which to add accessibility terms. A shared clause library helps: legal, procurement and compliance agree the language once, and every patient-facing purchase uses it. Counsel should confirm how responsibility is allocated under existing agreements, and which Section 504 duties continue to apply in the meantime.

The duties and costs that did not wait

An extension is not permission to wait, on several fronts. The legal exposure did not pause: the duty to make reasonable modifications, and Section 504’s broader obligations, continued to apply. A patient who cannot use a portal can still ask for another way to get the same result, and can still complain if none is offered.

The money is real too, though it often hides. Every patient who cannot finish a task online becomes a phone call, a paper statement or a staffed desk visit, each more expensive than a self-service transaction. Inaccessible payment pages can slow collections. Inaccessible forms for financial help can leave eligible patients without assistance they are entitled to, which is both a fairness problem and a reputational one.

The patient population also makes this more than a niche concern. Hospitals serve many older patients, and age brings declining vision, hearing and dexterity whether or not anyone uses the word disability. Work that makes a portal usable with a screen reader tends to make it clearer for everyone: clear labels, sensible order and readable contrast help a tired parent on a phone at midnight as much as anyone.

How the stronger programs are run

Strong programs share a few traits. An executive owns the overall outcome, and each of the three layers has a named owner beneath them. There is a single inventory of patient-facing digital services, tagged by layer and by whether the service gates care or payment. Contract language is standard rather than negotiated from scratch each time. Testing includes both automated scans and manual checks of real patient tasks, and results go to the same governance group that oversees web content and digital products.

The weaker ones tend to fail in the same ways:

  • Buying an overlay and calling it done. Some products promise to fix a site by adding a script on top of it. Automated tools have a role, but they do not replace fixing the underlying pages and documents.
  • Treating it as an IT project. Most of the backlog is created by publishing departments and most of the risk sits in contracts signed outside IT.
  • Accepting a conformance report at face value. It is a starting claim rather than proof.
  • Fixing brochures first. Forms and tasks that block care or money matter more.
  • Forgetting regressions. A fix that is not re-tested after the next release may disappear without anyone noticing.

Twelve months, three tracks

Return to the regional health system described above. Suppose its leadership team treats the extension as a twelve-month program with three tracks running side by side.

In the first quarter, the compliance office pulls a list of every supplier from accounts payable and asks each department head whether a vendor produces anything a patient sees, hears or touches. The answers surface the billing firm, the payment processor, the texting service, the kiosk supplier and an after-hours answering service nobody in IT knew about. Each is sent a request for conformance evidence. Meanwhile, the web team inventories the public site and finds that a large share of its PDFs are outdated and can simply be removed.

In the second and third quarters, legal and procurement agree a standard accessibility clause and attach it to every renewal on the calendar. The portal and scheduling contracts gain per-release conformance reports and severity-based fix times. The system joins other health systems in its vendor’s user group to test the scheduling workflow once and file a joint defect list. Publishing departments switch to accessible templates, and the financial assistance application is rebuilt and checked by a person who uses a screen reader.

By the fourth quarter, the board receives one page: the inventory by layer, the contracts updated, the tasks that gate care or payment and their test status, and the gaps that remain. The program needs no new technology, only ownership and a calendar.

Where a patient could still be shut out

  1. Do we have a single list of every digital service patients use, and do we know whether each one is written by us, configured by us or run by a vendor, and who is accountable for each layer?
  2. Which of our patient-facing vendor contracts renew before May 11, 2027, and do they include accessibility warranties, conformance reports, fix times and testing rights?
  3. Which of our forms gate care or financial help, and have they passed a manual accessibility check?
  4. If a patient told us today that they could not use our portal, what alternative would front-line staff offer, and how quickly?
  5. Has counsel confirmed which Section 504 duties apply right now, regardless of the extended dates?

With hindsight

The comment period closed in July, and the extended dates stand as HHS published them, as far as we have seen. Because the change came by interim final rule, and because the National Federation of the Blind’s May lawsuit challenges both the HHS and DOJ extensions, organizations should still confirm the current dates with counsel. An interim final rule can, in principle, be revised after comments, and litigation can change timetables, so the dates are best treated as a planning assumption rather than a guarantee.

The two extensions together set a consistent pattern across federal civil rights rules: 2027 for larger entities, 2028 for smaller ones, and WCAG 2.1 AA as the target throughout. The consistency helps. Health systems that also work with counties, public hospital authorities or state programs can plan against one standard and two sets of dates rather than a patchwork.

Neither extension touched the older duties to communicate effectively and to make reasonable modifications, so patients could still raise complaints in the meantime. The extension changed the date by which a full digital estate must conform; it did not change whether a patient who is shut out today deserves a working alternative.

The PDF backlog remains the stubborn part of the work, and automated tools still need human review. Nothing in the months since has changed the basic arithmetic: documents are produced across many departments, they accumulate, and each one that matters needs a person to confirm it reads correctly.

The procurement point has held up. The patient-facing services that change fastest are the ones hospitals do not build, and the contract is the only place a hospital can set how those services behave. By the time the new date arrives, most patient-facing contracts will have passed through at least one renewal. Whether those renewals carried accessibility terms will largely decide whether the hospital is ready.

Spotted an error? Tell us and we will check it and correct the article where needed.

  • Section 504
  • accessibility
  • HHS OCR
  • vendor contracts
  • patient portals