Accessibility Climbs State CIO Agenda as Operational Gaps Persist

Digital accessibility has risen from tenth to sixth place on NASCIO's State CIO priority list for 2026. Yet state governments still face substantial accessibility work. A new survey of state accessibility officers finds that policies are advancing faster than efforts to make documents, websites and digital services accessible.

The divide is clearest between policy and day-to-day remediation. Among surveyed accessibility officers, 75% identified document remediation as an area of non-compliance. Another 70% identified high-traffic systems and digital services, and 50% cited remediation workflows. By contrast, 71% reported full or near-full compliance on statewide accessibility policy, while 66% reported the same for procurement requirements.

Resources are a major constraint. NASCIO's inaugural State Digital Accessibility Officer Survey received 36 responses from 40 invited state accessibility officers. Among respondents, 67% said their states had no designated accessibility budget. Another 51% reported limited remediation capacity, and 69% said they lacked the resources to remediate all websites and applications statewide.

The federal timeline has meanwhile moved by a year. The US Department of Justice extended the Title II web and mobile accessibility compliance date for public entities with populations of 50,000 or more to 26 April 2027. Entities below that threshold and special district governments have until 26 April 2028, and covered web content and mobile applications must meet WCAG 2.1 Level AA.

The extra time does not turn compliance into a one-time deadline exercise. DOJ guidance says public entities must continue complying after their applicable date. NASCIO also found that accessibility officers largely intend to use the extension to strengthen workflows and move accessibility earlier into software development, modernisation, procurement, staff onboarding and training.

The DropTimes previously examined how wider state IT tensions play out when governments centralise common standards and infrastructure while agencies retain responsibility for their own content. The accessibility findings narrow that governance question to everyday production. A shared platform can maintain common components and technical guardrails, but a new page, image, heading, link or document can still introduce a barrier after the platform itself has been reviewed.

The State of Iowa provides a concrete Drupal example of moving some of those checks closer to content creation. Its Digital Experience platform moved 51 agencies onto a standardised platform during its first phase, with accessibility, plain language, a common design system and standard content types among its stated priorities. Project material from Lullabot identifies Drupal development and site building as part of the implementation.

Iowa's publishing guidance places accessibility checks directly inside the editorial workflow. The state's Editoria11y Accessibility Checker documentation describes a Drupal-based tool that flags issues such as missing alternative text, incorrect heading structure, poorly formatted lists and unclear links. Editors can encounter and correct those problems while creating or reviewing content rather than depending only on a later audit.

The document problem receives a different treatment. Iowa's guidance on HTML over PDF recommends replacing short PDFs with web pages where practical, considering dedicated content types for recurring material such as agendas and minutes, and removing obsolete documents. That does not automatically remediate PDFs that must remain available, but it can reduce the number of new files entering an accessibility backlog.

Drupal itself draws a similar line between platform support and finished-site conformance. Drupal core targets WCAG 2.2 Level AA for public-facing and administrative interfaces and uses the Authoring Tool Accessibility Guidelines to guide the authoring experience. Drupal's documentation also states that a finished site is not automatically accessible because configuration, contributed projects, custom code, themes, content and ongoing testing can change the result.

The same shift-left approach appeared at DrupalCon Chicago 2026. Kat Shaw, M. Nikki Flores and Javier Reartes of Lullabot drew on work involving Iowa, Maryland and Georgia, alongside higher-education projects including UMass Amherst and NYU. The session covered accessibility across planning, design, development, quality assurance and content entry, including design-system reviews, automated and manual testing, alternative-text training and heading structure.

That lifecycle model closely matches the direction described by NASCIO's accessibility officers. States face both a backlog problem, involving existing documents and systems, and a production problem, involving new content that can recreate barriers after remediation. Shared Drupal infrastructure can standardise components and expose some problems during authoring, but maintaining accessibility still depends on the processes and people involved each time content changes.