WordPress is not standing still. That much is clear. But the way people talk about it right now is often too neat. One side talks as if AI is about to rescue the platform and make it feel modern overnight. The other talks as if WordPress is finished and simply waiting to be replaced. Neither version feels serious. The truth is less dramatic and more useful: WordPress is still evolving, still very important, and still capable, but a lot of the pain users actually feel has not gone away.
The first thing to get straight is the current release reality. The latest stable version is not 7.0. It is the 6.9 branch, with 6.9.4 listed as the latest release in the official archive on 12 March 2026. WordPress 7.0 was meant to land in April 2026, but that release has been delayed. So any honest discussion has to begin there: users are still living on 6.9.x, while 7.0 remains a delayed next step rather than something already in their hands.
That comparison matters because 6.9 and 7.0 do not feel like the same kind of release. WordPress 6.9 looks like a strengthening release. It brought 33 accessibility enhancements and fixes in core, including better screen reader feedback and wider interface clean-up. It also shipped the server-side Abilities API, which is one of the key technical foundations for the new AI direction. In other words, 6.9 was not mainly about hype. It was about tightening the product and laying plumbing.
What makes 7.0 different is that it looks more ambitious and more structurally opinionated. Public developer updates point to three major themes: real-time collaboration in the editor, a platform-level AI client and connectors system, and a client-side expansion of the Abilities API. That is a bigger directional statement than 6.9 made. It says WordPress is trying to become more collaborative, more AI-capable, and more like a platform with shared infrastructure rather than just a CMS with plugins bolted onto it.
On paper, that all sounds sensible. From a technical point of view, it is far more mature than simply dumping a chatbot into the dashboard and calling it innovation. The Abilities API creates a discoverable registry of capabilities, the AI client aims to standardise how WordPress talks to providers, and the Connectors layer is meant to make provider choice and credential storage into proper platform features rather than something every plugin reinvents badly. That is serious architecture, not just trend-chasing.
But users do not experience WordPress as architecture diagrams. They experience it as a site that needs editing, a plugin that broke after an update, a dashboard crowded with notices, a block editor that sometimes feels elegant and sometimes feels maddening, and a pile of third-party decisions that can turn a good system into a clumsy one. That is where the conversation gets more honest, because the official roadmap and the lived experience are not always aligned.
A fair reading of current community discussion is not that people hate WordPress. In fact, many still recommend it. The repeated theme is more specific than that. Users still see WordPress as useful and powerful, but they also describe it as something that asks too much judgement from the person using it. Pick the wrong theme, the wrong page builder, the wrong form plugin, the wrong “accessibility solution”, or simply too many plugins, and the quality of the experience falls sharply. That is not a tiny problem. That is one of the core weaknesses of the ecosystem.
That weakness becomes obvious in the Gutenberg and page-builder discussions. Some agencies say Gutenberg has matured enough that they have switched client builds over to it for performance and long-term maintainability, but even those discussions still mention practical blockers such as responsive controls and editor ergonomics. On the other side, there are still blunt complaints that page builders feel easier, less buggy, or more controllable for real project work. The important point is not that one side is right and the other wrong. The point is that WordPress still has not settled this argument in users’ minds, which tells you the editing experience is still uneven in practice.
Accessibility is where the gap between official progress and ecosystem reality becomes hardest to ignore. At project level, WordPress is clearly still investing in accessibility. The 6.9 cycle included a meaningful set of accessibility fixes, and the Accessibility Team has continued publishing updated guidance, including refreshed documentation around the accessibility-ready theme tag. That part is real and should be acknowledged.
But the larger ecosystem remains inconsistent in ways that matter to real users. This is where people get misled. A site owner hears that WordPress takes accessibility seriously and assumes the ecosystem will more or less carry them safely if they choose a decent-looking theme and a few popular plugins. That is not how this works. The final experience can still be damaged by inaccessible navigation patterns, poor keyboard handling, broken focus behaviour, weak form markup, low contrast styling, overlays masquerading as accessibility fixes, and page-builder output that looks polished visually but falls apart under proper testing. The existence of updated accessibility-ready guidance is not proof that the problem is solved. It is proof that the ecosystem still needs correction.
The most uncomfortable part of the accessibility problem is the commercial behaviour around it. Across recent Reddit and plugin-forum posts, one of the strongest recurring criticisms is aimed at accessibility widgets and overlay-style plugins that imply they can make a site compliant or legally safer by adding a layer on top. The complaints are blunt, but the underlying concern is sound: these products often create false confidence. They do not repair poor structure, bad semantics, broken interactions, or missing content alternatives. At worst, they turn accessibility into a marketing line instead of an engineering and design responsibility.
That is why it is not enough for WordPress to improve core while letting the ecosystem keep selling comfort in place of competence. From a user perspective, this is one of the platform’s most persistent trust problems. The average site owner is not equipped to distinguish an actually responsible accessibility approach from a plugin that merely sounds reassuring. And WordPress, for all its strengths, still leaves too much of that sorting work to the user.
AI may improve some of this, but it could also make parts of it worse. The optimistic case is clear enough. Shared AI infrastructure means developers can build against common patterns instead of every plugin inventing its own incompatible provider logic. It could make content assistance, workflow automation, admin tasks, and richer integrations more consistent. That is the good version.
The darker version is also easy to imagine, and frankly already visible at the edges. AI lowers the cost of producing more things, including more mediocre things. More shallow plugins. More autogenerated customisations. More code that appears to work until it meets maintenance, accessibility testing, real content, or real users. WordPress already has a clutter problem. AI will not automatically reduce that. Without discipline, it could multiply it.
There is also a broader quality and trust issue that should not be skipped over. In the last week alone, reporting has described compromised WordPress plugins being used to target large numbers of sites after ownership changes. That is a security story rather than an accessibility story, but it points to the same structural issue: WordPress is powerful because of its ecosystem, yet that same openness means ordinary users are constantly exposed to uneven quality, commercial games, and risks they are not always equipped to evaluate. Accessibility inconsistency sits inside that larger ecosystem problem.
So where does that leave WordPress right now?
It leaves it in a position that is both stronger and messier than the loudest takes admit. WordPress 6.9 shows meaningful core progress, especially in accessibility and technical foundations. The public 7.0 material shows a platform trying to prepare properly for collaboration and AI rather than just pretending. But the daily user experience is still too dependent on whether the person building the site knew how to choose wisely across themes, builders, plugins, hosting, and patterns that vary wildly in quality. That remains one of WordPress’s biggest unresolved weaknesses.
In plain terms, WordPress is still useful, still powerful, and still very relevant. But it is also still too clutter-friendly, too uneven, and too willing to let the ecosystem create confusion around what is genuinely accessible, maintainable, or well built. The official roadmap is becoming more technically coherent. The ecosystem still often is not.
What to expect from WordPress 7.0
Based on public developer notes and official statements, WordPress 7.0 is expected to bring three major shifts if the delayed release lands with the current scope intact.
The first is real-time collaboration in the block editor. Official developer updates describe Yjs-based collaboration, an HTTP polling sync provider selected for broad hosting compatibility, and an architecture that is now being reworked because the current implementation caused deeper performance concerns. That delay itself is revealing. It suggests WordPress leadership decided this feature was important enough not to ship half-fixed. It also suggests that collaboration is not a side experiment anymore. It is a flagship capability.
The second is AI infrastructure moving closer to core platform status. Public notes describe a core AI client, a Connectors API for provider configuration and credentials, official provider packages for OpenAI, Google, and Anthropic, and a JavaScript-side expansion of the Abilities API. In practical terms, that means WordPress is trying to make AI integrations more standardised, more swappable, and less dependent on each plugin doing its own thing. That is probably the most important AI-related change to watch, because it affects how the whole ecosystem may build going forward.
The third is continued editor and theme-system refinement rather than a single flashy redesign. The April developer update points to things like navigation improvements in the Site Editor, pseudo-state styling for buttons in Global Styles, viewport-based block visibility controls, theme.json expansions, command palette improvements, and visual revision tracking in the editor. In other words, 7.0 is not only about AI. It is also about deeper editing and styling infrastructure.
There are also two practical expectations worth stating clearly. One is that classic meta boxes will be a growing point of friction, because official guidance already says they disable collaboration mode for a post. The other is that older hosting environments will need attention, because WordPress 7.0 is set to drop PHP 7.2 and 7.3, raising the minimum to PHP 7.4. So for agencies and plugin authors, 7.0 is not just a feature update. It is a compatibility and architecture signal.
So the honest expectation for 7.0 is this: it should be a more strategically important release than 6.9, but not necessarily a more comfortable one. It is likely to move WordPress further into collaboration and AI-capable infrastructure, while also forcing parts of the ecosystem to adapt. That could be very good for the platform long term. It could also expose, even more clearly, where older plugin habits, weak accessibility practices, and messy editorial patterns are no longer keeping up.
