Accessibility releases usually get read as end-user news. If you build plugins or maintain client sites, the habit is to skim the changelog and move on. That doesn’t work for the WordPress 7.0 accessibility notes. Joe Dolson’s post on Make WordPress Core lists 24 fixes in core and 16 in Gutenberg, and a fair number of them land on things developers already build against: uploads, template functions, admin markup.
After going through the ticket list, I think one behavior change is worth testing before clients run into it. The rest of the list makes a decent free audit checklist for your own screens, since core spent this cycle fixing the same bugs in its own admin that most plugins still ship.
Where WordPress 7.0 accessibility work meets your code
A few of these fixes change output or defaults instead of polishing what was already there. These are the ones I’d flag.
- Alt text embedded in image metadata (IPTC) now imports on upload. Step 1 covers it, because it’s the change most likely to surprise automated tests.
- Title attributes are gone from the author link functions (#62835). If an old theme used those titles as a styling or JavaScript hook, it stopped working quietly. Good riddance, since title attributes make weak tooltips and add noise for screen readers.
- The password reset screen pre-populates the username (#60726) to satisfy WCAG 2.2’s redundant entry rule, which asks that information entered once in a process isn’t demanded again. Plugins rendering their own login or reset flows should retest. Login screens are where accessibility work usually stalls, so core fixing its own flow gives plugins something to compare against.
- The block template skip link now goes through the HTML API (#64361), and Twenty Ten lost an auto-focus script on its 404 template. Small, but the rendered output differs.
Everything below is the walkthrough I’d run on a client site once the upgrade lands.
Step 1: test the alt text import before your clients upload
This is the biggest single change. WordPress 7.0 reads the IPTC Alt Text (Accessibility) property embedded in an image file and uses it as the attachment’s alt text (per IPTC’s own announcement, ticket #55535). Photographers and stock pipelines can now ship descriptions inside the file and have them survive the trip into WordPress.
Test it properly: write alt text into a test image with ExifTool or your DAM, upload it, and check the Alternative Text field on the attachment. The value lands in the _wp_attachment_image_alt post meta, the same place manual alt text goes, so wp_get_attachment_image(), the editor, and templates pick it up with no extra code.
The reading happens in wp_read_image_metadata(), and the wp_read_image_metadata filter still runs, so you can still customize the behavior. There are two caveats. It only applies to new uploads; nothing in the release notes backfills an existing library, so thousands of old images gain nothing. And if your integration tests assert an empty alt field on a fresh upload, they will now fail. That failure is correct, but someone will still get paged for it.
On store sites this matters most where photos arrive from a photographer or a supplier feed. Embedding alt text at export is now worth setting up as part of the workflow, because the platform finally honors it.
Step 2: run core’s ticket list against your own admin UI
The admin section of the source post reads like a list of the bugs that keep turning up in plugin settings screens. Core just fixed this set in its own UI: a button rendered as a link with missing ARIA attributes (#63980), title attributes doing tooltip duty, screen-reader-only text that breaks on long words because word-break was unset (#64375), controls that act clickable but keep the text cursor (#64382), and list tables announcing Edit twice per row (#33002).
The first one is worth showing in code, because it’s the most common and the cheapest to fix.
<!-- looks like a button, isn't one -->
<a href="#" class="button" onclick="bbioon_set_featured()">Set featured image</a>
<!-- name, role, keyboard behavior for free -->
<button type="button" class="button" onclick="bbioon_set_featured()">Set featured image</button>The link version fails voice control, focus styling and semantics. Saying “click set featured image” finds nothing meaningful to activate. Core’s own media library only became usable with speech recognition software in this release, on a ticket open since 2013. If a gap like that survived a decade inside core, I’d assume the same gap lives in your plugin’s modal, because almost nobody tests that path.
The audit itself is boring work. Unplug the mouse for ten minutes per screen, tab through, activate everything with Enter and Space, and do one voice-control pass on whatever screen handles files. That covers most of what core just fixed.
I do this regularly for client plugins and admin screens: a keyboard and screen-reader pass, then a short prioritized fix list. If you’d rather hand that off than learn NVDA on a deadline, it’s a reasonable thing to outsource.
Step 3: re-test the editor surfaces clients actually use
Gutenberg’s count looks small at 16, but the source post points out that the new interfaces (the gallery lightbox, the visual revisions inspector, the Connectors screen) shipped after accessibility review, under the stated commitment that new and updated code meets WCAG 2.2 at level AA. That continues the shift that started when WordPress 6.9 made accessibility part of the platform rather than a later patch job.
There are two checks I’d run on client sites. First, the gallery lightbox: if the site loads a lightbox plugin or custom script for photo or product galleries, look for double overlays, two Escape handlers and duplicated markup. Second, walk a gallery with the keyboard only. Arrows should move between images, Escape should close it, and focus should return to the image you opened from. DataViews grids gained keyboard navigation, and the accordion and gallery blocks gained list view support, so the editor’s list view is a decent quick test for whether a custom block exposes usable structure.
One more for anyone building editor UI: RangeControl now supports forced-colors mode. If you use the core components, you get that for free. If you rebuilt those controls yourself, you’ll need to add it.
What I’d check today
Upgrading doesn’t make a site compliant, and the release notes never claim it does. The number I’d measure today is how many images have no alt text at all, since that’s the gap the new import is meant to stop growing.
wp db query "SELECT COUNT(p.ID) AS images_missing_alt FROM wp_posts p WHERE p.post_type = 'attachment' AND p.post_mime_type LIKE 'image/%' AND NOT EXISTS (SELECT 1 FROM wp_postmeta m WHERE m.post_id = p.ID AND m.meta_key = '_wp_attachment_image_alt')"Adjust the prefix if the site isn’t on wp_. Then fix the worst offenders by hand, and tell whoever exports the images that embedded alt text now survives into WordPress.
