What ADA Title II means for your open source CMS
If you run a multi-site CMS as a state or local government body or a public university, the ADA Title II rule requires your web content to meet WCAG 2.1 Level A and AA, and the deadline depends on your size: 26 April 2027 for entities serving 50,000 or more people, and 26 April 2028 for smaller entities and special districts. The rule reaches content provided through contracts or licenses, so your CMS platform, themes, plugins, modules and vendor-supplied content all fall inside the scope, not only the pages your staff write. A Drupal or WordPress estate is therefore one system to assess, including the templates shared across sites and the third-party components they load. The rule text is at ADA.gov's web rule page, and the codified requirement is in 28 CFR 35.200.
Confirm early which deadline applies to each legal entity in your estate, because a university system or county may run sites under different governing bodies with different population counts. Then inventory every component that renders public pages: the CMS core version, the theme and its design system, contributed or third-party modules and plugins, embedded forms, video players and tracking scripts. Ask whether each vendor has documented WCAG 2.1 AA conformance for the features you use, and record which items you will remediate yourself and which you will require the vendor to fix in writing.
DeployOpen plans and implements the technical work: upgrading the CMS and theme to supported versions, remediating templates and components, configuring the editorial workflow and keeping test results and remediation records. DeployOpen prepares systems and evidence for review; it does not issue audit reports or conformance certifications. Conformance is assessed by independent auditors and your own accessibility office, so scope the engagement in writing with the evidence each party will receive and agree on what "conformant" means for your sites before work starts.
How each ADA Title II obligation maps to CMS configuration
This table maps the main WCAG 2.1 Level A and AA requirement categories, plus the WCAG 2.2 additions agencies may adopt as a stretch target, to what the CMS must do and how Drupal or WordPress is typically configured to support it. Read it as a starting point for the audit backlog, not as proof of conformance, since conformance depends on the actual pages, templates and content your editors publish. The main takeaway is that most failures originate in themes, components and editor habits, so configuration and governance must be tested together.
| Requirement | What the function must do | How to configure Drupal or WordPress |
|---|---|---|
| Text alternatives (1.1.1) | Every non-decorative image, icon and media object has a text alternative that matches its purpose | Make alt text a required field in the media library on Drupal, or enforce it through editor settings and a block-editor check on WordPress; confirm which plugins your theme already provides |
| Captions and audio description (1.2) | Prerecorded and live video provide captions, and audio description where the content requires it | Use a media type that stores caption tracks as separate files; confirm how your video host or embed plugin passes caption metadata to the page |
| Adaptable structure (1.3.1, 1.3.2) | Headings, lists, tables and form labels are coded semantically and read in a logical order | Lock heading levels in the theme and editor styles; restrict raw HTML for editors; test that tables and form labels render with correct markup |
| Color and contrast (1.4.3, 1.4.11) | Text and interface components meet the minimum contrast ratios defined in WCAG 2.1 | Set brand color tokens in the theme and test them against the ratios before publishing; avoid editor-chosen text colors |
| Keyboard access (2.1.1, 2.1.2) | All functions work by keyboard and focus can always move away from any component | Verify menus, accordions, carousels and modal components in the theme; confirm any third-party embed or widget traps focus |
| Timing and motion (2.2, 2.3) | Time limits can be extended and content does not flash beyond thresholds | Disable autoplay carousels by default in the component library; confirm no template animates content faster than the threshold |
| Navigation and page titles (2.4.1, 2.4.2, 2.4.4) | Skip links, unique page titles and descriptive link text are present on every page | Add a skip link and a required title field to content types in Drupal or the theme template on WordPress; audit generated link text in listing views |
| Focus Not Obscured (2.4.11, WCAG 2.2) | Focused elements are not hidden behind sticky headers, cookie banners or chat widgets | Set scroll-padding and z-index rules in the theme; test sticky headers and consent banners with a keyboard |
| Target Size (Minimum) (2.5.8, WCAG 2.2) | Pointer targets meet the minimum size or spacing defined in WCAG 2.2 | Set minimum padding for buttons, pagination and footer links in the design system; include the check in component tests |
| Accessible Authentication (Minimum) (3.3.8, WCAG 2.2) | Login and editor sign-in do not depend on memory or puzzle-style tests without an alternative | Use SSO through a SAML or OpenID Connect module for editors, and confirm that any public login or form offers a non-cognitive path |
| Form labels and errors (3.3.1, 3.3.2, 4.1.2) | Inputs have programmatic names, errors are identified in text and status changes are announced | Configure webform or form plugin labels, error summaries and ARIA live regions; retest after every form template change |
Choosing Drupal or WordPress for an accessible public estate
Drupal core suits large multi-site estates that need a managed release cadence, role-based editorial control and a single codebase governed across many departments or agencies. The current major version is Drupal 11, and Drupal 10 reaches end of life on December 9, 2026, so any estate still on Drupal 10 needs a dated upgrade plan before that point. Drupal 7 security support ended on January 5, 2025, and Drupal 6 and 7 sites cannot be updated in place to Drupal 10 or later.
- Release rhythm: Bugfix releases ship on the first Wednesday of each month and security releases on the third Wednesday, so the patch process should be scheduled around those dates.
- Major version timing: Drupal 12 is scheduled for the week of December 7, 2026, and the PHP requirement rises with each major version (PHP 8.3 for Drupal 11, PHP 8.5 for Drupal 12).
- Migration from Drupal 7: Sites are migrated into a new build with the core Migrate modules or Drush, and themes must be rebuilt, which adds accessibility testing work to the project.
- Licensing: Drupal core and derivative contributed modules are GPL-2.0-or-later, and there is no paid edition of Drupal itself, so costs sit in build, hosting and support.
- Authentication: The contributed SAML Authentication module (samlauth) and OpenID Connect module support enterprise sign-in for editors.
Confirm with your team which Drupal version each site runs today, the PHP version on each host, and who owns the patch calendar across the estate.
WordPress fits smaller estates with a simpler editor base, a limited number of sites and a team that prefers a familiar block editor. The current release is WordPress 7.1.3, released on October 6, 2026, and WordPress.org states that only the most recent release in the 7.1 series is actively maintained. That means a site must follow each point release in the series, since a site held on an older 7.1 point release is not receiving maintained fixes.
- Release discipline: Plan for updates to the latest 7.1 point release as they arrive, with a staging test cycle before production.
- Plugin footprint: Accessibility depends on themes and plugins, so each third-party component needs its own accessibility review and an owner who will keep it current.
- Multi-site limits: WordPress multisite is workable for a modest network, but estates with hundreds of sites need a deliberate architecture decision and a strong governance model.
- Editor governance: Built-in roles cover most small teams, but approval workflows for public content usually depend on plugins that must be assessed for maintenance status.
- Licensing: WordPress is GPL-licensed, so the cost drivers are theme design, plugin selection, hosting and support.
Confirm the number of sites, the plugins in use and whether each one has been tested against the WCAG 2.1 AA success criteria before the compliance date that applies to your entity.
Drupal CMS is a distribution built on Drupal core for marketers and content teams. It packages recipes and site templates, the Drupal Canvas visual page builder (previously Experience Builder) and optional AI tools, and Drupal CMS 2.0 is the current major release. It reduces initial setup effort for teams that want a faster start, but it does not change the underlying core support model, so the same upgrade and security obligations apply.
- Recipes and templates: Recipes provide repeatable site components, which can help consistency across departmental sites when the templates have been reviewed for accessibility.
- Visual page builder: Editors gain layout control, so accessibility rules such as heading order, alternative text and focus behavior must be enforced in the components themselves.
- Optional AI tools: Any AI feature that generates or edits public content needs its own review for accuracy and accessibility, and the data it sends must be assessed.
- Distribution updates: Confirm how distribution updates are delivered and tested against your custom code before applying them.
- Maturity check: Ask whether each recipe and module you plan to use is maintained and matches the Drupal core version you run.
Confirm that the distribution's components pass your accessibility test suite before editors build pages with them, and document which recipes are approved for public use.
Both platforms require a dated support plan, because the ADA Title II rule applies to content and to the software that produces it, and an unsupported platform makes remediation harder to sustain. The two products differ in how they publish support windows, so the operating model must be written for each. Drupal publishes a release schedule with set dates, while WordPress maintains only the newest release in each series.
- Drupal support windows: Drupal 10 end of life on December 9, 2026 is a fixed date that belongs in the estate's risk register.
- WordPress support windows: Because only the latest release in a series is maintained, the operating model should assume rapid point-release updates.
- Security patch ownership: Name the team that applies security releases and the time it has to do so after each release date.
- Accessibility regression testing: Both platforms need an automated and manual test pass after core, theme and plugin updates.
- Hosting and support contracts: Support, hosting and upgrade services are the recurring cost, and they should be priced from the written scope.
Ask any implementation partner to show its release calendar, its test evidence from the last two security cycles and how it handles an end-of-life version on your estate.
The decision turns on estate size, editor count, governance needs and the skills your team can keep. Drupal core is usually the stronger fit where many sites share components, roles and approval workflows across departments. WordPress is usually the lighter fit where the estate is small, editors are generalists and the team can manage a smaller plugin footprint. The choice is not permanent, but migrating later costs design, content and accessibility work.
- Estate size: Count sites, languages and editors today and in three years to test the platform choice against growth.
- Governance needs: Shared components, central approvals and per-site permissions favor a platform built for those patterns.
- Plugin and module risk: Review each third-party component for maintenance status and accessibility before selecting the platform.
- Internal skills: Confirm who will maintain PHP, the database and the theme after launch.
- Migration exposure: Estates on Drupal 6 or 7 face a rebuild rather than a simple upgrade, which changes the comparison.
Before deciding, confirm the current version of every site, the number of accessibility defects in the last audit and whether a partner will test both options against the same sample pages.
Which open source platforms fit an ADA Title II estate
Public entities choosing a CMS for ADA Title II work need a platform whose accessibility is verifiable in themes, modules and editor tooling, not just claimed. The options below differ mainly in how much accessibility work ships in core and how much the client must build and test around it.
Drupal core
Drupal core is GPL-2.0-or-later with no paid edition, so the accessibility cost sits in design, build and testing rather than licensing. Core theming and the administrative interface are the starting point for WCAG 2.1 AA work. Confirm which core version your estate will run, check the release schedule for Drupal 10 end of life, and test the editor, forms and media components your content teams will use.
Drupal CMS 2.0
Drupal CMS 2.0 is a distribution built on Drupal core for marketers and content teams, with recipes, site templates, the Drupal Canvas visual page builder and optional AI tools. Visual page builders can produce markup that drifts from accessible patterns, so each recipe and component needs an audit before it becomes the default for editors. Confirm which recipes and AI features are enabled and how they are reviewed.
WordPress
WordPress is GPL-licensed and widely used for public sites, but accessibility depends heavily on the theme and plugins chosen. Block-based editing and third-party page builders can introduce headings, contrast or keyboard issues that a site-wide audit must catch. Confirm the current release and the maintenance policy, since only the most recent release in the 7.1 series is actively maintained, and require accessibility evidence for every theme and plugin.
Headless front end on Payload
Payload is an MIT-licensed Next.js framework that can serve as a headless CMS, which suits estates where a separately built design system owns the accessible front end. Accessibility then rests on the component library, its testing and the editor experience, so the agency must own those controls explicitly. Confirm how the design system is tested for WCAG 2.1 AA and how preview and keyboard behavior work in the admin interface.
Headless front end on Strapi
Strapi is MIT-licensed except components under ee directories, which form the separately licensed Enterprise Edition. Confirm that the features your estate needs, such as particular SSO or audit capabilities, sit outside the Enterprise Edition or are licensed for your use. As with other headless options, the accessible front end and its testing belong to the agency's design system and release process.
How a Drupal or WordPress estate is audited and remediated
The sequence starts with a complete inventory of sites and vendor-supplied components, then tests a representative sample against WCAG 2.1 AA, fixes shared themes before single pages, and keeps fixes from regressing through the release pipeline. The output is a remediation record that shows what was checked, what changed and what still needs work.
Inventory every site and vendor component
Build a register of every site, subsite, theme, module or plugin, form, embedded widget and third-party script in the estate. Include content supplied by vendors, such as embedded booking tools, PDF generators and document viewers, because the ADA Title II rule covers web content provided through contracts or licenses. Record the owner, the CMS version and whether each component is maintained. The output is a signed inventory that the university or agency can use as the scope baseline for the written engagement.
Sample templates and page types
Group the inventory into templates and page types, such as the homepage, news article, department landing page, document listing, application form and search results. Select representative pages from each group, including pages built with the most complex components. Because the number of sites and pages drives effort, the sample is what keeps a large estate testable. The output is a sample set mapped to templates, with the reason each page was chosen.
Test with automated and manual methods
Run automated checks on the sample and the full crawl where the tooling allows, then have an assessor test by hand with keyboard-only navigation, screen readers, zoom and reflow, and forms with error states. Automated tools catch a subset of WCAG 2.1 AA failures, so manual testing is needed for focus order, meaningful alternative text and logical headings. Each finding is logged with the success criterion, the URL, the component and a reproduction step. The output is a defect log tied to WCAG 2.1 AA criteria.
Prioritize fixes in shared themes first
Group defects by root cause. A color contrast problem in the base theme or a missing label in a shared form component may appear on hundreds of pages, so fixing it once in the theme or component library removes many findings. Single-page content errors, such as missing alternative text on one image, are fixed by the content owner. The output is a ranked backlog in which shared theme and component fixes come before page-level work, with an owner assigned to each item.
Fix in the release pipeline
Make the corrections in code and configuration under version control, not only in the live site. For Drupal, this means theme and module changes tracked in the repository and deployed through the normal pipeline. For WordPress, it means child theme and plugin changes handled the same way. Add automated accessibility checks to the build so new defects fail before release. The output is a merged change set, a deployment record and a pipeline check that runs on future changes.
Retest and document the result
Retest the fixed templates and the defects that were logged, then retest a sample of the content that editors have published since the fixes. Record which findings are closed, which remain and the plan for each open item. Keep the test scripts, tool versions, assessor notes and the date of each test. The output is a remediation report and an accessibility statement draft, which the organization reviews with counsel before publication. Independent auditors, not DeployOpen, issue any conformance opinion.
Confirm the timeline in the written scope
No duration for an audit or remediation is supplied for this page, so ask the partner for a timeline in the written scope. It should reflect the number of sites, pages, templates, vendor components and languages, and it should separate the audit, the shared-theme fixes and the page-level content work. Ask which parts the organization's editors must complete and what the partner needs from the internal team. The output is a signed scope that sets milestones before work starts.
Which evidence an auditor or the agency will ask to see
This table maps each evidence item an auditor, agency reviewer or accessibility office is likely to request to what it shows and which part of the Drupal or WordPress estate produces it. Use it to plan evidence collection before the April 26, 2027 or April 26, 2028 compliance date rather than assembling it at audit time. DeployOpen prepares this evidence, but independent auditors and certification bodies issue any attestation.
| Evidence item | What it shows | Which component produces it |
|---|---|---|
| WCAG 2.1 AA test reports per template | Which success criteria each page template passes or fails, tested against the rendered page rather than the source code alone | Automated scans plus manual testing with assistive technology, run against each template in the CMS theme and component library |
| Remediation tickets | Each defect found, its WCAG 2.1 success criterion, severity, owner, fix date and retest result | Issue tracker linked to the CMS release process, with retest records attached to each closed ticket |
| Release accessibility checklist | That each release was checked for accessibility before it reached production, and who signed off | Release pipeline gate and a signed checklist stored with the release notes for each deployment |
| Vendor accessibility statements for contracted components | What accessibility conformance the third-party modules, plugins, embeds and SaaS add-ons claim, which the rule covers when provided through contracts or licenses | Procurement file and a component inventory that lists every contributed module, WordPress plugin and embedded widget with its vendor statement |
| Content review records | That editors reviewed published content for alternative text, headings, captions and document accessibility, and when each page was last reviewed | Editorial workflow states, review dates and reviewer records kept in the CMS revision history |
| Public accessibility statement and feedback path | The conformance status, known limitations, contact method and feedback process the public can use | Published statement page maintained through the CMS, with the feedback form logged in a ticket queue |
| Patch and update logs from the CMS | Which core and contributed updates were applied, when, and whether security releases were applied within the organization's stated window | Deployment records, Drupal or WordPress update history, and hosting change logs covering each core and module update |
| Accessibility regression results after updates | That core, theme or module updates did not reintroduce failed criteria on key templates | Scheduled regression tests run after each update, with results stored alongside the patch log |
What tooling alone does not satisfy
A Drupal or WordPress estate can meet WCAG 2.1 AA only if people, contracts and release habits hold up after launch. The gaps below sit outside the CMS itself, and each one is a place where a compliant site can drift out of conformance.
Scanners cannot prove conformance
Automated checkers catch a subset of WCAG failures, such as missing alt attributes and empty links, but they cannot judge whether alt text is meaningful, whether focus order makes sense or whether a form error is understandable. Overlays and widgets that promise automatic compliance do not change the underlying markup. Ask any partner to show a manual test plan covering keyboard use and screen reader output on key journeys, with results recorded per template.
Editors publish inaccessible files
A compliant template does not stop an editor from uploading a scanned PDF, an untagged Word document or a video without captions. Under Title II these files count as state and local government web content. Set a publishing rule that routes new documents through a check, and add a field for an accessible alternative where the source file cannot be fixed.
Vendor content needs contract terms
The rule covers web content provided through contracts or licenses, so a vendor-built microsite or a purchased course page is still your obligation. Write WCAG 2.1 AA deliverables, test evidence and remediation timelines into statements of work. Require the vendor to name who tested, which assistive technologies were used and how defects found after launch are fixed.
Third-party embeds break access
Maps, chat widgets, booking tools, survey iframes and tracking scripts often ship their own focus traps, unlabeled buttons and inaccessible modals. Your CMS team cannot fix code it does not control. Inventory every embed per page, test it with a keyboard and a screen reader, and keep a documented exception or replacement plan for any that fails.
Release cadence keeps conformance current
Accessibility is lost when core, theme or module updates change markup without a regression check. Drupal publishes security releases on the third Wednesday of the month, and WordPress maintains only the most recent release in each series. Build a staging environment with automated scans and a short manual spot check into each update cycle, and confirm who approves a release that fails.
Deadlines need an internal owner
The 26 April 2027 and 26 April 2028 dates apply by entity size, and no vendor can decide which applies to your organization. Name one accountable executive, a web accessibility lead and a budget line before the work starts. Keep a dated inventory of every site, document library and vendor-supplied page, and record a status for each so the plan can be reported to leadership and auditors.
Questions buyers ask before hiring help for ADA Title II
What drives the cost of an accessibility audit and remediation for a Drupal or WordPress site?
The main cost driver is the size and variety of the estate, not the platform license, because Drupal and WordPress core carry no license fee. Auditors and remediation engineers are paid for the number of distinct templates, components, content types, forms, interactive widgets and authenticated areas that must be tested against WCAG 2.1 Level AA. A site with one theme and a few page templates costs far less to assess than a multisite estate with many contributed modules and third-party embeds. Ask for a quote that lists sites, templates, languages, document types and whether PDFs and vendor-provided widgets are in scope. Also ask whether retesting after fixes is included, because that work recurs with every release.
How long does ADA Title II remediation take, and what sets the pace?
The pace is set by the compliance date your entity falls under and by how much of the estate is shared. The Department of Justice rule sets April 26, 2027 for entities serving 50,000 or more people and April 26, 2028 for smaller entities and special districts, so the first step is confirming which date applies to you. Remediation speed then depends on whether defects sit in a shared theme or component, which can be fixed once and propagated, or in individual pages and documents, which must be fixed one by one. Editor availability, content owner sign-off and the release calendar also control the schedule. Ask any partner for a written plan that sequences shared components before page-level fixes.
What does the agency need to provide for an accessibility engagement to succeed?
The agency must supply three things: people who own content, access that lets engineers change the theme, and testers who can judge the result. Content owners for each department decide which pages are retired, rewritten or kept, and they approve alt text and document fixes. Engineers need repository and staging access to the theme and contributed modules, plus a production-like environment for regression checks. Testers should include people who use screen readers, keyboard-only navigation and magnification, because automated scans miss many WCAG issues. Confirm these roles in the written scope before work starts so delays do not fall on the remediation budget.
Can our internal team handle ADA Title II accessibility work on its own?
Some teams can, particularly when they already have front-end engineers, a documented design system and staff trained in WCAG. Internal teams usually struggle with three areas: independent testing with assistive technology, consistent fixes across many sites, and the evidence trail an assessor will ask for. Ask whether your team can name an owner for the accessibility statement, run a repeatable audit, track defects to closure and retest after each Drupal or WordPress security update. A partner can cover part of this work, such as the audit, the shared theme fixes or the evidence pack, while your staff keep content ownership. Decide the split before scoping, not after.
How does the Drupal 10 or Drupal 11 release cadence change accessibility scope?
Each core or contributed update can alter markup, JavaScript or theme output, so a passing audit can drift without any change to your own content. Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026, according to the core release schedule. Security releases come on the third Wednesday of the month and bugfix releases on the first Wednesday, so accessibility regression checks belong in that rhythm. Ask a partner how it will rerun targeted checks after each security release and how it will plan any move from Drupal 10 before end of life. Those checks are recurring costs that belong in the scope.
What does a fixed-scope accessibility engagement from DeployOpen cover?
DeployOpen works from a written scope that names the sites, templates, components, document types and deliverables, and the timeline is agreed before work starts. Typical deliverables for this kind of work include an audit against WCAG 2.1 Level AA, a prioritized defect register, remediation of agreed defects in the platform and theme, retesting and an evidence pack for your records. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications, which independent auditors and certification bodies provide. Ongoing testing and upgrades can be added as a retainer. Ask for the exclusions in writing, including vendor-provided content and third-party embeds.
Do we pay for accessibility work once, or does it recur?
Both happen, and the split matters when you compare quotes. The first audit and the bulk of the remediation are one-time costs. Recurring costs include retesting after platform updates, fixes for new content and new third-party components, periodic re-audits and maintaining the accessibility statement and feedback route. WCAG 2.2 adds nine success criteria to WCAG 2.1, so an estate that must later meet newer criteria will need additional work, which is worth asking a partner to price as an option. Request a quote that separates one-time and recurring line items so that your budget owner can plan the second year as well as the first.
How public universities and local governments differ
Public universities and local governments are both covered by the ADA Title II rule, but they do not face the same deadline or the same web estate. Under 28 CFR 35.200, state and local government web content and mobile apps must meet WCAG 2.1 Level A and AA from April 26, 2027 for entities serving 50,000 or more people, and from April 26, 2028 for smaller entities and special districts. A public university serving a large population will usually fall in the earlier group, while a small township, a water district or another special district may have until 2028. Confirm which group your entity falls in with counsel and your state or local legal office, and document the population basis you used, because auditors and complainants will ask for it.
Universities differ mainly in scale. A campus may run hundreds of department sites, each with its own editors, templates and third-party embeds such as event calendars, admissions tools and video players. Decide early whether accessibility ownership sits with a central digital team that owns the shared theme, components and testing pipeline, or with department editors who publish independently. Whichever model you choose, the central team needs an inventory of every public site and every vendor-provided component, because the rule reaches content supplied through contracts or licenses. Local governments more often run a smaller set of sites, but they may depend heavily on a single vendor for permits, payments or meeting portals, so those contracts need accessibility terms written in.
Student records and identity are separate obligations that this rule does not resolve. FERPA (34 CFR Part 99) governs education records, and a university portal that handles grades, financial aid or advising data needs its own access controls, disclosure logs and vendor terms. Campus single sign-on and login flows also raise questions under the accessibility standard, such as whether authentication is usable without a cognitive test. Treat those as separate workstreams. The open source CMS for higher education and open source CMS for the public sector pages cover department sprawl, campus SSO and public-sector multi-agency governance in detail.
How DeployOpen scopes and delivers ADA Title II work
DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted Drupal or WordPress estates inside the client's own infrastructure. For ADA Title II work, we start from a written scope that names the sites, templates, content types and third-party components that must meet WCAG 2.1 Level AA before the compliance date that applies to your entity.
How we scope
- Inventory every site, template, content type and vendor-supplied component that falls under the rule, including contracted and licensed content.
- Confirm which compliance date applies to your entity, April 26, 2027 or April 26, 2028, with your counsel or the rule text at 28 CFR 35.200.
- Agree the written scope, deliverables and timeline before work starts, with ongoing support available as a separate retainer.
How we build
- Test templates and components against WCAG 2.1 AA with automated tools and manual review by people who use assistive technology.
- Remediate theme, module and editor-facing issues in version-controlled code, so fixes survive future Drupal or WordPress updates.
- Add accessibility checks to the release pipeline so new content and plugin changes are tested before they reach production.
How we hand over
- Deliver audit results, remediation records and an accessibility conformance report that your internal team and independent auditors can review.
- Document editor guidance for alt text, heading structure, forms and document accessibility so content teams keep conformance after launch.
- Hand over runbooks for hosting, backups, update procedures and the evidence log you need to keep for each release.
How we support
- Offer ongoing support as a retainer covering security updates, accessibility regression testing and new feature checks.
- Re-test after Drupal or WordPress security releases and after new third-party components are added to the estate.
- Confirm with us during scoping which tests, reports and response times are included in any retainer, since these are set in writing.
