Design
Digital Editions and Accessible PDFs
Web-optimized PDFs, interactive flipbooks, and accessible versions of the publication, built to WCAG rather than repaired after.
What this covers
This service produces the digital editions of a publication: an interactive flipbook for the agency website and a web-optimized PDF for download, built as an accessible file that works with screen readers, magnification, and keyboard navigation. It also covers, where it serves residents better, publishing key content such as program listings as web pages.
It suits communications offices, parks and recreation departments, libraries, and any department posting guides or reports. Print and digital editions usually share one InDesign file, so the digital work is planned at the start of production, not the end.
A PDF can look finished and still be unusable. A file exported without tags, or with tags out of order, reads as a jumble to a screen reader. Many flipbooks display pages as images. Repairing a long file after export is slow, and the repair is lost at the next export.
How we do it
- Map styles to tags in the template. We assign each paragraph style an export tag (headings to H1, H2, or H3, body text to P), so structure comes from the layout, not hand tagging. Real headings let screen reader users move by section.
- Set reading order in the Articles panel. Multi-column pages and sidebars are where reading order breaks, so we add content to the Articles panel in reading sequence and use that order for the tagged export.
- Write alternative text at placement. Alt text goes into object export options as each image is placed. Decorative shapes and rules are marked as artifacts so assistive technology skips them.
- Build tables as real tables. Schedules and fee charts use table and cell styles with defined header rows. Tables built from tabs or loose text frames lose their structure.
- Set document properties and navigation. Each file gets a document title shown in the title bar, a document language (including on translated editions), bookmarks that follow the headings, and link text that makes sense on its own, such as a program name rather than "click here."
- Check color contrast during layout. Text and background pairs are checked against WCAG 2.1 AA while a color is still easy to change, not after approval.
- Test with a checker and a person. We run an automated accessibility checker, then review the file with a screen reader to confirm that reading order makes sense and alt text is accurate.
- Treat the flipbook as covered content. The Title II rule applies to the flipbook itself; a separate accessible version is allowed only where technical or legal limits make direct accessibility impossible. We review the vendor's accessibility conformance report, test the flipbook with a keyboard and screen reader, and post the accessible PDF or a web version alongside it.
- Move key content to web pages where it serves residents better. Program listings and schedules are often easier to search, read on a phone, and update as web pages. When that content already lives in a registration system or calendar, we build from that source so guide and website agree.
What you receive
- A web-optimized, accessible PDF of the approved publication, built and tested to WCAG 2.1 AA, with PDF/UA (ISO 14289) as the structural target.
- A flipbook edition, tested and linked to the accessible PDF, with the vendor's conformance report on file.
- A test record of checker results, screen reader findings, and how each issue was resolved or why it remains open.
- The InDesign template with export tags and table, cell, and object styles configured, so future issues inherit the structure.
Considerations for public agencies
- The Title II rule covers posted documents. The Department of Justice final rule published in April 2024 adopts WCAG 2.1 Level AA for state and local government web content, including posted PDFs and content built or run by contractors. Compliance dates depend on entity size and were extended in April 2026; the standard and exceptions did not change. Confirm current dates with the Department of Justice, which has said it may review the requirements further.
- Exceptions for past issues are narrow. Archived content qualifies when it was created before the compliance date or reproduces paper documents from before that date, is kept only for reference, research, or recordkeeping, is not changed after archiving, and sits in an area clearly identified as archived. Preexisting conventional electronic documents are excepted unless still used to apply for or access a service, so a current guide used for registration does not qualify. Effective communication is required regardless, so plan to supply an accessible version or alternative format on request. Confirm with counsel.
- Every posted file has a test record. HQT delivers each file tagged and tested, with a written record of anything left unresolved and why.
- Digital editions can be public records. Posted PDFs, replaced versions, and test records may fall under retention schedules. Confirm requirements with the records officer.
- Platforms and ownership. Flipbook platforms are usually subscriptions, so check what happens to hosted editions and links if the agency switches platforms. The contract should state that the agency owns the template and files. Fonts stay under their own licenses, which may require the agency to hold its own font licenses or Adobe Fonts access to edit the files, as described on the production calendars, proofing, and file handover page.
Starting an engagement
An engagement begins with a review of current digital editions: a sample of posted PDFs run through a checker and a screen reader, the InDesign template, the flipbook platform, and the publication calendar. From that review HQT identifies what to fix in the template so the next issue is built accessible, and which past issues to remediate, archive, or replace with web pages.
Frequently asked questions
If our PDF passes an automated accessibility checker, is it accessible?
Not necessarily. Automated checkers confirm that tags, alternative text, a document title, and a language are present, but they cannot tell whether the reading order makes sense or whether the alt text describes the image accurately. A file can pass and still confuse a screen reader user. A manual review with a screen reader is the step that catches those problems.
Is a flipbook on our website accessible enough on its own?
Often it is not. Many flipbook platforms render pages as images, which screen readers cannot read as text. The flipbook is web content covered by the Title II rule, and a separate accessible version is allowed only where technical or legal limits make direct accessibility impossible. Ask the vendor for an accessibility conformance report, test the flipbook with a keyboard and screen reader, and also post an accessible PDF or web version.
Do we have to fix every past issue already posted on our website?
Not necessarily. Past issues may fall under the archived web content exception if they meet all of its conditions, including being kept only for reference, research, or recordkeeping, left unchanged, and stored in a clearly identified archive area. A document still used to register for or access a program does not qualify for the preexisting document exception. The agency must still provide effective communication on request, so confirm your approach with counsel.
When do the Title II web accessibility requirements apply to us?
It depends on your entity's size. An interim final rule published April 20, 2026 set compliance dates of April 26, 2027 for public entities with a total population of 50,000 or more, and April 26, 2028 for smaller entities and special district governments. The Department of Justice has said it may review the requirements further, so confirm the current dates on its official ADA website before planning around them.
Does building accessibility in add time to our production calendar?
Most of the work moves into the template and layout, where it is set up once and reused for every issue. The step that needs its own place on the calendar is testing, between final approval and posting. Repairing a file after export usually takes longer and has to be repeated whenever the document is revised.