Skip to main content
← Back to Blog
Accessibility · Title II

Title II web readiness checklist: what teams can do before 2027 and 2028

Title II web readiness checklist: what teams can do before 2027 and 2028

Practical Title II / WCAG 2.1 AA readiness checklist for web and marketing teams - educational guidance, not legal advice.

August 25, 2026 6 min read

Title II web readiness checklist: what teams can do before 2027 and 2028

If your organization builds or maintains websites for state or local government - or you partner with agencies that do - accessibility timelines are no longer abstract. Under the U.S. Department of Justice’s Title II web and mobile accessibility rule, covered public entities must make web content and mobile apps conform to WCAG 2.1 Level AA.

Important dates (as extended):

  • April 26, 2027 - public entities with a population of 50,000 or more
  • April 26, 2028 - smaller public entities and many special districts

This post is practical guidance for web and marketing teams, not legal advice. Compliance scope, exceptions, and whether a specific site is covered depend on your counsel and the rule’s text. When in doubt, involve legal and accessibility specialists early.

The useful move now is not panic. It is a calm inventory: what do we publish, who can use it, and what do we fix first?

What “readiness” actually means

Title II readiness is less about a last-minute redesign and more about governed digital operations:

  1. You know which sites, apps, PDFs, and third-party tools are in scope.
  2. You can test against WCAG 2.1 AA in a repeatable way.
  3. New content and components don’t reintroduce barriers.
  4. You have a backlog and owners - not a single hero sprint.

WCAG 2.1 AA covers perceivable, operable, understandable, and robust criteria: captions and alternatives, keyboard access, contrast, form labels, focus order, error identification, and more. Treat it as a quality bar for every release, not a one-time audit badge.

Checklist for teams (start here)

Use this as a working list. Adjust with your counsel and any internal accessibility policy.

1. Map what you publish

  • Inventory public websites, microsites, portals, and mobile apps
  • List major third-party embeds (maps, chat, video, payment, calendars)
  • Flag document libraries (PDFs, Word, slide decks) that users must download to get the same information
  • Note who owns each property: IT, communications, department, vendor

Why it matters: You can’t remediate what you haven’t named. Many gaps live in “that old PDF on the shared drive” or a widget nobody remembers approving.

2. Confirm the technical standard you’ll hold

  • Align stakeholders on WCAG 2.1 AA as the shared bar (matching the Title II technical standard)
  • Decide how you’ll handle content that falls under any documented exceptions your counsel identifies
  • Document how new features get reviewed before launch

Why it matters: Teams stall when “accessible” means different things to design, vendors, and legal. Write the bar down.

3. Establish a baseline (without waiting for perfection)

  • Run automated scans on key templates (home, search, forms, login, popular service pages)
  • Pair automation with manual keyboard and screen-reader checks on critical user journeys
  • Sample forms: labels, errors, required fields, timeouts
  • Check media: captions, transcripts, audio descriptions where needed
  • Spot-check color contrast on brand colors and UI states (focus, hover, disabled)

Why it matters: Automation finds many issues and misses others. Manual checks catch focus traps, unlabeled controls, and content that “passes” a scanner but fails a real user.

4. Prioritize by risk and use

  • Rank journeys: apply for a service, pay a bill, find a meeting, file a complaint, contact support
  • Fix blockers that stop people from completing those journeys first
  • Schedule lower-traffic template debt next (don’t ignore it - just sequence it)

Why it matters: A perfect footer on a rarely visited page helps less than a usable application form.

5. Fix the system, not only the tickets

  • Put accessibility into design and CMS component standards (headings, alt text fields, form patterns)
  • Require vendors to meet WCAG 2.1 AA in contracts and acceptance criteria
  • Train editors: headings, link text, image alternatives, tables, document exports
  • Add a11y checks to QA before major releases

Why it matters: One-off remediations return when the CMS still lets editors publish inaccessible patterns.

6. Plan for documents and archives

  • Prefer HTML for essential information when possible
  • Remediate high-use PDFs; set a standard for new document publishing
  • Define an archive / historical content approach with legal guidance

Why it matters: Document debt is often the longest tail. A policy for new PDFs stops the pile from growing while you catch up.

7. Assign owners and a cadence

  • Name a product or program owner for web accessibility
  • Set a recurring review (monthly or quarterly) for backlog and metrics you care about (open critical issues, template coverage)
  • Keep a simple public or internal statement of commitment if your org expects one - accurate language only

Why it matters: Deadlines without owners become last-minute crises. Cadence turns readiness into operations.

What mid-market and agency partners can do this quarter

Even if you are not a covered public entity yourself, you may build for one - or for organizations that mirror public-sector expectations.

Practical moves:

  • Audit before rebuild. Know whether the problem is templates, content process, or both.
  • Componentize accessibility. Shared Drupal or WordPress patterns (forms, cards, navigation) reduce drift.
  • Budget for stewardship. Updates, media, and PDF workflows need ongoing time - not only a launch sprint.
  • Ask vendors clear questions. How do you test? Which journeys? Who remediates content vs. code?

Responsab builds and supports Drupal and WordPress sites with accessibility in mind as part of maintainable delivery. We help teams see what’s broken, what’s urgent, and what belongs in a care plan - without inventing fear or false guarantees.

Soft next step

If you want a clearer picture of where your site stands against common WCAG 2.1 AA failure patterns, start with a site health check. We’ll look at structure, templates, and practical risk - then talk options.

This article is for educational purposes and is not legal advice. Confirm coverage, deadlines, and obligations with qualified counsel.

Site Audit

Next Step

Need help applying this to your own site or delivery workflow?

We help teams turn these same ideas into practical launches, cleaner CMS delivery, and long-term support.

Book a Meeting