Public Library Website Compliance Checklist

TL;DR: Public libraries are public entities under ADA Title II, so your website, catalog, and licensed databases must meet WCAG 2.1 AA (2.2 AA is the safer target) by the April 2026 or April 2027 deadline based on your jurisdiction’s population. The hard part for libraries isn’t your own pages — it’s the third-party OPAC, discovery layer, e-book platforms, and research databases you don’t control. This checklist covers accessibility, patron privacy, security, PDFs, and the vendor VPATs you need to collect and act on.

Public libraries occupy an awkward spot in the compliance landscape. As a unit of a city, county, or special district, your library is a public entity under ADA Title II, which means the 2024 DOJ web accessibility rule applies to your website with the same force it applies to any city hall. But unlike a typical municipal department, a library’s web presence is mostly other people’s software: a hosted catalog (OPAC), a discovery layer, an events calendar, e-book and audiobook apps, and dozens of licensed research databases. You are legally responsible for the accessibility of services you offer to the public even when a vendor builds them.

This public library website compliance checklist walks through every area you need to cover — your own site, your catalog and databases, patron privacy, and security — with concrete actions you can assign and check off. It complements the broader government website compliance checklist but is tailored to the realities of library systems.

First: Confirm Your Deadline

Your compliance deadline under the DOJ rule depends on the population of the government entity your library is part of, not the number of library cardholders.

• Libraries in jurisdictions with a population of 50,000 or more must comply by April 24, 2026.
• Libraries in jurisdictions under 50,000, and all special district libraries, must comply by April 26, 2027.
• Confirm whether your library is a department of a city/county (use that population) or an independent library district (a special district — the 2027 deadline applies).
• The technical standard is WCAG 2.1 Level AA. Target WCAG 2.2 AA instead — it’s a superset and the future-proof choice.

See the local government deadline breakdown if you’re unsure which tier you fall into.

Section 1: Your Own Website (WCAG 2.2 AA)

These are the items fully within your control — your CMS pages, blog posts, program announcements, and staff-authored content. They mirror the WCAG 2.2 AA checklist for government but flagged for library-specific patterns.

Images and Media

• All meaningful images (book covers in featured lists, author photos, event flyers) have descriptive alt text; decorative images use alt="".
• Event flyers and program graphics are not the only source of the date, time, and location — that information also appears as real text. Flyer-only events are a chronic library accessibility failure.
• Storytime, author-talk, and instructional videos have accurate synchronized captions, not unreviewed auto-captions.
• Audio-only content (recorded programs, podcasts) has a transcript.

Color, Contrast, and Layout

• Body text meets 4.5:1 contrast (SC 1.4.3); large text and UI components meet 3:1 (SC 1.4.11).
• “New,” “Available,” and “On hold” status badges don’t rely on color alone.
• Content reflows to a single column at 320px width and 400% zoom (SC 1.4.10) — important for patrons reading on phones.

Keyboard and Structure

• Every interactive element is reachable and operable by keyboard alone, including search autocomplete and “place hold” buttons.
• A visible focus indicator is present (SC 2.4.7, and SC 2.4.11 Focus Not Obscured in WCAG 2.2).
• Headings are properly nested (one <h1>, logical <h2>/<h3>).
• A “Skip to main content” link is present.

Forms

• Library card registration, room booking, and “suggest a purchase” forms have programmatically associated <label> elements, clear error messages, and don’t rely on placeholder text alone. See accessible government forms for the full pattern.
• Don’t use unnecessary CAPTCHA; if you must, follow WCAG 2.2 SC 3.3.8 (avoid cognitive-function tests).

Section 2: The Catalog (OPAC) and Discovery Layer

This is the part of library compliance that has no equivalent at city hall, and it’s where most of the risk lives. Your OPAC or discovery interface — BiblioCommons, Aspen Discovery, the SirsiDynix or Polaris/Innovative public catalog, EBSCO Discovery Service, Ex Libris Primo — is the most-used page on your site, and patrons use it to perform a core public service: finding and borrowing materials.

• Identify every public-facing search/catalog interface patrons can reach and list its vendor.
• Request a current VPAT (Voluntary Product Accessibility Template) for each. The VPAT/procurement guide explains how to read one critically — a VPAT is a vendor self-assessment, not proof of conformance.
• Test the actual hosted interface, not just the VPAT: keyboard-only search, place a hold, manage account, and renew an item with a screen reader (NVDA or VoiceOver).
• Verify faceted search filters (format, availability, language) are operable by keyboard and announced to screen readers.
• Check that catalog record pages expose cover images with meaningful alt text and that “Add to list”/“Place hold” controls have accessible names.
• If you’ve applied local CSS or template customizations to a hosted catalog, audit those — your customizations can break vendor accessibility.
• Document accessibility defects and open vendor support tickets with specific WCAG SC references; track them in your remediation log.

Section 3: Licensed Databases and E-Resource Platforms

Public libraries license research databases, language-learning tools, e-book and audiobook apps (OverDrive/Libby, Hoopla, cloudLibrary), and streaming media. Each is a third-party platform offered to the public on your behalf, so each is in scope.

• Maintain a single inventory of every licensed e-resource and its access URL.
• Collect a VPAT for each platform; flag any that report only partial support for keyboard, screen-reader, or contrast criteria.
• Add an accessibility clause to license renewals and new contracts requiring WCAG 2.1 AA (or 2.2 AA) conformance, a current VPAT, and a commitment to remediate reported defects within a defined window. Procurement is your strongest lever — see the compliance tool procurement guide for clause language patterns.
• Where a platform is inaccessible and can’t be fixed quickly, document an equally effective alternative access path (e.g., staff-mediated retrieval) and publish it.
• Ensure proxy/authentication wrappers (EZproxy, OpenAthens) and your link resolver don’t introduce their own keyboard traps or unlabeled login forms.

A realistic stance: you will not get every vendor to full conformance by the deadline. What regulators and courts look for is a documented, good-faith program — inventory, VPATs, contract requirements, defect tracking, and interim alternatives — not perfection across software you don’t write.

Section 4: Patron Privacy

Libraries have privacy obligations that go beyond the typical government website, rooted in state library-records confidentiality statutes (nearly every state has one) and the profession’s long-standing commitment to the confidentiality of what patrons read and search.

• Publish a clear privacy policy that specifically addresses circulation and search records, retention periods, and the conditions under which records are released (typically only with a court order).
• Minimize retention: don’t keep checkout history longer than operationally necessary, and make patron-visible reading history opt-in, not default-on.
• Audit third-party tracking. Catalog and database vendors, e-book apps, and embedded widgets often set their own cookies and send patron behavior to analytics or ad networks — a direct conflict with library privacy ethics.
• Implement a compliant cookie banner where required, and confirm non-essential trackers don’t fire before consent.
• Serve the entire site, catalog, and proxy over HTTPS so search terms and barcodes aren’t transmitted in clear text.
• Review whether state privacy laws (CCPA-style or sector-specific) add obligations for your jurisdiction.
• Vet vendor data practices in contracts: where is patron data stored, who can access it, and is it ever used for advertising or model training?

Section 5: Security

Library sites handle PII (registration data), payment information (fines, donations, print credit), and authentication, making them worth protecting properly.

• Enforce HTTPS site-wide with HSTS; redirect all HTTP to HTTPS.
• Configure baseline security headers — Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, and a sensible Permissions-Policy.
• Keep your CMS (WordPress/Drupal are common for library sites) and all plugins/modules patched; remove abandoned plugins.
• Review CISA’s guidance for government websites and consider the .gov domain if eligible.
• Ensure self-checkout, payment, and donation flows use a PCI-compliant processor; never store card numbers in your CMS.
• Lock down staff/admin logins with MFA, and audit accounts when staff leave.
• Set monitoring/alerting for TLS certificate expiry — an expired cert takes the catalog offline.

Section 6: PDFs and Digital Collections

Libraries publish a lot of PDFs (board agendas and minutes, annual reports, program calendars, policies) and often host digitized special collections — historical newspapers, photographs, local-history documents — that are essentially scanned images.

• Run an inventory of PDFs linked from the public site; prioritize active documents (current calendars, board packets, forms) for PDF accessibility remediation.
• Ensure born-digital PDFs are tagged, have a reading order, document language, and alt text on images.
• Replace scanned-image board minutes and agendas with text-based, tagged PDFs or, better, HTML pages.
• For digitized collections, apply OCR so the text is selectable and screen-reader accessible; provide text transcripts for handwritten or low-quality scans where feasible.
• Where full remediation of a large historical archive isn’t feasible by the deadline, document the conforming alternate version approach and your prioritization plan. WCAG’s archive provisions and DOJ’s rule allow a measured, risk-based approach for large legacy collections — but you need it written down.
• Prefer HTML over PDF for new content (calendars, policies, board documents) whenever practical.

Section 7: Governance and Ongoing Monitoring

Compliance isn’t a project that ends at the deadline — your library publishes new program flyers, board packets, and catalog records every week, and vendors push interface updates you don’t control.

• Publish an accessibility statement with a feedback/complaint contact and a stated commitment to WCAG 2.2 AA.
• Designate a staff accessibility coordinator and train content contributors on alt text, headings, captions, and links.
• Keep a living remediation log covering your site, catalog, and each vendor platform.
• Re-test the hosted catalog and key databases after every vendor update.
• Run continuous automated monitoring so new staff-published pages and PDFs are caught immediately, not at the next annual audit. See continuous compliance monitoring for government.

For sister checklists tailored to other gov contexts, see the city and county checklist and the state agency checklist.

A public library’s accessibility and privacy posture degrades quietly: a new flyer-only event here, a vendor catalog update there, an untagged board-minutes PDF every month. The libraries that stay compliant aren’t the ones that pass a single audit before April 2026 — they’re the ones that monitor continuously and treat vendor accountability as an ongoing program. Govzu crawls your library’s full web presence on a schedule, flags new accessibility, privacy, and security regressions as they appear, and gives you the evidence trail to hold your catalog and database vendors accountable.