Accessible WordPress sites: what your page builder should do for you
Accessibility isn’t a plugin you install at the end. A lot of it comes down to the HTML your builder writes. Here is what to expect from your tools, and what is still up to you.
One in six people worldwide lives with a significant disability, according to the World Health Organization. Many more have temporary or situational limits: a broken wrist, bright sunlight on a phone screen, a slow connection. An accessible site works for all of them.
It also matters legally. Accessibility rules apply to more and more websites, and the European Accessibility Act now covers many online shops and services selling in the EU. The common technical reference is WCAG 2.2, level AA.
What your page builder should handle
A lot of accessibility depends on markup you never see. A good builder gets these right by default:
- Semantic HTML. Headings are real
h1–h6elements, lists are lists, buttons are buttons and links are links. - Keyboard support. Tabs, accordions, menus, sliders and popups work with Tab, Enter, Space, arrow keys and Escape.
- Visible focus. Keyboard users can always see where they are.
- Correct ARIA. Tabs announce as tabs, accordions announce whether they’re open, and dialogs trap focus while open.
- Reduced motion. Animations calm down for visitors who ask their system for less motion.
- Image alt text. The builder uses the alt text from your media library and lets you override it.
- Form labels and errors. Every field has a label, and errors are announced, not just shown in red.
In Akram, the editor, the dashboard and every template are tested against WCAG 2.2 AA, and the interactive widgets follow the patterns above. You can also build pages using only a keyboard or a screen reader, which matters if your team includes people who rely on them.
What you still need to do
No tool can make content accessible on its own. These are your job:
Write a clear heading structure
One h1 per page, then h2 for main sections and h3 for subsections. Don’t pick heading levels for their size. Change the size in the style settings instead.
Write useful alt text
Describe what the image shows in context. A photo of your team on the About page might be “The five-person Akram team at the office”. Purely decorative images should have empty alt text so screen readers skip them.
Check color contrast
Body text needs a contrast ratio of at least 4.5:1 against its background, and large text at least 3:1. Light grey text on white is the most common failure. Check your design system colors once and every page benefits.
Write descriptive links and buttons
“Read more” repeated ten times means nothing to someone browsing a list of links. Use “Read the migration guide” instead.
Caption your videos
Add captions to videos with speech, and a transcript for audio.
A five-minute test you can do today
- Unplug your mouse. Press Tab through your home page. Can you reach and use every link, button, menu and form? Can you always see where you are?
- Zoom to 200%. Does anything overlap or disappear?
- Turn on reduced motion in your system settings and reload. Do large animations calm down?
- Run an automated check with a browser extension like axe DevTools. Fix anything marked serious.
- Try a screen reader for one page: VoiceOver on Mac and iPhone, or NVDA on Windows (free).
Automated tools only catch part of the problems. The manual checks above find most of the rest that matter day to day.
The short version
Choose tools that write accessible HTML by default, then focus your own effort on content: headings, alt text, contrast, link text and captions. That combination gets most WordPress sites to a level that works for far more people, and keeps you on the right side of accessibility law.
Start with the free version next to your current builder and compare. Pro from $49 a year.