Anne Bovelett homepage, logo

Your CMS backend could be costing your customers employees, money, and business

By Anne-Mieke Bovelett on November 13, 2026
Status: up to date

Companion resources for my CMSConf 2026 presentation in Gdynia, Poland from November 13, 2026

We’re having some fascinating conversations about AI in the CMS industry. Content generation, automated publishing, intelligent workflows, AI agents that manage entire websites. If you listen to some of the predictions, you might get the impression that humans will soon have very little reason to enter a CMS dashboard at all.

I’ve been building websites since 1998, and I’ve seen quite a few technologies arrive with promises to change everything. Some really did transform our industry. Others turned out to be considerably more complicated, expensive, or limited than their early advocates expected. That’s why I think we need to be careful about making product decisions based on what we hope AI will eventually accomplish.

Because even with increasingly sophisticated AI, organizations still employ people to create, manage, review, and publish content. Those people need software they can operate independently, efficiently, and comfortably. Yet while we’ve spent years discussing the accessibility of the websites people visit, we’ve paid surprisingly little attention to the accessibility of the interfaces where those websites are actually maintained.

For CMS developers and vendors, I believe this represents an opportunity that deserves considerably more attention. Accessible administration interfaces can help organizations accommodate a wider workforce, meet their responsibilities as employers, and improve the way employees interact with business-critical systems. And if you’re developing or selling CMS technology, these are valuable capabilities to bring into your commercial conversations.

AI isn’t making human workers disappear

In November 2026, Gartner published research that should give anyone relying on AI to replace human work something to think about. The company surveyed 275 customer service and support leaders about AI adoption and workforce decisions. Seven percent reported that their organizations had already rehired human workers following previous workforce reductions, while another 11% expected to rehire within the following 18 months.

Gartner also predicts that by 2027, half of companies that reduced customer service staffing because of AI will rehire people for similar functions, potentially under different job titles. That is a forecast, and the survey does not establish that every reported rehire was directly caused by AI failure. Nevertheless, Gartner specifically warns about the risks of reducing staffing before AI has demonstrated that it can reliably handle the necessary work. Recruitment, onboarding, training, and rebuilding institutional knowledge introduce costs that organizations may have underestimated when making their original decisions.

You can read the findings in Gartner’s November 5, 2026 report on AI-related workforce reductions and rehiring.

The financial picture is becoming interesting too. In a separate November 2026 report, Gartner found that only 4% of the surveyed customer service organizations had achieved their expected return on investment from AI initiatives. Meanwhile, Reuters reported on November 10 that banks were looking for ways to control the operating costs of AI agents. McKinsey research cited in that report suggested that spending on AI-agent tokens could potentially reach 20% of labor costs in banking. That figure is a projection for a particular sector, rather than an established average or an estimate for CMS automation.

These findings don’t tell us that AI is ineffective, and they certainly don’t mean we should stop investing in automation. They do remind us that the total cost of an AI solution includes more than the subscription or API bill. Failed attempts, human verification, monitoring, integrations, maintenance, and recovering from errors can all add to the operating costs. Before assuming AI will make human interaction with CMS dashboards unnecessary, wouldn’t it make sense to establish that the technology can actually perform the required tasks reliably and economically?

Further reading: Gartner’s November 2026 research on AI return on investment in customer service.

A CMS backend is somebody’s workplace

Think about the people who actually use CMS administration interfaces. Content editors, marketers, translators, product managers, customer service employees, and colleagues responsible for publishing information all depend on these systems to do their jobs. Their responsibilities may involve editing articles, managing products, entering prices, approving publications, uploading media, or maintaining content across hundreds of websites.

Now consider how those tasks work for someone who cannot use a mouse, needs voice control, or relies on a screen reader. Can they reach every control, understand what it does, complete the action, and move on to the next task without asking somebody else for help? Does the interface remain usable when they enlarge the text or increase browser zoom?

These questions concern different aspects of accessibility. Screen reader users often rely on keyboard commands, but testing successfully with a screen reader does not automatically demonstrate that the interface works well for sighted keyboard users. Missing focus indicators, for example, can make it extremely difficult to understand which control is currently active. Voice control introduces additional considerations, such as whether a button’s accessible name contains the text displayed on the screen.

For a developer, these might sound like relatively small implementation details. For an employee who cannot complete an essential task, they can determine whether that person is able to work independently.

There’s a W3C standard specifically for authoring tools

Most web developers are familiar with the Web Content Accessibility Guidelines (WCAG), but far fewer seem to know about the Authoring Tool Accessibility Guidelines (ATAG). These guidelines address the accessibility of tools used to create content, including their user interfaces, as well as the support those tools provide for producing accessible content.

That distinction is particularly important for CMS development. A CMS might generate beautifully structured, accessible frontend pages while presenting serious barriers to the people responsible for maintaining them. Improving the output doesn’t automatically improve the working environment.

For developers interested in the technical requirements, I recommend starting with the Authoring Tool Accessibility Guidelines 2.0 and Implementing ATAG 2.0. The Web Content Accessibility Guidelines 2.2 provide additional requirements and explanations covering keyboard access, visible focus, input methods, and interface behavior. Two particularly relevant resources are Understanding Focus Visible and Understanding Label in Name.

Disability employment is also a financial issue for employers

Here’s where accessible CMS development becomes especially interesting from a commercial perspective. In many countries, employing people with disabilities is supported by legal obligations, financial incentives, and government programs. Some countries require employers to reserve a percentage of positions for workers with disabilities and impose financial contributions when those obligations are not met. Others provide wage subsidies, tax relief, reduced social contributions, or financial assistance for workplace accommodations. Several use a combination of these approaches.

Employers operating in these markets already have reasons to consider disability inclusion as part of their workforce planning. Their internal software is part of that equation, even when the people making procurement decisions haven’t connected the two.

Imagine a large organization that has invested in recruiting employees with disabilities, providing workplace accommodations, and developing inclusive employment policies. It then purchases a CMS whose administration interface cannot be operated independently by some of those employees. The organization may have created an additional barrier through its own technology choices.

An accessible CMS cannot guarantee that an employer fulfills its disability employment obligations. It doesn’t automatically eliminate financial contributions or qualify the organization for government subsidies. But accessible workplace software can contribute to enabling employees to perform their jobs, which makes it a relevant consideration when organizations select business-critical systems.

Disability employment requirements in eight countries

The following overview shows how different countries approach disability employment. The figures describe the main statutory requirements as of November 2026. Definitions, exemptions, counting methods, and contribution calculations differ, so these figures should be considered a starting point rather than a complete explanation of each country’s legislation.

CountryEmployment requirementsFinancial mechanisms
GermanyGenerally 5% for employers with at least 20 qualifying positions, with special rules for employers with 20–59 positionsGraduated compensation levy for unfilled mandatory positions
France6% for qualifying employers with at least 20 employeesAnnual financial contribution when obligations are unmet, subject to applicable rules and transitional arrangements
Spain2% for public and private employers with at least 50 employeesExceptional arrangements permit approved alternative compliance measures
ItalyOne qualifying employee at 15–35 employees, two at 36–50, and 7% above 50Statutory employment obligations with exemptions, contributions, and enforcement mechanisms
AustriaOne qualifying employee for every 25 workersMonthly compensation levy of €344, €485, or €512 per unfilled position in 2026, depending on employer size
Japan2.7% for private employers from July 2026, generally relevant from 37.5 workers under statutory counting rulesLevy arrangements and employment support mechanisms
South Korea3.1% for private employers with at least 50 workers and 3.8% for covered public employersEmployment levies generally apply to private employers with at least 100 workers; qualifying employers may receive grants
TurkeyGenerally 3% in private workplaces and 4% in public workplaces employing at least 50 peopleAdministrative fines for unfilled mandatory positions

These percentages alone don’t explain the entire legal situation. In particular, thresholds for employment obligations and financial contributions aren’t always identical, and national definitions of qualifying disability can differ considerably.

Austria provides a useful illustration of how the financial implications can accumulate. In 2026, the monthly compensation levy is €344, €485, or €512 for each unfilled mandatory position, depending on employer size. For an organization in the €485 category, a single unfilled position maintained throughout the year would represent €5,820 in contributions. That doesn’t mean purchasing accessible software would remove the contribution, but it helps explain why employers have financial reasons to take workforce inclusion seriously.

Official sources for the country figures:

Governments also provide financial incentives

The European Commission’s research on reasonable accommodation at work reports that 11 EU countries offer tax relief for employers hiring workers with disabilities, while 13 provide reductions in employer social-security or health-insurance contributions. Most EU countries also offer wage subsidies, and many provide financial support for adapting workplaces.

The European Commission’s guide to reasonable accommodation at work explains these mechanisms in greater detail. The Employment Equality Directive 2000/78/EC also establishes the framework for reasonable accommodation in employment, subject to its requirements and exceptions.

For CMS vendors, this is worth paying attention to. An organization investing in disability employment and workplace accessibility may have good reasons to prioritize software that supports its employees. That creates an opportunity for vendors who can demonstrate accessible administration interfaces and explain their practical value.

The employment gap is much bigger than any individual CMS

According to the European Commission’s Disability Employment Package, approximately 42.8 million people with disabilities in the EU are of working age, and only about half are employed.

There are many reasons for this gap, including discrimination, inaccessible environments, inadequate accommodations, and unequal access to opportunities. It would be absurd to suggest that fixing CMS dashboards would solve the entire problem. But workplace software is part of the environment people encounter when they try to find employment, perform their duties, and develop their careers.

Developers have direct influence over that part of the environment. We decide whether people can reach controls, understand information, use alternative input methods, and complete the tasks their jobs require. Those decisions can make a genuine difference to someone’s ability to participate in working life.

Don’t forget the employees over 50

There’s another group I think our industry should pay considerably more attention to: people whose needs change as they get older.

Imagine a content manager who has been working with publishing systems for more than 20 years. They understand the organization, know its customers, and can manage complicated workflows almost instinctively. They’re now 55 and increasingly find themselves enlarging the text on their screen because the interface is uncomfortable to read at its default size.

That’s hardly an unusual situation. According to the US National Eye Institute, presbyopia, the age-related reduction in the ability to focus on nearby objects, generally begins after approximately age 45. The World Health Organization also reports that most people experiencing vision impairment or blindness are over 50.

Neither statement means that everyone over 50 has a disability. Many people compensate effectively for age-related changes with glasses or other adjustments. But it does mean we should stop designing software as though people’s physical capabilities remain unchanged throughout their working lives.

What happens when that experienced content manager increases browser zoom to 200% and essential buttons disappear? Or when a dialog becomes impossible to operate because its content no longer fits within the available space? What if low-contrast labels become difficult to distinguish, or the interface breaks when text is enlarged?

These are avoidable barriers that can interfere with the work of experienced employees. Organizations have invested years in their knowledge and skills, and accessible software can help them continue using that experience effectively.

For CMS developers, this also widens the commercial conversation. Accessibility isn’t relevant only to employees with officially recognized disabilities. It matters to organizations with multigenerational workforces, people recovering from injuries, employees dealing with temporary limitations, and anyone who benefits from more flexible ways of interacting with software.

What does an inaccessible backend actually cost?

When a CMS interface creates barriers, somebody often has to deal with the consequences. An editor cannot complete a task, contacts support, asks a colleague for help, or needs additional training to work around the problem. Each individual incident might appear relatively insignificant, but repeated across a large organization, that extra work can become expensive.

I haven’t found a reliable universal figure showing exactly how much inaccessible CMS backends cost organizations in support hours. And I wouldn’t trust a sweeping industry statistic without knowing how it was calculated. Fortunately, organizations can measure the impact within their own environments.

One starting point is to identify support requests related to interface barriers and calculate their estimated handling costs:

Estimated monthly interface-related support cost = number of relevant support tickets × average handling time in minutes ÷ 60 × fully loaded hourly support cost.

For a more complete picture, an organization could also examine how long employees take to complete common tasks, how frequently errors occur, how often colleagues need to intervene, and how much training is required. Comparing those measurements before and after accessibility improvements can help establish whether the changes produce operational benefits.

This is also an opportunity for CMS developers and agencies to sell valuable services. Accessibility audits, remediation, workflow evaluations, training, and ongoing maintenance can all contribute to helping customers improve their systems. Rather than promising an arbitrary return on investment, you can help customers identify the problems that affect them and measure what happens when those problems are addressed.

Can AI compensate for an inaccessible CMS backend?

AI browser agents can already perform impressive tasks. Depending on their architecture, they may examine accessibility trees, interact with the DOM, interpret screenshots, simulate keyboard and pointer input, or communicate with APIs. In some situations, they can navigate interfaces that humans find difficult to operate.

But that doesn’t mean we can assume AI will compensate for every accessibility problem. Agents can encounter ambiguous controls, unexpected interface behavior, navigation problems, and situations where the result of an action is difficult to verify. I recently encountered this while working with AI automation in bookkeeping software, where particular dropdown interactions proved problematic. That’s one practical example, not evidence that every AI agent would fail in the same circumstances.

What interests me is the commercial implication. If an automated workflow requires repeated attempts, human intervention, monitoring, and error recovery, those activities belong in its total cost calculation. The same applies to maintaining the integrations and infrastructure that make automation possible.

Clear, semantically meaningful interfaces and predictable behavior can benefit human users and certain forms of automation. However, an accessible CMS isn’t automatically AI-friendly in every respect, and successful AI automation doesn’t demonstrate that humans can operate the interface. Both capabilities need to be evaluated on their own terms.

I’d also encourage CMS developers to consider well-documented, secure APIs where automation makes sense. Sometimes direct integration is more reliable and efficient than forcing an AI agent to operate a graphical interface intended for human interaction. That doesn’t remove the need for an accessible backend, because employees still need to review, correct, approve, and manage content.

If your development strategy assumes that AI will eventually make human accessibility unnecessary, you’re making a fairly substantial bet on capabilities and operating costs that may change considerably over the coming years. I’d much rather see CMS products designed to work well for people now, with automation built on top of a reliable technical foundation.

Accessible CMS development is a commercial opportunity

Now imagine you’re competing for an enterprise CMS contract. Your product supports the necessary publishing workflows, user permissions, integrations, and content structures. So does your competitor’s product.

But there’s something additional you can demonstrate. Your CMS backend has been tested with keyboard navigation, screen readers, voice control, and enlarged text. You have documented its accessibility, can explain the limitations that remain, and understand how accessible workplace technology relates to the customer’s workforce requirements.

That can make a difference during software procurement, particularly when the organization has accessibility requirements, disability inclusion commitments, or employees who depend on alternative interaction methods. It may also help you reach organizations that haven’t previously considered backend accessibility as a purchasing criterion.

For CMS vendors, this creates opportunities to make accessibility part of product positioning, enterprise sales, licensing discussions, and procurement documentation. For agencies, it can support implementation projects, migrations, accessibility audits, remediation, training, and maintenance agreements. Consultants can offer independent evaluations, procurement guidance, workflow assessments, and advice on accessibility requirements.

Open source CMS projects also have something to gain. Accessible administration interfaces can make their ecosystems more welcoming to contributors and users, while giving the agencies and companies building services around those platforms another valuable capability to offer customers.

Of course, none of this guarantees an increase in revenue. But accessibility is a capability that customers may be willing to pay for, especially when vendors can demonstrate its practical relevance to their organizations.

Have you made accessibility part of your sales conversation?

If you’re developing a CMS or building services around one, I’d encourage you to examine how well you’re communicating the value of accessible interfaces.

Can you demonstrate common editing workflows using only a keyboard? Have you tested screen reader and voice-control interaction separately? Does your interface support text resizing and browser zoom without losing functionality? Can you provide useful accessibility documentation when a prospective enterprise customer asks for it?

And perhaps most importantly, do you understand how accessibility connects to the customer’s operational needs, workforce, procurement requirements, and business objectives?

You can also start measuring the commercial impact. How frequently does accessibility appear in tenders and procurement questionnaires? Does it influence sales conversations or implementation requirements? Are customers requesting accessibility audits, remediation, or ongoing support? Those are much more useful questions than simply assuming that accessibility either does or doesn’t generate revenue.

Further reading and references

I’ve collected the sources supporting this talk below, including technical standards, employment legislation, research into AI adoption, and information about age-related vision changes.

Accessibility standards and technical guidance

Employment obligations and workplace inclusion

The official sources for the eight national employment systems are linked directly beneath the country comparison above.

AI costs and workforce decisions

Aging and vision

The opportunity is already there

I’ve been working with websites and content management systems for nearly three decades, and I know how much expertise goes into creating software that people can rely on. CMS developers make countless decisions about functionality, interaction patterns, architecture, and maintainability, often under considerable pressure to deliver more features in less time.

I want accessibility to become part of those decisions from the beginning, because the interface people use to do their jobs deserves as much attention as the websites they publish.

And I want CMS developers to recognize the commercial potential of that expertise. Organizations need technology that supports their employees, works with their operational processes, and remains usable as people’s needs change. Developers who can demonstrate that their products meet those needs have something genuinely valuable to offer.

If you’re already building accessible CMS backends, make sure your customers understand why that matters. And if you aren’t, this might be a very good time to start.

This companion article accompanies my CMSConf 2026 presentation in Gdynia, Poland. Employment figures and financial mechanisms reflect information published for November 2026. National rules and eligibility criteria can change. The article is intended to support technical and commercial discussions, rather than provide individualized legal or financial advice.

Latest articles

Topics