Making Drupal government sites accessible (WCAG 2.1 AA)

Most government websites were accessible on the day they launched, or close to it. Two years later, after thousands of edits by dozens of departments, many are not. Accessibility is not a one-time project that a site passes. It is a property that erodes a little with every new PDF, every image without alt text, every table built for layout. Keeping a Drupal site accessible is about building the platform so that the accessible path is the default one for every editor.

What the requirement is

ADA Title II requires state and local governments to make their web content accessible, and the technical standard is WCAG 2.1 Level AA. Compliance deadlines for larger entities are already in effect, with smaller entities following. Section 508 applies the same WCAG standard to federal agencies. WCAG 2.1 AA is organized around four principles: content must be perceivable, operable, understandable, and robust. In practice that means things like text alternatives for images, full keyboard access, sufficient color contrast, clear headings and labels, captions for video, and markup that assistive technology can interpret.

Where failures actually come from

Fixing the theme is the highest-leverage work, because one fix repairs every page. Content is where most ongoing issues appear, because it changes daily.

What Drupal gives you

Drupal core takes accessibility seriously: its default admin and front-end themes were built to meet WCAG AA, and core includes accessible form handling and ARIA support. Contributed modules add editor-facing help. Editoria11y, for example, highlights accessibility problems to editors as they work, in plain language. The platform is a good foundation. What it cannot do on its own is stop an editor from uploading an untagged PDF.

Guardrails for editors

• Make alt text required on image fields, with guidance on writing it well, and a clear option for decorative images.
• Restrict text-editor heading options so editors cannot skip levels.
• Remove toolbar options that invite layout tables or colored text.
• Show inline accessibility feedback in the editor before content is published.
• Offer a short training session and a one-page checklist for every new editor.
• Prefer HTML pages over PDFs for anything people need to read or act on.

Testing: automated and manual

Automated scanners are essential and fast, and they catch a meaningful share of problems: missing alt attributes, contrast failures, empty links, missing labels. They cannot judge whether alt text makes sense, whether keyboard order is logical, or whether a screen reader user can complete a form. That takes manual testing with keyboard only and with screen readers such as NVDA, JAWS, and VoiceOver. A good program runs automated scans continuously and manual tests on key templates and journeys regularly, and after significant changes.

A quick self-check you can do today

1. Put your mouse away and use Tab to move through your homepage. Can you reach and use everything, and can you always see where you are?
2. Zoom the browser to 200 percent. Does content still fit and work?
3. Open your five most-visited PDFs. Can you select the text? Do they have a title and headings?
4. Pick a form, such as a service request, and complete it using only the keyboard.

Keep a simple accessibility statement on the site, with a way for people to report barriers. Reports from real users are some of the most valuable testing you will get, and a quick, visible response builds trust.

How eWay approaches accessibility on Drupal

eWay treats accessibility as a continuous operational discipline, not a launch audit. Development follows accessibility-first practices: semantic HTML, proper heading structure, ARIA where needed, keyboard navigation, and accessible contrast. Automated accessibility checks run on changed templates before release, and manual testing with screen readers covers key templates and journeys. After launch, eWay monitors for regressions, configures editor guardrails, and provides training. For organizations that need audits, remediation, and conformance documentation, eWay also offers dedicated accessibility compliance services.

What to include in a support ticket

• The severity you would assign, P1 to P4 (see severity levels and response times)
• The URL, the barrier found, and how it was found (a scanner report, a user complaint, manual testing)
• Whether it appears on one page or across a template

eWay customers can open a ticket in the support portal or email support@ewaycorp.com at any time. See how to request support for all the options. Related reading: running multi-site Drupal for many departments and structuring Drupal environments. More on our Drupal page.