Best practices and updates from WordPress Accessibility Day 2026

We spent October 7-8 at WordPress Accessibility Day 2026 free online event and a few sessions gave us things WordPress agencies, developers and site owners can use straight away. Here’s what we took from it.

One idea kept coming back across the sessions on development, design, content and user experience: accessibility isn’t something you add to a website once the design and development are finished. It’s part of how a website is planned, built, updated and maintained for as long as it exists.

Two sessions stood out for anyone who builds or maintains WordPress sites: Makarand Mane’s I Built WordPress Sites for Years Without Thinking About Accessibility – Here’s What I Wish I Knew and Pranali Bane and Raj Rajeshirke’s Mind the Focus: Keeping Users on Track. Different subjects, same underlying question. Can the people visiting our sites actually use them?

A site can look finished and still lock people out

Makarand talked about years of building WordPress sites that looked good and worked as expected, and about realizing later that neither of those meant the sites were accessible. The problems he described are common ones:

• Images with no meaningful alt text
• Headings chosen for how they look, not for the structure of the content
• Forms without proper labels or clear error messages
• Navigation you can’t operate with a keyboard
• Interactive elements that are easy to spot visually but hard to use with assistive technology

Only, none of these require a redesign. Headings in the right order let screen reader users move through a page. Proper labels make a form understandable. Going through a page using just the keyboard shows problems you won’t notice with a mouse.

His advice: think about these while you’re building the page, not when the site is about to launch.

Keyboard users need to know where they are

Most of us use a mouse or a touchscreen. Plenty of people don’t. They rely on keyboards, switches, joysticks and other assistive technologies, and in Mind the Focus, Pranali and Raj looked at how interface design and focus management affect them.

Keyboard focus is the element currently receiving keyboard input. Press Tab and focus should move through links, buttons and fields in a logical order, with something visible showing where you are. It breaks when focus disappears, jumps somewhere unexpected, or gets stuck.

Popups are a good example. When one opens, focus should move into it. While it’s open, Tab shouldn’t wander into the page behind it. When it closes, focus should usually go back to whatever opened it. Menus, forms and buttons have their own versions of the same rules.

The easiest way to find out whether your site gets this right is to put the mouse away and try a few everyday tasks. Open the menu. Open and close a dialog. Fill in and submit a form. Notice whether you can always tell which element has focus. If any of that is awkward, you’ve found something worth looking into.

Content teams make accessibility decisions every time they publish

Correctly built components don’t help much if the content on top of them is hard to follow. Readability, structure and the different ways people take in information came up in several discussions.

For content creators and site owners, that comes down to everyday publishing habits:

• Write headings that tell readers what the section is about.
• Make link text say where the link goes instead of “click here” (guilty of that).
• Don’t rely on color alone to carry important information.
• Keep text readable, check color contrast, and be careful with moving or auto-playing content that interrupts reading or navigation.
• Use alt text to explain what an image is there for, not to describe every detail. Decorative images generally don’t need descriptive alt text.

Small as they seem, these choices decide whether someone finds what they came for and gets it done.

Who’s responsible once the site is live?

A website that meets accessibility requirements today may develop new issues tomorrow. New content gets published. Plugins are updated. Layouts change. Features are introduced. Different people become responsible for maintaining the website.

Sanna Kramsi took this on directly in Who Owns Accessibility After a WordPress Site Launches? Her central point was that accessibility slips when responsibilities are unclear. A developer assumes the content team has it covered; the content team assumes the technical setup handles it.

The practical fix to this is to make it part of regular maintenance:

• Check heading structure, links, images and forms when publishing new pages.
• Test keyboard navigation after adding or changing interactive elements.
• Review accessibility when making significant design or plugin changes.
• Agree on who identifies, reports and fixes issues.

Websites are never really finished and the same goes for accessibility work too.

Where WPBakery fits in

As a page builder for WordPress, WPBakery is part of the everyday workflow people use to create and maintain websites and accessibility is an important consideration in how we develop and improve our product.

We’re aware of accessibility requirements and take them into account as part of ongoing development. With each release, we work on different areas of the plugin, including interface behavior and focus management. At the same time, accessibility isn’t something a page builder can guarantee on its own. The theme, other plugins, custom code, the content and the design choices all shape what a visitor ends up with. Getting it right means paying attention to how those pieces work together.

A few things you can check on your WordPress website today

You don’t need a full audit to start identifying areas for improvement. Start with the following:

1. Navigate without a mouse. Use Tab, Shift+Tab, Enter and Escape to see whether you can reach and operate every interactive element.
2. Review the heading structure. Headings should follow a meaningful hierarchy and describe what comes after them.
3. Check forms. Fields need clear labels, required information should be obvious, and errors should be easy to spot and fix.
4. Review images and links. Informative images need appropriate alt text, and link text should make sense out of context.
5. Test interactive elements. Open menus, dialogs and other components and watch whether focus behaves predictably.

These checks don’t replace comprehensive accessibility testing, including testing with assistive technologies and with people with disabilities but they do show you where to look first.

Kudos to Amber Hinds and the rest of the team for organizing yet another impactful event we were happy to support by sponsoring and attending!

Further reading and sessions:

• I Built WordPress Sites for Years Without Thinking About Accessibility – Here’s What I Wish I Knew – Makarand Mane
• Mind the Focus: Keeping Users on Track – Pranali Bane and Raj Rajeshirke
• Who Owns Accessibility After a WordPress Site Launches? – Sanna Kramsi
• WordPress Accessibility Day 2026