Making Kontent.ai Accessible
A years-long effort to make a complex enterprise CMS work for everyone — including the people who have no alternative but to use it.
Why this mattered to me
Most accessibility problems are annoying. For a sighted user who finds something confusing, there’s always a workaround — a different path, a colleague to ask, muddling through. For someone using a screen reader or keyboard-only navigation, a broken interaction isn’t annoying. It’s a wall.
They didn’t choose Kontent.ai. Their employer did. They have no alternative but to work with what they’re given.
That asymmetry is what kept me pushing for this long before anyone asked me to. Inaccessible design isn’t just bad UX — it’s exclusion the person on the receiving end can’t escape.
Context
Kontent.ai is an enterprise headless CMS. Editors spend their entire working day in it — managing thousands of content items, editing rich text, reordering content blocks, navigating complex content models. For most users, it’s a demanding but workable professional tool. For users with disabilities, it’s a professional tool they’re required to use, often with assistive technology that had never been tested against it.
When I joined, accessibility wasn’t on the roadmap. It wasn’t in the design principles. It wasn’t in anyone’s goals.
The groundwork (2019–2022)
The 2019/2020 Kontent.ai redesign was my first real opportunity. I built WCAG-compliant color contrast into the design system from the start — not retrofitted, assumed. That decision meant the visual layer was largely compliant by the time the Scope project launched years later.
Beyond that, my influence was incremental: making contrast, keyboard navigation, and label quality standard criteria in design reviews; making the business case internally using legal risk and disability prevalence data; running sessions to build basic awareness across design and engineering.
The management response was always some version of the same question: “Will they buy more?” Accessibility is hard to tie directly to revenue. The feedback loop from users with disabilities was structurally broken — 90% click away rather than report issues, so the problem was invisible in normal product metrics. Without a paying customer explicitly demanding it, it couldn’t compete for roadmap space against features with measurable conversion impact.
The advocacy years weren’t just meetings and business cases. I’d been designing accessible patterns throughout — so when the crisis hit and prioritisation finally came, a significant amount of design work was already done and waiting for development.
The crisis
In May 2024, a client made it impossible to look away.
Scope is a UK disability equality charity. Their editors include people with disabilities using assistive technology every day. When they re-platformed onto Kontent.ai, accessibility wasn’t a requirement on a checklist — it was the point. And the platform failed them.
Their Executive Director sent this email:
“Kontent.ai team — this is an unfortunate start to what I was led to believe was a partnership with yourselves as a ‘leading CMS’ that understood our priorities as a non-profit organisation. To be honest, I am disappointed that I made the decision to spend donated funds from our supporters, with yourselves.
Lastly, I would like to request that no quote, mention of Scope, case study, article, LinkedIn posts or other social media posts by yourselves refers to me, my team or Scope. This is not an accessible platform.” — Kwesi Afful, Executive Director for Digital, Data and Marketing, Scope (May 2024)
The email reached the right people. Almost overnight, years of slow progress gave way to genuine organisational focus. I stepped in as the designer on the project.
How we worked
The standard approach to accessibility remediation is an audit: hire specialists, generate a list of WCAG violations, fix them in priority order. We didn’t do that.
Instead, Scope’s team participated directly. Every week, their editors — people with disabilities using their own assistive technology — tested actual tasks from their real working day. Not controlled test scenarios. Not hypothetical journeys.
What we found challenged a lot of assumptions. Features we’d prioritised internally turned out to matter less than we’d thought. Parts of the UI we’d flagged as problems were fine in practice. The things that genuinely blocked Scope’s editors were different from what we’d anticipated.
This is a consistent pattern in accessibility work: WCAG compliance audits tell you what’s technically broken by specification. Real users tell you what’s actually blocking them. Those two lists don’t fully overlap.
The other surprise was Scope themselves. After the May 2024 email, a difficult relationship felt likely. The opposite was true — they were collaborative, practical, and generous with their time. Of the 12 vendors they’d originally approached, Kontent.ai was the only one that said it genuinely wanted to help.
The hardest problem: drag and drop
Drag and drop is fundamental to how Kontent.ai works — reordering content blocks, elements within content types, items in lists. It’s also one of the most exclusionary interaction patterns in UI design: impossible for keyboard-only users, poorly supported by screen readers, and difficult for users with limited motor control.
A single keyboard alternative wasn’t enough — different users have different needs, and covering one edge case while leaving others unresolved isn’t accessibility, it’s liability management.
The solution was multi-layered:
- Arrow key reordering — pick up an item, reposition it with arrow keys; screen reader announces position change at each step
- Separate move UI — an explicit mode for users who can’t interact with drag handles at all
- Arrow buttons on drag handles — visible up/down controls alongside every dragger, for users who can use a mouse but find drag imprecise (motor impairments, trackpad users, touch screens)
The rest of the platform
Focus indicators — In the 2019/2020 redesign, focus styles had been suppressed for aesthetic reasons. We went back through the design system and reinstated visible, WCAG-compliant focus states on every interactive element across the platform.
Skip links — Added to every page, enabling direct access to main content. Without them, screen reader and keyboard users must tab through the full navigation on every page load before they can reach anything useful.
ARIA landmarks — Introduced throughout the interface so assistive technology users can jump between page regions — navigation, main content, sidebar — without tabbing through everything in sequence.
Link and button labels — Rewrote generic labels (“button”, “click here”, “read more”) to communicate purpose in context. Eliminated duplicate links pointing to different destinations — invisible to sighted users, deeply confusing in screen reader navigation lists.
Dragon Dictation compatibility — Voice control software requires elements to have accurate, unique labels that match exactly what the user says aloud. This required close work with engineering given Dragon’s non-standard behaviour and the limitations of the software itself.
Outcome
January 2026 — Kontent.ai becomes the first headless CMS fully compliant with WCAG 2.2 Level AA and EN 301 549, the European accessibility standard for digital products.
Two years after the email that threatened to end the relationship entirely:
“It was really great speaking to the Kontent team, who listened to the pain points that different editors and our colleagues had, and they were able to act quickly. That built trust. Of the original 12 vendors, only one said they really wanted to help and work with us. We had weekly collaboration with the engineering teams, who were also learning as they were building this accessible way, designing and practically testing real content workflows, not hypothetical journeys. We’re very grateful for the time invested, and now we have an outstanding product.” — Kwesi Afful, Executive Director for Digital, Data and Marketing, Scope (February 2026)
