WordPress 7.1 Ships 88 Accessibility Fixes Before GA

🇹🇷 Türkçe: Bu yazının Türkçesini oku →

Accessibility is the part of the WordPress release notes I read first and quote last. First, because it tells me what the project actually spent its Saturdays on. Last, because clients rarely ask, and a good agency ships the fixes without making a speech about them.

The other reason I read it first is more old-fashioned. I came up through print in the early nineties, and the whole point of a paragraph style in QuarkXPress was that one decision travelled everywhere it was applied. That is the same instinct behind accessibility work in a CMS: fix the label once, and it reads correctly in every screen reader, every High Contrast Mode, every keyboard tab-order, for every editor who logs in. Small file, wide blast radius.

WordPress 7.1 ships August 19. The accessibility dev note landed yesterday afternoon. Here is what is actually in it, and what I would do about it before GA week.

What is actually new

Joe Dolson’s Accessibility Improvements in WordPress 7.1 dev note, published August 13 and reviewed by @annezazu, @amykamala and @sabernhardt, counts 88 combined fixes: 45 in Core, 43 in the Editor. It is one of the largest single accessibility ledgers a WordPress release has published, and it lands as part of the wider 7.1 Field Guide that Milana Cap collated on August 5.

The Core work concentrates on the surfaces editors actually touch. Post title cells in list tables are finally identified as row headers instead of the selection checkbox next to them (#32892, #65743) — a small semantic change that untangles a decade of screen-reader confusion on Posts and Products lists. Focus indicators are standardised to a minimum of 2 CSS pixels across the admin (#65645). Active states for buttons and tabs are now correctly identified in Windows High Contrast Mode (#65153, #65419). A standardised mechanism for accessible tooltips (#51006) lands alongside the wp_get_tooltip() / wp_get_toggletip() APIs from earlier in the month, and is already applied to metabox order buttons (#50921) and the “Remember Me” login option (#55343).

Media gets its own quiet clean-up: caption field labels refined (#43178), duplicate figcaption IDs fixed when the same image is reused (#65315), unlabelled date filters resolved in the Media grid (#65711), the arrow-key conflict with screen readers in theme and media modals corrected (#63760). List Tables now expose structural indicators for subpages so blind users can navigate hierarchies (#64932). Password-protected content on the front end gets both styling and usability updates (#64569).

The Editor side is where the block work lives. Contrast checking is extended to the viewport and to pseudo-states (#80223) — meaning the warning now catches problems that only appear on hover, focus, or a specific breakpoint, which is how most real contrast bugs actually reach production. The Image block gains a toggle for marking media as decorative (#78064), so screen readers stop announcing purely visual images as if they carried meaning. Localised aria-live regions are replaced with speak() for better auditory feedback (#79600). The Playlist (#80203) and Tabs (#80163) blocks landed with accessibility testing done rather than promised.

Then, the honest paragraph. The Media Library’s default behaviour changed from a “Load more” button to infinite scroll, and the dev note names it as “a known inaccessible pattern.” Four mitigations ship in the box: a per-user opt-out in profile settings, the media_library_infinite_scrolling filter for developers to disable it globally, the WP Accessibility plugin’s inverting logic, and continuing work on a modal-level toggle (#65775). That is the shape of a project willing to document its own regressions instead of hoping nobody notices.

Context around all of this: RC3 shipped August 12 with 90+ fixes since RC1, and the Polyglots team confirmed on August 13 that 7.1 is ready to be translated on translate.wordpress.org. Hard string freeze is in. The accessibility work in this dev note is what actually lands on production the morning of the 19th.

Why it matters for WordPress and WooCommerce people

Accessibility work rarely announces itself in your inbox. It shows up as fewer support tickets that begin with “our editor can’t find where to publish”, fewer legal questions from clients in regulated industries, and fewer awkward conversations about EN 301 549, WCAG 2.2, or the European Accessibility Act (which is now in force and applies to a lot more e-commerce than most agencies budgeted for).

The two changes that hit WooCommerce estates hardest are the row-header fix on list tables and the standardised focus indicators. Both apply directly to the Orders screen, the Products screen, the Customers screen — every list your shop managers spend their day inside. If your client roster includes a store where a shop manager uses a screen reader, or a warehouse operator uses keyboard-only navigation because the mouse is on a shared workstation, this release quietly makes their job easier without you needing to ship a plugin.

The contrast checker extending to viewport and pseudo-states matters for anyone shipping block themes with hover states on Buttons or Navigation links. Between this and the pseudo and custom style states dev note from earlier this month, the editor now warns you about the contrast problem on the same screen where you designed it. That is a whole category of QA ticket that stops existing.

What I would do about it

Three things this week, one thing not.

First, if you already have 7.1 RC3 on a staging clone (and you should — RC3 is where the accessibility work is fully in), spend twenty minutes walking the admin with the keyboard only. Tab through Posts, Products, Orders. Confirm the focus rings are visible on the sidebar in your admin colour scheme. Toggle Windows High Contrast Mode if you have a Windows machine handy and check that active buttons still read as active. This is the shortest possible smoke test and it catches ninety percent of the regressions that would otherwise reach a client.

Second, decide the media library policy now, not on the 19th. On editorial sites with heavy media use I would ship the media_library_infinite_scrolling filter set to false in a mu-plugin — one line, versioned with the site, no user settings to explain. On smaller sites with light media use the per-user opt-out is fine. Either way, decide before someone opens a ticket saying the media library “keeps loading forever.”

Third, for any client in a regulated sector — public sector, banking, education, healthcare, larger retail with an EU footprint — send a short note this week saying WordPress 7.1 ships significant accessibility improvements on August 19 and you have staged and tested them. That note is worth more than the fixes themselves, because it puts the governance layer in front of the client before they have to ask.

The one thing I would not do: install a third-party “accessibility overlay” plugin that promises to fix your site with a single script tag. They do not fix accessibility. They occasionally make it worse. The real work is in this dev note and in the fifteen years of similar dev notes behind it, and no widget bolted on top substitutes for the semantic fixes shipping in Core.

Eighty-eight fixes is not a headline. It is a Saturday-by-Saturday inventory of small decisions travelling wide. That is exactly the shape of WordPress work I trust most, and exactly why we still build the enterprise stack on it.