Web Compliance for Public Libraries: ADA, Privacy, and What the Law Requires

TL;DR: Public libraries are public entities under ADA Title II, so your website, online catalog (OPAC), and digital services must meet WCAG 2.1 AA under the DOJ’s 2024 final rule — with deadlines of April 2026 or April 2027 depending on your governing population. Much of a library’s most important digital content lives on third-party platforms (catalogs, databases, e-book apps, study tools), which means you must review vendor VPATs and write accessibility into contracts. Patron privacy is both a core professional value and a legal obligation under state library-records confidentiality laws, so audit what your site and its third-party trackers actually collect. Start by inventorying every vendor platform, requesting current VPATs, and running an accessibility scan of your catalog and main site.

Public libraries occupy an unusual and often overlooked position in the world of web compliance. As ADA Title II public entities, libraries carry the same legal accessibility obligations as a city hall or a state agency — but they operate with smaller budgets, leaner IT staff, and a digital footprint that is overwhelmingly composed of third-party platforms the library does not control. A library’s website might be modest, but the online catalog, research databases, e-book lending apps, and learning tools that patrons actually use are built and hosted by vendors like OverDrive, EBSCO, ProQuest, BiblioCommons, and the integrated library system (ILS) provider.

This guide explains what the law requires of public libraries online, how to handle the third-party platform problem, and why patron privacy — long a defining value of librarianship — is also a compliance obligation you can’t ignore. If your library serves the public and receives any state or local government funding, the requirements below apply to you.

Libraries Are Title II Public Entities

The Americans with Disabilities Act divides covered organizations into titles. Title II covers state and local government entities — and public libraries, whether organized as a city department, a county system, a special library district, or a regional consortium, are public entities under Title II. (Independent nonprofit libraries that are open to the public may instead fall under Title III as places of public accommodation; the practical accessibility expectations are similar.)

This matters because in April 2024 the Department of Justice published a final rule under Title II establishing a specific technical standard for web and mobile accessibility: WCAG 2.1 Level AA. Before this rule, the obligation to make digital services accessible existed but lacked a precise benchmark. Now there is one, with hard deadlines:

• April 24, 2026 for public entities serving a population of 50,000 or more.
• April 26, 2027 for public entities serving a population of fewer than 50,000, and for special district governments.

Library systems should determine which deadline applies based on the population of the governing jurisdiction. A county library system serving 400,000 residents is in the 2026 cohort. A small-town library in a community of 8,000 is in the 2027 cohort — but should not wait, because the work takes time. For a deeper walkthrough of the rule, see our guide to ADA Title II obligations for state and local government and the 2026 deadline explainer.

Libraries are also subject to Section 504 of the Rehabilitation Act if they receive federal financial assistance (many do, through LSTA/IMLS grants and E-rate), which independently requires that programs and services — including digital ones — be accessible to people with disabilities.

What “Accessible” Means for a Library Website

The technical standard, WCAG 2.1 AA, breaks down into concrete requirements. The same failures that plague city and county sites show up on library sites, often introduced by the steady stream of program flyers, event listings, and PDF newsletters that library staff publish. The most common problems:

• Missing alternative text on images — book covers, event posters, staff photos, branch maps. See how to fix missing alt text.
• Low color contrast in the library’s brand palette, especially light text on photographic backgrounds and pale link colors. See color contrast on government websites.
• Keyboard traps and unreachable controls in interactive widgets like event calendars, room-booking forms, and “chat with a librarian” tools. See keyboard accessibility.
• Inaccessible PDFs — program calendars, board meeting minutes, annual reports, and scanned local-history documents. PDFs are a particular library weak spot because so much library content is document-shaped. See PDF accessibility.
• Uncaptioned video — recorded storytimes, author talks, board meetings, and tutorial videos. See video captions.

For the full criteria, work through the WCAG 2.2 AA checklist for government. (WCAG 2.2 is backward-compatible with the 2.1 AA legal floor; meeting 2.2 satisfies 2.1.) If you’ve never assessed your site, start with a structured accessibility audit.

Don’t forget the catalog discovery layer

Many library websites are really two systems stitched together: the content management system (WordPress, Drupal, or a vendor CMS) that runs the marketing pages, and the catalog/discovery layer (the OPAC) that handles search, holds, renewals, and account management. Patrons spend most of their time in the catalog. If the catalog isn’t accessible, your library isn’t accessible — no matter how good the homepage is. The catch: you usually can’t fix the catalog yourself, because a vendor builds it. That brings us to the central challenge.

The Third-Party Platform Problem

Here is what makes library web compliance genuinely harder than a typical municipal site: the services patrons depend on most are not yours to remediate.

Consider a typical library’s digital stack:

The DOJ rule does not let you off the hook just because a vendor built the tool. A public entity is responsible for the accessibility of the services it offers to the public, including services delivered through contractors and third-party platforms. You cannot remediate OverDrive’s code, but you can and must make accessibility a procurement and contracting requirement, and you can choose more accessible vendors when alternatives exist.

Request and review VPATs

The practical mechanism for evaluating third-party accessibility is the Voluntary Product Accessibility Template (VPAT) — a standardized document in which a vendor reports how their product conforms to WCAG and Section 508. The output of a completed VPAT is sometimes called an Accessibility Conformance Report (ACR).

For every major platform, request the vendor’s current VPAT and read it critically:

• Check the WCAG version and level it reports against (you want 2.1 AA or 2.2 AA, not an old 2.0 report).
• Look for criteria marked “Partially Supports” or “Does Not Support” — these are the real findings. A VPAT that says “Supports” for everything deserves skepticism.
• Note the date and author. A VPAT from 2019, or one written by the vendor’s marketing team rather than an accessibility evaluator, is weak evidence.

Our guide to VPATs in government procurement walks through how to read these documents and what to require. Build VPAT submission into every database renewal and every new platform contract.

Write accessibility into contracts

A VPAT is a snapshot, not a guarantee. Strengthen it with contract language that:

• Requires the vendor to conform to WCAG 2.1 AA (or 2.2 AA) and to provide a current VPAT/ACR.
• Obligates the vendor to remediate accessibility defects within a defined timeframe.
• Requires accessibility information in any product updates or migrations.

Many library consortia and state libraries negotiate database contracts collectively. That collective bargaining power is your strongest tool — a single small library has little leverage over EBSCO, but a statewide consortium representing hundreds of libraries has a great deal. Push your consortium to make VPATs and accessibility commitments standard contract terms.

Patron Privacy: A Core Value and a Legal Duty

Accessibility gets the headlines, but for libraries, privacy is the deeper professional commitment — and an increasingly important compliance area. The freedom to read, research, and inquire without surveillance is foundational to librarianship, codified in the American Library Association’s Code of Ethics and Library Bill of Rights. It is also, in most of the country, the law.

State library-records confidentiality laws

Nearly every state has a statute protecting the confidentiality of library records — laws that restrict disclosure of what patrons borrow, request, or read. These laws were written for circulation records and reference questions, but their spirit extends to the digital systems that now hold the same information: your catalog accounts, e-book lending history, database search logs, and website analytics.

The compliance question for your website is uncomfortable but necessary: what does your site actually collect, and who does it share it with? Many library websites quietly leak patron behavior to third parties through:

• Analytics and advertising trackers (Google Analytics, Meta Pixel, ad-network tags) embedded in pages or in vendor catalog skins.
• Third-party fonts, chat widgets, and social embeds that phone home with patron IP addresses and browsing data.
• Database and e-book vendor tracking — some vendors monetize usage data in ways that conflict with library privacy ethics.

A patron who searches your catalog for medical, legal, or political topics has a reasonable expectation, rooted in state law and professional ethics, that the search won’t be brokered to advertisers. Audit your trackers. Our guides to state privacy laws and government websites and privacy policy requirements cover the broader landscape; for libraries, layer your state’s library-records statute on top.

Cookie banners and privacy disclosures

If your library serves residents of states with comprehensive privacy laws, or if your site uses non-essential cookies and trackers, you likely need a compliant cookie consent mechanism and a clear privacy notice. See cookie banner requirements. At minimum, every library website should publish a privacy policy that explains what it collects, names the third-party services involved, and describes patron rights — and that policy should match what the site actually does.

A Practical Compliance Roadmap for Libraries

You don’t have to do everything at once. Sequence the work so that the highest-impact, highest-traffic services come first.

1. Inventory your digital stack. List every public-facing platform: website, catalog, each database, each e-content app, each interactive tool. Note the vendor and the contract renewal date for each. This inventory is the backbone of everything else.

2. Scan what you control. Run an accessibility scan of your main website and catalog discovery layer. Free tools like WAVE and axe DevTools are good for page-level review; automated platform monitoring covers the whole site. Triage by traffic — homepage, hours/locations, account login, event calendar, and the catalog first.

3. Request VPATs from every vendor. Send a standard request to each database, e-book, and ILS vendor for a current WCAG 2.1 AA (or 2.2 AA) VPAT. Track responses in your inventory. No VPAT, or a stale one, is itself a finding.

4. Remediate your own content. Fix alt text, contrast, headings, form labels, and PDF accessibility on the pages you control. Train every staff member who publishes content — programming flyers and event listings are a constant source of new failures.

5. Audit privacy and trackers. Inventory third-party scripts on your site and catalog. Remove or replace trackers that conflict with your state’s library-records law and ALA ethics. Update your privacy policy to match reality.

6. Publish an accessibility statement. Tell patrons how to report barriers and request alternatives, and commit to a response timeline. See how to write an accessibility statement.

7. Make it continuous. Libraries publish constantly and renew vendor contracts on rolling cycles. A one-time audit goes stale within months. The government website compliance checklist covers the full scope across accessibility, privacy, security, and performance.

Why Continuous Monitoring Fits Libraries Especially Well

The library compliance picture has two moving parts that make point-in-time audits inadequate. First, content changes daily — every storytime flyer, every event post, every uploaded board packet is a chance to introduce a new failure. Second, vendor platforms change underneath you — a database vendor pushes a redesign, an e-book app updates, the catalog gets a new skin, and accessibility regressions appear without warning. A single audit captures one moment; the law requires sustained conformance.

This is also why libraries, with their thin IT staffing, benefit most from automation. You can’t assign a person to re-check the catalog and every published page each week, but you can monitor continuously and get alerted when something breaks.

Public libraries earned their place as trusted, equitable community institutions — and that trust now has to extend to the digital front door. Meeting WCAG 2.1 AA, managing third-party vendor accessibility through VPATs and contracts, and protecting patron privacy are not separate projects; they’re three faces of the same obligation to serve every patron fairly and confidentially. Govzu continuously monitors library websites and catalog layers for accessibility, privacy, security, and performance issues — so your team catches new failures when a flyer is posted or a vendor pushes an update, not when a patron files a complaint. Start with an inventory, request your VPATs, and put monitoring in place to keep the gains.