State agencies, city governments, and public university websites all have April 26, 2027 on their respective calendars. On that date, any public entity serving 50,000 people or more will be required to conform to WCAG 2.1 AA in accordance with the Justice Department’s ADA Title II rule. Entities serving less than 50,000 people must comply by April 2028. The deadline moved once before, but planning around another delay is a gamble.
The good news? Your CMS can simplify compliance.
While AI capabilities and media enhancements were getting all the headlines, WordPress accessibility had a far busier year than release coverage suggested. Somewhat buried in the developer release notes for WordPress 7.0 and 7.1 are 127 updates that improve accessibility in WordPress Core and the Gutenberg Block Editor.
What follows is a deeper dive into what changed in those two releases, how the changes will (or won’t) help with WCAG, ADA, and Section 508 compliance obligations, and what you’ll still need to check to make your site compliant by the deadline.
If you’re a developer, an accessibility practitioner, or on a public sector, higher ed, or corporate team managing WCAG, ADA, or Section 508 obligations, here’s what the last two releases actually changed.
What changed for WordPress accessibility in 7.0 and 7.1
WordPress release notes separate code changes and feature enhancements based on where they impact WordPress, which means accessibility improvements will be divided between WordPress Core and the Gutenberg Block Editor.
The list below clusters the changes by where you will see them affect your site during an accessibility audit.
Keyboard and focus
- Admin focus indicators are now standardized at a minimum of 2 CSS pixels (7.1).
- Focus traps caused by certain CSS display properties are fixed in editor components (7.1).
- Focus indicators in the media library stay fully visible (7.1).
- Keyboard navigation fixes were implemented in the block editor (7.0).
Screen readers
- Admin screens behave more predictably with screen readers (7.0).
- The editor now uses the WordPress speak() function for announcements instead of separate live regions, so feedback is more consistent (7.1).
- Page headers in admin screens now default to H1, which gives each screen a correct heading structure (7.1).
- Untitled items in the media grid get accurate labels, and caption fields have clearer labels (7.1).
Contrast and display modes
- Color contrast fixes were implemented across the admin (7.0), plus higher contrast in the admin color schemes (7.1).
- Fixes for forced-colors mode were implemented in the editor (7.0).
- Active states for buttons and tabs now show in Windows High Contrast Mode (7.1).
Media and alt text
- The media library now supports voice control (7.0).
- Alt text stored in an image’s IPTC metadata can be imported on upload (7.0).
- The image block has a new toggle that marks an image as decorative (7.1).
New interfaces
- Visual Revisions, the Gallery lightbox, and Connectors were reviewed against WCAG 2.2 AA before they shipped (7.0).
- The new Tabs and Playlist blocks were released as part of 7.1. Tabs are a design pattern that is easy to get wrong from an accessibility perspective, so they’re worth testing on your site if you plan to use them.
A small step backward
The developer notes for 7.1 point out that making infinite scroll the default in the media library is an inaccessible design pattern. Users can turn off infinite scroll in their profile settings, or you can turn it off for everyone by default by setting media_library_infinite_scrolling to return false.
Why it matters if you’re on the hook for WCAG, Section 508, or ADA
Section 508, ADA Title II, Section 504, and ADA Title III originate from different laws, apply to different organizations, and have different timelines for compliance. To varying degrees, they all measure your site against Web Content Accessibility Guidelines (WCAG) at the AA level. Title III has no written standard, but demand letters and settlements usually cite WCAG AA as the expected remediation.
Each version of the WCAG standard differs by building on the one that came before. WCAG 2.1 keeps all the AA requirements from 2.0 and adds more. 2.2 does the same with 2.1. In practice, if you focus on complying with the newest version of the standard, you’ve met the older ones too, while staying ahead of future changes to legislation.
The changes that improve accessibility in WordPress 7.0 and 7.1 help your organization meet WCAG guidelines regardless of which legal mandate applies to your organization.
What the platform covers and what you still own
An accessible CMS takes platform accessibility off your list of things to fix, allowing your team to focus on making the site’s design accessible. WordPress Core and the block editor control the admin screens your content team uses daily, the markup output in blocks, and the behavior of every interface throughout the CMS. When those get accessibility improvements, every site running WordPress becomes more accessible.
Accessibility of the site’s theme, custom blocks, plugin library, published content, PDF uploads, and any third-party embeds remains your team’s responsibility. The new 2px focus indicator that shipped in 7.1 won’t help your theme if it was designed to strip focus outlines. And that new decorative image toggle doesn’t change the need to write meaningful alt text for images that require a description. Choices like those are managed by your team.
Why the platform improvements matter
Audits expose accessibility gaps without telling you which system or team is responsible for the issue. WordPress fixes like the markup core blocks output benefit your site visitors. Other fixes change the admin screens used by your content team. Those matter for anyone on your team using assistive technology, which helps with meeting Section 508 requirements for employee-facing tools at federal agencies.
Fixing accessibility issues at the platform layer means fewer workarounds with each new WordPress version, reducing the number of issues your team needs to fix later.
The advantage of an open platform like WordPress is that all improvements to the platform are documented publicly, along with the discussions that led to that change. When it’s time for an accessibility audit, the transparent public release notes show exactly how the platform handles accessibility without needing to take a vendor’s word for it.
What this means if you’re running WordPress at scale
To benefit from these WordPress accessibility improvements, keep your platform updated to the latest version. For a single site, updating is fairly simple. If your organization has hundreds of sites with different owners and release cycles, keeping every site on the latest version of WordPress is a bigger project.
Before your portfolio is due for another accessibility audit, consider the following:
- Verify which version of WordPress currently powers your site. If it’s a 6.x release, you aren’t taking advantage of the accessibility improvements released in 7.0 and 7.1.
- If you are running 7.1, consider making the media library more accessible by default by turning off infinite scroll instead of making each user find the opt-out setting in their profile.
- Retest any custom blocks and themes against the new admin focus and contrast features because the updates might eliminate the need for workarounds used with older versions of WordPress.
- Before using the new Tabs and Playlist blocks on your live site, test them in a staging environment to verify their impact on accessibility so you can make sure they don’t introduce new issues.
Using a platform like WordPress VIP to manage your portfolio of sites takes the burden of WordPress updates off of your team and moves it to the platform, which means your sites stay current and get fixes like these sooner.
It also addresses the security requirements that slow public sector purchases, with FedRAMP Moderate authorization and SOC 2 Type II attestation. Running the latest version of WordPress doesn’t remove the need for an accessibility review of your site, but it does make sure you are starting from the most current set of features.
The quieter story
April 2027 will be here before you know it. Between now and then, the platform powering your site will keep shipping additional releases. Each release will either make complying more complicated or reduce the number of items in your accessibility backlog.
The CMS running 43% of the web just shipped 127 accessibility improvements in two releases, and neither one made a headline. For compliance teams, that’s the story.
