Accessible PDFs and patient forms for practices

Open the patient resources page on a practice website and you will find the documents: the new patient packet, the financial policy, the consent forms, the Notice of Privacy Practices, maybe a medical history form someone scanned on the office copier years ago. For a patient who uses a screen reader, a scanned page is a picture with no text in it. For a patient on a phone, a fillable form built for a letter size page can mean pinching and dragging across each field. The document is on the site, but not each patient can use it.

This guide is about those files. The wider rules for a practice website are in our guide to website accessibility for medical practices, what an intake form should ask and where its answers go is in online patient intake forms, and the nondiscrimination notice and language taglines that belong on the site are in Section 1557 website notices. This one covers PDFs and other downloadable documents: which rules reach them, which exceptions apply, what WCAG asks of a document, and when to replace the file with a web page or form. If you reuse CDC or NIH handouts, see using government patient education materials.

This is general information, not legal advice. Sources cited were checked on October 31, 2026: 42 USC 12181(7)(F) and 12182(b)(2)(A)(iii); 28 CFR 36.303; 45 CFR 84.10, 84.84, 84.85, 84.86, 84.87, 84.88 and 84.89; the HHS interim final rule extending the Section 504 web compliance dates (91 FR 25496, May 11, 2026); 45 CFR 92.202 and 92.204; 28 CFR 35.104, 35.200, 35.201 and 35.202 and the Department of Justice rule extending their dates (91 FR 20902, April 20, 2026); 45 CFR 164.520(c)(3); WCAG 2.1; and the W3C PDF Techniques for WCAG 2.1. We found no federal rule or agency guidance that requires a practice to stop using PDFs as such. Whether your practice receives federal financial assistance, and which rules apply to it, depends on its programs and payers. State law differs, so have a health care attorney review your obligations.

The short version

The ADA lists the “professional office of a health care provider” as a public accommodation (42 USC 12181(7)(F)), and its effective communication rule names “accessible electronic and information technology” among the auxiliary aids (28 CFR 36.303(b)).
For practices that receive HHS financial assistance, the Section 504 rule counts PDFs, word processor files, presentations and spreadsheets as web content (45 CFR 84.10) and requires that web content meet WCAG 2.1 Level A and AA: from May 11, 2027 for recipients with 15 or more employees and from May 10, 2028 for those with fewer (45 CFR 84.84(b)).
Documents posted before your compliance date are excepted, unless they are “currently used to apply for, gain access to, or participate in” your programs (45 CFR 84.85(b)). An intake packet in use today does not fit the exception.
A separate accessible version is allowed under the 504 rule only where it is not possible to make the content directly accessible because of technical or legal limitations (45 CFR 84.86(a)).
WCAG 2.1 applies to a PDF the same way it applies to a page: real text instead of a scanned image, tags for headings and tables, a logical reading order, labeled form fields, a title and a language. The W3C publishes PDF techniques for each.
A form patients fill out is the strongest case for an accessible HTML web form, with the PDF kept for printing.

Which rules reach a PDF on your site

ADA Title III. The ADA’s list of public accommodations includes the “professional office of a health care provider” (42 USC 12181(7)(F)). A public accommodation may not exclude or treat a person with a disability differently because of the absence of auxiliary aids and services, unless it would fundamentally alter what is offered or be an undue burden (42 USC 12182(b)(2)(A)(iii)). The Department of Justice regulation lists examples of auxiliary aids for people who are blind or have low vision, including screen reader software, large print materials and “accessible electronic and information technology” (28 CFR 36.303(b)(2)). It also says auxiliary aids “must be provided in accessible formats, in a timely manner, and in such a way as to protect the privacy and independence of the individual with a disability” (28 CFR 36.303(c)(1)(ii)). A patient who has to ask a family member to read their health history form aloud and fill it in for them is not getting privacy or independence.

Section 504. HHS’s Section 504 rule applies to recipients of HHS financial assistance. It defines “conventional electronic documents” as web content or mobile app content in PDF, word processor, presentation and spreadsheet formats, and lists conventional electronic documents among the examples of web content (45 CFR 84.10). Section 84.84 requires that web content a recipient provides “directly or through contractual, licensing, or other arrangements” comply with WCAG 2.1 Level A and AA. HHS extended the compliance dates by an interim final rule effective May 7, 2026 (91 FR 25496): May 11, 2027 for recipients with 15 or more employees and May 10, 2028 for recipients with fewer than 15. The rule allows a defense where compliance would cause a fundamental alteration or undue financial and administrative burdens, but the decision has to be made by the head of the recipient or a designee and come with a written statement of reasons, and the recipient still has to provide access to the maximum extent possible (45 CFR 84.88).

Section 1557. The Section 1557 rule requires a covered entity to make health programs provided through information and communication technology accessible, with the same fundamental alteration and undue burden limits, and requires recipients’ websites and mobile apps to comply with Section 504 (45 CFR 92.204). It separately requires auxiliary aids and services to be provided free of charge, in accessible formats, in a timely manner and in a way that protects privacy and independence (45 CFR 92.202(b)).

ADA Title II. If your organization is a public entity, such as a county hospital or a public health department clinic, the Department of Justice web rule applies, with the same WCAG 2.1 Level A and AA standard and the same document exceptions (28 CFR 35.200, 35.201). A Department of Justice rule of April 20, 2026 (91 FR 20902) moved the dates to April 26, 2027 for public entities with a total population of 50,000 or more and April 26, 2028 for smaller ones and special district governments (28 CFR 35.200(b)). Title II defines a public entity as a state or local government or one of its departments, agencies or instrumentalities (28 CFR 35.104), so a private practice is not one.

HIPAA. One document has its own posting rule. A covered entity with a website that provides information about its customer services or benefits “must prominently post its notice on the web site and make the notice available electronically through the web site” (45 CFR 164.520(c)(3)(i)). That is the Notice of Privacy Practices. HIPAA does not set an accessibility standard for it; the rules above do.

The document exceptions, read closely

The Section 504 rule lists five exceptions in 45 CFR 84.85, and the Title II rule has the same five in 28 CFR 35.201. Three of them matter for practice documents.

Preexisting conventional electronic documents (84.85(b)). PDFs and other files available on your site before your compliance date are excepted, “unless such documents are currently used to apply for, gain access to, or participate in” your programs or activities. A new patient packet, a consent form, a financial policy patients sign and a records request form are in current use for exactly that. An old newsletter in PDF is a better fit for the exception.
Archived web content (84.85(a)). The definition in 84.10 has four conditions, all required: the content was created before the compliance date (or reproduces older paper or physical media), is kept only for reference, research or recordkeeping, is not altered or updated after archiving, and sits in a dedicated area clearly identified as archived. A folder of current forms is not an archive because it has old files in it.
Individualized, password-protected documents (84.85(d)). Documents about a specific individual, their property or their account that are password-protected or otherwise secured, such as a statement or visit summary in a patient portal. This exception covers the document, not the portal; the portal pages themselves are still web content.

The other two cover content posted by a third party that is not posting under an arrangement with you (84.85(c)), and social media posts from before your compliance date (84.85(e)). A form service, booking tool or portal vendor you contract with is posting under an arrangement, so its content is your web content under 84.84(a).

Accessible alternate versions, and when an HTML form can stand in

WCAG defines a conforming alternate version as one that conforms at the required level, provides all the same information and functionality in the same language, is as up to date as the original, and can be reached from it in an accessible way. The Section 504 rule narrows when a recipient may rely on one: “only where it is not possible to make web content directly accessible due to technical or legal limitations” (45 CFR 84.86(a)). The Title II rule has the same limit (28 CFR 35.202). So a note that says “call us for an accessible version” next to an inaccessible PDF is not, by itself, the plan these rules describe.

There is a different route that does not depend on the alternate version rule: make the accessible version the main one. If patients complete intake through an accessible HTML form on your site, the form is the content, and a PDF offered for people who prefer to print is an extra. The rule also allows other designs, methods or techniques that give substantially equivalent or greater accessibility and usability (45 CFR 84.87). No federal rule we found requires a web form over an accessible PDF. We recommend the web form for anything patients fill out, because it can be built and tested with the same tools as the rest of the site and it works at phone width.

What WCAG 2.1 asks of a PDF

WCAG success criteria are written for web content in general, and the W3C publishes PDF techniques (numbered PDF1 to PDF23) that show one way to meet each. These are the criteria that come up with practice documents, with the related technique:

Real text, not a picture of text. A scanned page is an image. Success criterion 1.1.1 requires a text alternative for non-text content, and 1.4.5 asks that text be used rather than images of text where the technology allows it. Technique PDF7 covers running optical character recognition on a scan, and the result still needs checking and tagging.
Tags for structure. Criterion 1.3.1 requires that structure conveyed visually, such as headings, lists and tables, can be programmatically determined. In a PDF that means tags: headings (PDF9), lists (PDF21) and tables (PDF6).
Reading order. Criterion 1.3.2 requires a correct reading sequence where order affects meaning. Two-column layouts and text boxes on intake forms are where tag order and visual order part ways (PDF3).
Form fields with labels. Criteria 3.3.2 (labels or instructions) and 4.1.2 (name, role, value) mean each fillable field has a name a screen reader announces and a state it can report. Techniques PDF10, PDF12 and PDF5 cover labels, field information and required fields. A form with lines to write on and no fillable fields gives a screen reader user nothing to fill in.
Alt text for images. Logos, diagrams and photos need alternate text (PDF1), and decorative images should be marked as artifacts so they are skipped (PDF4).
Title and language. Criterion 2.4.2 requires a descriptive title (PDF18 sets it in the document properties, not just the file name), and 3.1.1 requires the default language to be set (PDF16). For a Spanish version of a form, the language should be Spanish.
Contrast and phones. Criterion 1.4.3 sets a 4.5:1 contrast minimum for normal text. Criterion 1.4.10 (Reflow) requires content to work at a width equal to 320 CSS pixels without scrolling in two directions, except for parts that need a two-dimensional layout. Check how each document behaves at that width.
Keyboard. Criterion 2.1.1 requires all functionality to work from a keyboard, which for a fillable PDF means moving through and completing each field without a mouse.

Automated checkers in PDF software catch missing tags, titles and alt text. They do not tell you whether the reading order makes sense or whether a label matches its field. A manual pass with a screen reader, and on a phone, is the test that matches what a patient does.

Which documents to fix first

No federal rule we found sets an order. We recommend starting where the exception in 84.85(b) does not reach and where a barrier stops a patient from getting care:

Forms patients must complete before or at the first visit: registration, health history, consent and financial policy.
Documents patients need to act on their rights or their records, such as a records request or authorization form.
The Notice of Privacy Practices, which HIPAA requires on the website (45 CFR 164.520(c)(3)(i)). Post it as an HTML page; a PDF copy can sit beside it.
Your Section 1557 notices, which belong on the site in text, as our Section 1557 notices guide explains.
Preparation instructions and aftercare sheets patients use to follow treatment.
The remaining files: newsletters, older flyers and reference material, which can be updated, archived under the four conditions in 84.10 or replaced with a web page.

Questions to ask your web team or forms vendor

Which documents on our site are PDFs or other downloadable files, and which of them do patients use to register, consent, pay or request records?
Are any of them scans with no text layer?
Can each fillable form be completed with a keyboard alone and with a screen reader, and has someone tested that?
Does each PDF have tags, a reading order that matches the page, a title in its document properties and the right language?
If we replace a PDF form with a web form, does the web form vendor sign a business associate agreement, and what does it cover?
When we update a form, who regenerates the accessible version so the two do not drift apart?
Do the forms inside our booking tool or patient portal meet WCAG 2.1 AA, and can the vendor show its testing?

Use and avoid

Use: an accessible HTML page or form as the main version of anything patients read or complete.
Use: PDFs created from a source file with tags, not printed and scanned.
Use: a clear link name that says the file type and size, such as “New patient forms (PDF, [size])”.
Use: a dated inventory of documents with an owner for each.
Avoid: scanned forms with no text layer as the only way to register.
Avoid: relying on “call for an accessible version” when the document could be made accessible directly.
Avoid: labeling a folder of current forms as an archive.
Avoid: trusting an automated checker’s pass as proof a form works with a screen reader.

An illustration

This example is invented. [Practice name] is a physical therapy practice with [number] employees that, for this example, receives HHS financial assistance. Its patient resources page links to four PDFs: a registration and health history form scanned from paper, a financial policy patients sign, the Notice of Privacy Practices, and an exercise handout from a past event.

The office manager makes an inventory. The registration form and financial policy are in current use, so the preexisting document exception does not apply to them. The team rebuilds registration as an accessible web form, tested with a screen reader and on a phone, and keeps a tagged PDF for patients who want to print. The financial policy becomes an HTML page with a signature step inside the form. The Notice of Privacy Practices moves to its own HTML page with a tagged PDF beside it. The event handout goes into a clearly labeled archive section and is not updated again. A patient who uses a screen reader can now register without asking anyone to read the form to them.

Checklist

List each PDF, word processor, presentation and spreadsheet file on the site and in the patient portal.
Mark which ones patients use to apply, register, consent, pay or request records.
Find scans with no text layer and replace them first.
Rebuild forms patients fill out as accessible web forms, with a tagged PDF for printing.
Post the Notice of Privacy Practices and Section 1557 notices as HTML text.
For each remaining PDF, check tags, reading order, field labels, alt text, title and language.
Test with a screen reader, a keyboard alone and a phone.
Move reference files into an archive section that meets all four conditions in 45 CFR 84.10, or update them.
Ask vendors whose forms appear on your site for their WCAG 2.1 AA testing.
Note your compliance date under 45 CFR 84.84(b) and confirm with your adviser whether the rule applies to you.

How we help

We build websites, local and organic search, Google Ads and lead generation and an AI front desk for independent practices. For patient documents, that means an inventory of the files on your site, HTML pages and web forms in place of scanned PDFs, and testing with a keyboard, a screen reader and a phone before launch. Our tools are built with HIPAA in mind. We confirm in writing what a BAA covers before any patient information flows through a tool, and if it is not covered, we do not route patient information through it. We are not a healthcare provider and we do not give legal or medical advice. For the wider rules, see our healthcare marketing rules guide.

Do PDFs on our website have to be accessible?

For recipients of HHS financial assistance, yes: the Section 504 rule counts PDFs as web content that must meet WCAG 2.1 Level A and AA from May 11, 2027 (15 or more employees) or May 10, 2028 (fewer than 15), subject to the exceptions in 45 CFR 84.85. Under ADA Title III there is no regulation that sets a technical standard for private practice websites, but the effective communication rule in 28 CFR 36.303 applies to how you communicate with patients.

Our PDFs were posted years ago. Are they exempt?

Only if patients do not currently use them to apply for, gain access to, or participate in your programs (45 CFR 84.85(b)). Intake, consent and financial forms in use today do not fit. Older reference files may, or may fit the archive exception if they meet all four conditions in 45 CFR 84.10.

Can we just offer an accessible version on request?

Under the Section 504 rule, a conforming alternate version is allowed only where it is not possible to make the content directly accessible because of technical or legal limitations (45 CFR 84.86(a)). Patients can still ask for auxiliary aids, which 45 CFR 92.202 and 28 CFR 36.303 require where needed for effective communication, but the 504 rule expects the posted content itself to be accessible.

Is a fillable PDF enough, or do we need a web form?

No federal rule we found requires one over the other. A fillable PDF can meet WCAG 2.1 if its fields are labeled, tagged and usable with a keyboard. We recommend a web form for forms patients complete, because it works at phone width and can be tested with the rest of the site. The privacy side of web forms is in our intake forms guide.

What about statements and visit summaries in our patient portal?

Documents about a specific patient that are password-protected or otherwise secured are excepted from 45 CFR 84.84 (45 CFR 84.85(d)). The portal pages patients use to reach them are not excepted, and a patient who needs a document in another format can still ask for an auxiliary aid under 45 CFR 92.202 and 28 CFR 36.303.

Sources

More in Practice websites, privacy and tracking

Accessible PDFs and patient documents on a practice website