Audited. Remediated. Maintained.
Not a launch deliverable.

Title II of the ADA, under the DOJ rule finalized in April 2024, requires WCAG 2.1 Level AA conformance for all public-facing web content and mobile apps operated by state and local government entities and the entities they fund or contract with. The conformance deadline is April 24, 2026 for entities with populations of 50,000 or more, and April 24, 2027 for smaller entities and special district governments. The rule covers public agency websites, higher education institutions that receive state or local funding, public hospitals, public libraries, and many nonprofits operating government-funded programs. If you are public-sector or public-sector-adjacent, the rule almost certainly applies to you.

Section 508 is the federal procurement rule. It requires accessible information and communication technology in federal agencies and entities receiving federal funds. WCAG 2.1 AA is the technical baseline. Title II of the ADA covers state and local government entities and entities operating government programs, with the same WCAG 2.1 AA technical baseline. Section 1557 of the Affordable Care Act prohibits discrimination in health programs receiving federal financial assistance and requires meaningful access for people with limited English proficiency along with accessible communications for people with disabilities. Many health departments, federally qualified health centers, public hospitals, and academic medical centers receiving federal funding are subject to Section 1557 and Title II simultaneously. WCAG 2.1 AA is the technical standard that satisfies the accessibility requirements of all three frameworks. The differences are in scope, enforcement, and the documentation a regulator will ask for.

An audit captures the state of the platform on the day it was tested. The minute a content editor publishes a new page, adds a new image without alt text, or embeds a third-party widget that ships with accessibility issues, your audit no longer reflects reality. We treat accessibility as a continuous operational discipline, not a launch audit. The audit closes the existing list. The continuous program prevents the next list from accumulating. Most institutions discover within six months of a one-time audit that they are back to a backlog they cannot keep up with. The standalone audit is a starting point. It is not a finish line.

Automated scanning across every public template and content type. Manual testing against WCAG 2.1 AA success criteria by an accessibility specialist who reads the spec, not a tool. Assistive-technology testing with screen readers (NVDA, JAWS, VoiceOver), keyboard-only navigation, voice control, and zoom/magnification scenarios. Document accessibility review for PDFs, forms, and downloadable assets. A prioritized findings report that distinguishes blockers from polish items, tied to the specific WCAG criterion each finding violates. Remediation guidance written for the engineers who will fix it, not as generic checklist items. We deliver this as evidence your audit committee or your information security officer can reference, not as a screenshot of a Lighthouse report.

Yes, and document accessibility is the most commonly overlooked gap in institutional websites. A site that conforms to WCAG 2.1 AA at the template level can still be effectively inaccessible because the PDFs, board minutes, application forms, and policy documents linked from it are untagged, unstructured, or scanned images. We remediate document accessibility as part of the audit and continuous compliance program: PDF tagging, reading-order correction, form-field labeling, alternative-format provision, and editor workflows that prevent inaccessible documents from being uploaded in the first place.

Editor governance is where most accessibility programs fail. We design CMS-level guardrails into the publishing workflow: required alt-text on image upload, heading-structure validation, link-text quality checks, and inline accessibility feedback in the authoring experience. We train your content team on the editorial decisions that affect accessibility (image alt text, link context, heading hierarchy, video captions, plain-language writing). Recurring office hours and a defined escalation path for accessibility questions keep the program operational beyond the initial training. The goal is a publishing environment where content editors do not have to be accessibility experts to publish accessible content.

Yes, and this is a common engagement starting point. We assess what was delivered, document the actual current state of the platform (which often differs from what the previous vendor reported), identify the gaps between the previous remediation and current WCAG 2.1 AA conformance, and bring the platform to our continuous-compliance operating standard. We have inherited environments where the prior vendor closed an audit by suppressing automated-scan findings rather than fixing them. We do not work that way, and we will tell you honestly what we find.

Quarterly conformance reports tied to WCAG 2.1 AA success criteria. The audit baseline and the remediation evidence for each closed finding. Editor governance documentation showing the controls in place to prevent regression. Automated-scan results across all public surfaces with trend lines. Manual testing logs by an accessibility specialist. The OCR-complaint response posture documentation if your general counsel asks how the platform would defend against a complaint. We design this evidence pack so it satisfies the people who will read it (your audit committee, your CISO, your general counsel, your accessibility coordinator), not as a generic compliance binder that nobody reads until a regulator shows up.

Yes. Accessibility is not a launch deliverable. Every new page template, every new component, every new content type is a new accessibility surface. We work with your design and front-end teams (or ours) to build WCAG 2.1/2.2 AA conformance into the design system at the component level: color contrast, focus states, keyboard interactions, ARIA implementation, and motion preferences. New components ship with accessibility test coverage. Design-system updates do not regress accessibility because regressions are caught in the development pipeline, not in production.

The DOJ rule provides limited exceptions (archived content, preexisting conventional electronic documents not used for current programs, third-party content not under the public entity's control under specific conditions, and individualized password-protected content). These exceptions are narrow and not a safe harbor for an inaccessible primary platform. There is no general extension. The honest answer is that the deadline is real, the enforcement mechanism (OCR complaints, DOJ investigations) is real, and the institutions that have not started are running out of room. We will tell you what the conformance path looks like from where you are, including the realistic timeline. We do not sell a fast remediation that we cannot actually deliver.