How Varbase Enhances Accessibility in Drupal

Why Does Website Accessibility Matter?

Web accessibility means people with disabilities can perceive, navigate, and use a website as fully as anyone else. It matters because about one in six people lives with a significant disability, according to the World Health Organization: visual, hearing, physical, speech, cognitive, or neurological. Many of them read your site with a screen reader, a keyboard, a zoomed-in screen, or their voice.

Three sets of rules cover most organizations:

• WCAG, the W3C's Web Content Accessibility Guidelines, is built on four principles: content must be perceivable, operable, understandable, and robust. Level AA is the target most laws point to, including the EU Web Accessibility Directive and the UK public sector regulations.
• Section 508 requires US federal agencies to make their digital services accessible.
• The ADA, the Americans with Disabilities Act, has been applied by courts to websites as well as buildings.

Compliance is the floor, not the reason. An accessible site also:

• Reaches more people, including millions who are shut out of sites built without them in mind.
• Is easier to find. Clear headings, alt text, and plain navigation help search engines, and the AI assistants that now read your pages too.
• Works better for everyone. Captions help on a noisy train; good contrast helps on a phone in the sun.
• Lowers legal risk from complaints and lawsuits over services people cannot use.

Accessibility is not a feature you ship once. It is a check you run every time code or content changes.

The rest of this post follows one change through those four checks.

1. In the Code: How Are Varbase Themes Built to WCAG 2.2 AA?

Varbase fixes accessibility where most problems start: in the theme. Most accessibility problems are baked in before an editor types a word: a template that skips a heading level, a gray caption that looked elegant in the design, a slider arrow too small to tap.

Our four site templates on drupal.org's site template listing, Varbase Starter, Educare, Horizon Aid, and The Rightup, are where this work shows most clearly. In September 2026, before their stable 1.0 releases, we put each one through WCAG 2.2 AA on a fresh install and fixed what we found in the themes and recipes themselves, not in the test exemptions. The listing has a filter for templates tested to WCAG 2.2 AA; Educare and Horizon Aid carry that wording on their cards, and every one of the four shipped the same fixes.

What the September 2026 WCAG 2.2 AA sweep found in each Varbase site template

Three patterns came up in every template, and they are worth checking on any Drupal site:

• Headings chosen for their size. A component that always renders h3 is wrong on most pages. The fix was to make the heading level a property of the component, separate from its visual size, so the page outline stays in order.
• Targets too small to tap. WCAG 2.2 added a 24px minimum for touch targets (success criterion 2.5.8). Slider dots, ticker links, and share icons all needed it.
• Brand colors that fail contrast. Mostly on light surfaces: gray captions, gold headings, blue outline buttons on beige. The fix is scoped to where the color fails, so the brand stays intact everywhere else.

One lesson is worth repeating to every design team: matching the design can fail WCAG. A caption shipped in the designer's gray measured 3.75:1 against its background, below the 4.5:1 minimum. Our test gate refused it three times. The fix, a darker gray at 6.82:1, still reads as "lighter text", and now everyone can read it.

What Does a Fresh Varbase 11 Site Get Right on Day One?

We checked the front page and a blog post of a fresh install, with automated tests and then by hand with a keyboard:

• Page basics: a declared language, a unique page title, and zoom allowed on phones.
• Keyboard: "Skip to main content" is the first stop on Tab, and the focused link is always visibly marked.
• Structure: one H1 per page, headings in order, and main and navigation landmarks for screen readers.
• Images: every image carries alt text, and the media library will not save one without it.
• Forms and controls: every field has a label, and every button and link has a name a screen reader can read out.

A clean theme is the starting line, not the finish. The next question is how it stays clean.

Planning a redesign? We can audit your current site against WCAG 2.2 AA before a single template is built. Talk to our team.

2. In Testing: How Does Varbase Test Accessibility on Every Release?

Varbase gates every release on an automated accessibility check: if the check fails, the release does not ship. A manual audit finds problems once. An automated test finds them every time someone changes something.

Our end-to-end test toolkit, varbase-e2e, gives every Varbase project two layers of accessibility checks, written as plain-English steps:

1. Fast structural probes: page language, one h1, a valid heading order, a skip link, labeled fields, named buttons and links, valid ARIA (the attributes that describe custom controls to screen readers). Each probe maps to a WCAG success criterion.
2. A full axe audit. The suite runs Deque's axe tools inside the browser test: the open-source axe-core engine, version 4.12 today, through @axe-core/playwright. That is around 100 rules across WCAG 2.0, 2.1, and 2.2 at level AA by default. It is the same engine behind the free axe DevTools browser extension, so a developer and the test suite see the same result.

A test reads like a sentence:

@a11y
Scenario: A blog post passes the full accessibility check
  Given I am on "/blog/community-behind-varbase-support-and-collaboration"
  Then the page should pass the full accessibility check
.    And the page should have a skip link

That one step runs axe plus every structural probe and reports every failure at once, not just the first. Since varbase-e2e 2.0.7, the severity gate is cumulative: a "no serious violations" gate also fails on a critical one, so nothing slips through on a technicality. If a step fails, the release does not ship. That is how the gray caption got caught.

What the gate found while we wrote this post. We pointed it at the fresh site behind these screenshots. The front page and a blog post passed the full check. The blog listing did not:

3 scenarios (1 failed, 2 passed)
[serious] color-contrast: Elements must meet minimum color contrast ratio thresholds (3 nodes)

Two causes: a pale "Reset" filter button at 2.24:1, and blue outline buttons on a beige card at 3.99:1. Both are short of the 4.5:1 minimum, and neither looks like a problem to the eye. That is exactly why the check runs on every release rather than once a year. 

3. In Editing: How Does Editoria11y Check Content as Editors Write?

Editoria11y, the accessibility checker built into Varbase, flags content problems while editors write, before a page goes live. Back to our editor and her Tuesday press release. The template is clean, and the tests are green, and the page she is about to publish still has a skipped heading, a "click here" link, and an image with no description.

Varbase ships the Editoria11y accessibility checker for exactly this moment. It has been part of Varbase Core since Varbase 10.1 (October 2023) and is enabled out of the box in Varbase 11. It also arrives in Drupal CMS through the Drupal CMS Accessibility Tools recipe.

We wrote a demo post with those mistakes on purpose. Editoria11y marks each one on the page and explains it in plain words:

It also works inside the editor, while you type, before anything is saved:

And site managers see the whole site in one report: which problems are most common, and which pages need attention first.

Editoria11y is made for editors, not auditors. It speaks plainly, lets an editor mark a false alarm as OK, and stays out of the way when the content is clean. We also fixed its panel colliding with the Gleap feedback button, in both left-to-right and right-to-left layouts, because many of our clients publish in Arabic as well as English.

Want this for your editors? Every Varbase 11 site has it on day one. Start with Varbase or ask us about your current Drupal site.

4. In Review: How Can AI Help With Accessibility Without Replacing People?

In Varbase, AI drafts accessibility fixes such as alt text and content reviews, and a person approves each one. The editor now has a list of things to fix, and a deadline. This is where AI earns its place: not by deciding, but by drafting.

For editors, inside Varbase:

• Varbase AI Image Alt drafts alternative text for an image from the content around it. The editor reviews and edits it.
• Varbase AI Content Review adds a Review tab to content. One click returns a score and a verdict per criterion before publishing; readability and clear structure can be among them.
• AI Editoria11y, a community module we are following, adds a "Fix with AI" button to Editoria11y tips in CKEditor. The AI suggests; the editor decides.

For developers, in code review:

• Our engineers build with AI coding agents, and the varbase-e2e accessibility suite is part of what those agents run before a change goes to a human reviewer.
• Accessibility-aware AI review is maturing fast. Deque's Axe MCP Server lets a coding agent test, fix, and re-test a component with axe. GitHub has written about building its own accessibility review agent. Open-source options such as ax-review run WCAG 2.2 checks on pull requests.

One caution: automated tools, AI included, catch only part of what WCAG asks for. Keyboard flow, a sensible reading order, and whether the alt text actually describes the image still need a person. That is why every step in our process ends with human review.

Where Can Your Team Keep Learning About Accessibility?

Much of what shaped this approach came from the accessibility community. Two free places we keep going back to:

A11yTalks, a monthly online meetup on digital accessibility running since 2018. Its topic index is a good map of the whole field, and a reminder that accessibility is much wider than code:

Where to start in the A11yTalks topic index, by role

axe-con, Deque's free accessibility conference, from the team behind the axe tools our tests run on. The next edition is on 23 and 24 February 2027, live and online, in four tracks: development and testing, design, organizational success, and a wildcard track. Past talks are free to watch after registering. Sessions such as Accessible by Default: Scaling Design Systems with AI-Assisted Development and Shift Left Without Shifting Gears argue for the same thing this post does: accessibility built into the tools and the workflow, not added after launch.

What Does Accessible by Default Mean in Practice?

Our editor's page went out with its headings in order, its links named and its image described, and nobody had to remember to check. That is what "accessible by default" means in practice: four checks, every time.

The four places Varbase checks accessibility

None of these replaces the others, and none replaces testing with real people. Together they make an accessible site the default rather than a project.

Is your Drupal site accessible today?

 Book an accessibility review with Vardot