When Accessibility Meets Platform Limits

Building a WCAG 2.2 AA Website Is Harder Than It Should Be

When I started building the BlindSpot Solutions website, my goal was simple. I wanted the site to meet WCAG 2.2 AA accessibility standards. Not “close enough”. Not “good intentions”. Actually compliant.

WCAG stands for the Web Content Accessibility Guidelines. They are internationally recognised standards developed by the World Wide Web Consortium (W3C) to help ensure websites can be used by people with disability. The guidelines cover areas such as keyboard navigation, screen reader compatibility, colour contrast, captions for video and many other aspects of accessible design. Level AA is generally considered the practical benchmark for most organisations and is the level referenced by many accessibility laws and policies around the world.

After all, it would be somewhat ironic to run an accessibility consultancy with a website that does not meet accessibility guidelines. If I am encouraging organisations to remove barriers for their staff and customers, it is only fair that my own digital front door follows the same principles.

Like many small businesses, I chose a drag-and-drop website builder. These platforms promise speed, simplicity and modern design. You can launch quickly without needing a development team, and most of the design work can be done visually rather than through code. For many organisations, that works well. You can get a professional looking website online in a relatively short time.

At first, everything appeared straightforward. The templates looked good, the layout tools were easy to use, and publishing pages was simple. From a visual design perspective, the platform did exactly what it promised.

But things started to change once I began looking at the site through an accessibility lens.

Trying to build a website that genuinely meets WCAG 2.2 AA standards is very different from simply building a website that looks good on the screen. Accessibility requires attention to structure, navigation, interaction and how assistive technologies interpret the page. It also requires the ability to control how the website behaves, not just how it looks.

What began as a routine quality check quickly turned into a much deeper learning experience. The more I tested, the more I realised that some accessibility issues were not caused by design choices. In several cases, the limitations were coming from the platform itself.

That is when the process shifted from simply improving the website to asking a bigger question. What happens when you want to build an accessible site, but the tool you are using makes some of those changes difficult or impossible?

Using AI to Audit the Site

Once the initial build was complete, I decided to run a proper accessibility review. Rather than relying only on manual checks, I used AI to assist with the process. I asked Claude to conduct a WCAG 2.2 AA audit by reviewing the site structure, page elements and interaction patterns against the accessibility guidelines.

AI is becoming surprisingly useful for this type of work. It does not replace formal accessibility testing, but it can quickly highlight potential issues and patterns that deserve closer inspection. In many ways it acts as an efficient first pass, pointing out areas that may need further investigation.

The results were eye-opening.

Not because the site had issues. That was expected. Any meaningful accessibility review will identify areas that can be improved. If an accessibility audit comes back completely clean, it usually raises more questions about the audit than the website.

What stood out, however, was where many of the issues were coming from.

Several findings were not related to my content or design decisions. Instead, they were linked to how the platform generates code, navigation elements and interactive components.

In other words, some accessibility barriers were being introduced by the underlying system rather than by the person building the site.

That creates an unusual situation. Even when you are actively trying to improve accessibility, certain changes become difficult or impossible because the platform does not provide enough control over how elements behave.

It is a slightly uncomfortable moment when you realise that the thing preventing you from fixing accessibility issues is the very tool you are using to build the website.

Keyboard Navigation Should Not Be This Hard

One of the most important principles in digital accessibility is keyboard accessibility. Not everyone can use a mouse. Many people rely on a keyboard, switch device or other assistive technology to move through a website and interact with content.

For a website to be accessible, every important function should be usable without a mouse. Users should be able to move through links, buttons, forms and menus using standard keyboard controls.

In simple terms, if someone cannot complete key tasks using the keyboard alone, the site is not fully accessible.

When testing the website, I expected to find a few areas that needed improvement. What I did not expect was how difficult some of these changes would be to implement within the platform itself.

A number of issues became clear as soon as I began navigating the site using only the keyboard.

Tab navigation and logical focus order → Users should be able to move through interactive elements using the Tab key in a logical and predictable order. In several places the focus order did not follow the natural reading order of the page.

Visible keyboard focus → As users tab through a page, it should be clear which element currently has focus. While some focus indicators were present, there was limited control over how they appeared.

Interactive elements reachable by keyboard → Some elements looked clickable on the screen but were not reachable using keyboard navigation. This means a user relying on the keyboard may not even realise the element exists, let alone interact with it.

Navigation components and screen reader behaviour → Certain navigation structures generated by the platform behaved inconsistently when tested with assistive technology. In some cases menus and navigation items did not follow expected accessibility patterns.

In a fully custom coded website, these issues can usually be addressed by adjusting the HTML structure, improving keyboard event handling or refining focus management.

In a template-driven website platform, the situation is different. Many components are generated automatically, and the platform limits access to the underlying code.

That means you cannot always change how these elements behave.

Instead, you are often expected to accept the way the system works.

Which becomes slightly awkward when the system itself is introducing the accessibility barrier.

Video Accessibility Is Still an Afterthought

Another area where accessibility challenges appeared was video content.

Video is now a common part of many websites. It is often used to introduce services, explain concepts or provide training material. Because of this, accessibility standards include clear expectations for how video should be delivered.

Captions for spoken audio → Captions allow people who are deaf or hard of hearing to access spoken dialogue and key audio information. They are also useful for people watching videos in noisy environments or where sound is not available.

Clear and accessible playback controls → Users should be able to start, pause, adjust volume and navigate the video using accessible controls that are easy to locate and usable with keyboard navigation and assistive technology.

Media players that work with assistive technologies → The video player itself needs to interact properly with screen readers and keyboard navigation. If the player cannot be controlled or understood by assistive technology, the video may effectively become unusable for some users.

While reviewing the website, I discovered that the built-in video player provided by the platform does not properly support caption integration. There is no simple or reliable way to attach caption files directly to the player, nor is there clear control over how captions are handled by assistive technologies.

The most common workaround is to embed video from third-party platforms such as YouTube or Vimeo. However, that approach introduces its own complications, including privacy, branding, advertising and layout control.

In practice, the decision becomes a choice between working around the platform or accepting certain accessibility limitations. Neither option feels particularly elegant when the goal is simply to make content accessible to everyone.

The Hidden Limits of Drag and Drop Platforms

Drag-and-drop website builders are powerful tools. They have opened the door for small organisations to create professional looking websites without needing a developer.

However, this simplicity comes with a trade-off. When using a drag-and-drop platform, you rely on the structure and behaviour the platform generates behind the scenes. While you control how the page looks, you often have far less control over how the page is built technically.

Limited access to ARIA attributes → ARIA attributes provide additional context to assistive technologies. Many template platforms restrict direct access to these attributes, which limits the ability to fine tune accessibility behaviour.

Restricted control over semantic HTML structure → Accessibility relies heavily on proper semantic HTML. Template-driven platforms often generate this structure automatically but do not always allow it to be adjusted.

Inconsistent heading hierarchy → Headings may appear visually correct but fail to follow a logical hierarchy in the underlying code.

Limited control over keyboard interaction behaviour → Menus and interactive elements are often pre-built by the platform. If they do not fully support keyboard interaction, there may be little ability to modify them.

Difficulty implementing accessible custom components → Advanced accessibility patterns may require custom components, which many drag-and-drop platforms do not support easily.

From a visual design perspective, everything may look polished. From an accessibility perspective, however, many critical elements sit outside your control.

It becomes a little like assembling flat-pack furniture only to discover the screwdriver has been glued to the table.

Accessibility Should Not Depend on Workarounds

One of the more frustrating parts of this process is that many accessibility problems are not technically complex. In most cases, the solutions already exist and are well understood within the web development community.

What is often missing is prioritisation at the platform level. Accessible video players already exist. Keyboard navigation patterns are well documented. Semantic HTML and ARIA roles are widely understood. Focus management is a known design pattern.

These are not experimental ideas. They are established accessibility fundamentals. Yet many platforms still treat accessibility as something that sits slightly outside the core product design process.

The result is that organisations trying to build accessible websites often rely on workarounds rather than having the right tools available from the start.

The Future: WCAG 3 and Outcome-Driven Accessibility

While many organisations are still working hard to meet WCAG 2.2, the accessibility standards themselves are already evolving.

The next generation of guidance, WCAG 3, represents a noticeable shift in thinking. Earlier versions of WCAG largely rely on technical success criteria that determine whether a page passes or fails based on specific rules. WCAG 3 begins to move toward a more outcome-driven model.

Rather than asking only whether a technical requirement has been satisfied, the focus shifts toward a more practical question. Can people successfully use the website to complete the tasks they came to do?

Which, when you think about it, is probably what we should have been measuring all along.

Outcome-Based Testing

WCAG 3 proposes measuring accessibility based on user outcomes, not just code compliance. The goal is to understand whether people can interact with a website effectively in real situations.

Can a user navigate a page using a keyboard without confusion? → The navigation flow should be predictable and easy to follow for people who rely on keyboard interaction rather than a mouse.

Can someone with low vision locate and activate key actions? → Important buttons, links and controls should be easy to find and usable when zoomed or viewed with assistive technology.

Can a person using assistive technology complete a task without unnecessary friction? → Screen reader users and others relying on assistive tools should be able to move through the site and complete common tasks without unexpected barriers.

Scoring Instead of Pass or Fail

Another proposed change in WCAG 3 is the move toward graded scoring rather than strict pass or fail compliance. Instead of declaring a website either compliant or non-compliant, accessibility could be assessed through a scoring model that reflects how well a site performs across different accessibility areas and disability groups.

This creates a more realistic picture of accessibility progress. It recognises that accessibility improvements often happen over time and that different aspects of accessibility may mature at different stages.

It also acknowledges something many accessibility practitioners already know. Accessibility is rarely perfect from the start. It improves through testing, feedback and ongoing refinement.

Greater Focus on Cognitive Accessibility

One of the most significant developments within WCAG 3 is the increased attention given to cognitive accessibility. Earlier versions of WCAG focused heavily on visual, auditory and motor accessibility. WCAG 3 begins to address challenges such as:

Reducing unnecessary complexity in navigation → Users should be able to move through a website without needing to decipher complicated layouts or unpredictable navigation patterns.

Providing clear instructions and predictable interactions → Forms, buttons and processes should behave in ways that users can easily understand.

Avoiding cognitive overload → Content and interactions should not overwhelm users with unnecessary information or confusing choices.

Supporting people who process information differently → Websites should recognise that users interpret and process information in different ways and design interactions accordingly.

In simple terms, using the web should not require a puzzle-solving mindset just to complete everyday tasks.

Why Platforms Need to Pay Attention

This shift toward outcome-based accessibility has important implications for website platforms. If accessibility is assessed based on real user outcomes, then the architecture of the platform itself becomes far more significant.

Template systems that generate inaccessible structures, limit control over interaction patterns or restrict access to key accessibility features will struggle under this model. Even the most careful website owner cannot deliver accessible outcomes if the platform prevents them from doing so.

As accessibility standards evolve, platforms will need to ensure their underlying systems allow organisations to deliver experiences that genuinely work for everyone.

When the Platform Becomes the Barrier

One of the more revealing insights from this process was recognising that accessibility problems do not always originate with the person creating the content. In many cases, the platform itself becomes the barrier.

Restricted control over page structure → Some website editors limit the ability to adjust the underlying structure of a page. This can make it difficult to correct heading hierarchy, landmarks or other structural elements that assistive technologies rely on.

Templates generating inaccessible markup → Templates sometimes produce HTML structures that are not ideal from an accessibility perspective. When the template controls the markup, it can be difficult to correct these issues without access to the underlying code.

Media components with limited accessibility options → Built-in media players and interactive elements may not support features such as captions, transcripts or keyboard-accessible controls.

Fixed navigation systems → Navigation menus and interface components are often generated automatically by the platform. If those components do not follow accessible interaction patterns, website owners may have little ability to modify their behaviour.

Over time, these limitations create a subtle shift in responsibility. Accessibility expectations are often directed at organisations and website owners. Yet when the platform restricts how accessibility features can be implemented, the responsibility quietly moves away from the platform provider and onto the individual trying to build the site.

Considering a Platform Change

After completing the audit and reviewing the results, I arrived at a slightly uncomfortable conclusion. If I want the BlindSpot Solutions website to genuinely meet WCAG 2.2 AA, I may need to consider moving to a different platform.

That is not a decision most small organisations make lightly. Rebuilding a website involves migrating content, redesigning page structures, rebuilding integrations, and retesting accessibility from the ground up.

For larger organisations with dedicated development teams, this kind of rebuild may be manageable. For many small businesses, however, a full platform migration can be difficult to justify. Time, budget and operational priorities often mean organisations must work with the tools they already have.

This raises an important point. There may be thousands of organisations trying to build accessible websites using platforms that do not fully support accessibility standards. In many cases, these organisations are not ignoring accessibility. They are working within the limits of the tools available to them.

Platforms Need Greater Accountability

Conversations about accessibility often focus on the responsibilities of organisations, designers and content creators. However, there is another part of the ecosystem that deserves more attention: website platform providers.

If a platform presents itself as a professional tool for building modern websites, it should also provide the foundations needed to support accessibility standards. Website owners should not have to fight against the platform simply to implement widely recognised accessibility practices.

Accessible navigation components by default → Menus, buttons and interactive elements should follow established accessibility patterns and be usable with keyboards and assistive technologies without additional work from the site owner.

Media players that support captions and transcripts → Video and audio components should include straightforward ways to attach captions, transcripts and accessible playback controls as standard functionality.

Full keyboard navigation support → All interactive elements generated by the platform should be usable through keyboard navigation, with proper focus order, visible focus indicators and activation behaviour.

Control over semantic HTML structure → Website owners should be able to manage heading hierarchy, landmarks and structural elements so that assistive technologies can correctly interpret the page.

Compatibility with assistive technologies → Platforms should ensure their components work reliably with screen readers, keyboard navigation tools and other assistive technologies commonly used by people with disability.

None of these requirements are unusual or experimental. They represent basic accessibility foundations that have been well understood in web development for many years.

AI Is Highlighting These Gaps

Interestingly, artificial intelligence is beginning to play a role in exposing some of these platform limitations more quickly than before.

In the past, identifying accessibility issues often required specialist tools and detailed manual testing by accessibility professionals. AI tools now make it much easier to conduct an initial review, quickly highlighting patterns, structural issues and interaction problems that might otherwise take longer to identify.

Earlier identification of accessibility barriers → AI-assisted audits can help organisations detect accessibility problems earlier in the design process, before a site is launched.

More accessible testing for non-specialists → People who may not have deep technical knowledge of accessibility standards can still run basic checks and gain useful insights into potential issues.

However, these tools are also revealing something else. When AI highlights accessibility problems that cannot be fixed because the platform restricts control, it becomes clear that the barrier is not simply a lack of awareness or effort from the website owner. The limitation sits within the platform itself.

As AI-powered auditing becomes more common, these structural gaps will likely become more visible. In other words, AI is not just helping identify accessibility issues. It is also making it clearer where responsibility for those issues actually sits.

The Real Goal

Accessibility is not about ticking boxes or passing technical checks. At its core, accessibility is about creating environments where people can participate fully and independently.

The web has the potential to be one of the most accessible environments ever created. Digital experiences can adapt in ways that physical environments often cannot. Content can be resized, read aloud, translated, simplified or navigated in different ways depending on the needs of the user.

Yet despite this potential, the tools used to build websites do not always make accessibility easy to achieve. When the platforms themselves introduce limitations, organisations may find themselves trying to deliver accessible experiences with incomplete tools.

Before closing, it is important to acknowledge something. While working through this process, I discovered that the BlindSpot Solutions website is not yet as accessible as I would like it to be. The audit highlighted several areas that need improvement, and I am currently developing a plan to address them.

Some of these improvements will involve changes that the current platform cannot easily support. As a result, I am now assessing alternative platforms that provide stronger accessibility foundations.

Until accessibility is treated as core infrastructure within website platforms, rather than an optional feature or later improvement, many organisations will continue to face the same challenge.

They want to build accessible websites.

But they discover that the platform will only let them get part of the way there.

That is a challenge the broader digital industry will need to take seriously if accessibility is to become the norm rather than the exception.

💡 Small change. Big impact.