Why an AI accessibility system breaks on live content
An AI accessibility system confidently passes static markup: headings, images, and basic fields get labels and roles. Failure begins where the interface lives — content loads after the first render, changes without a page reload, and reacts to human actions.
Dynamic blocks, pop-ups, and updatable catalog sections are either absent at the time of the check or in a different state.
Forms add a second layer: field hints, error states, and success messages live in separate layers and often remain inaccessible blocks disconnected from the field itself.
Non-standard components — script-based lists, custom switches, carousels — have no native semantics, and automated markup assigns roles at random.
In the report, this looks like dozens of identical findings, but behind each one is a scenario: keyboard navigation does not get past the first block, focus remains behind the pop-up, no one announces content changes.
A person using a screen reader does not "experience inconvenience" — they cannot fill out a form or select a product.
That is why interface accessibility is built not on a one-time check of a finished page, but on a behavior model: which blocks appear, in what order, what should be announced and when. Below, we break down how such a model closes accessibility errors before release.
What Changes After Implementation: Measurable Effects
Before implementation, the share of inaccessible blocks in a typical release is measured in tens of percent: images without text equivalents, buttons without labels, elements that keyboard focus does not reach.
The system flags them during the build and sorts them by impact on completing a scenario, so the team fixes not the entire list but what actually blocks the user.
Text equivalent coverage stops depending on whether a developer remembered to add a description. Image recognition and caption generation cover mass cases automatically, while disputed ones go to manual review — coverage grows with every build, rather than once after an audit.
Release verification time is reduced many times over.
A manual run before release took days and still remained selective, while checking on every change returns a list of discrepancies in minutes: an engineer looks only at new and affected blocks rather than going through the entire interface.
An entire class of failures disappears — "we didn't notice before release." Previously, an inaccessible element was discovered from reports by users of assistive technologies, and the fix was urgent; now the signal comes before release, and the fix goes into the normal workflow.
Interface stability is maintained separately: traversal order, focus logic, and role markup do not fall apart during re-layout or when modules are added.
These effects are measurable — the share of covered blocks, the number of discrepancies per release, time to release — and they show whether the system works or was simply installed.
Markup Modes and Accessibility Levels
The system marks up materials in one of three processing modes, and the mode determines how quickly edits appear on the page and how much manual work remains for the editorial team.
We compare by constraints, not convenience — it is constraints that determine the choice for a specific content stream.
| Mode | When it fits | Constraints |
|---|---|---|
| Markup at publication | Materials enter through the system and go straight to the reader | Requires integration with the publishing pipeline; an already released archive is not covered |
| Batch processing | The archive is published and needs to be covered entirely | Edits arrive in portions — between runs there is a window without markup |
| Hybrid mode | Critical pages where a markup error is costly | Some decisions are confirmed by a human, which is a speed bottleneck |
Accessibility levels are set separately from the mode and do not depend on it. Basic covers keyboard navigation, labels for controls, and meaningful alternative texts.
The target level adds contrast, scaling up to large font sizes, and a logical heading structure; the maximum level adds transcripts and subtitles for media.
Verification is performed for each level with a separate report: you can see which pages reached the required bar and which did not.
In hybrid mode, the system flags disputed fragments and sends them for confirmation — usually this is a few percent of the total volume. Such a set provides predictable quality where the cost of an error is higher than speed, and does not slow down the rest of the stream.
Implementation Stages: From Interface Audit to Handover
Work proceeds sequentially: each stage relies on the result of the previous one and ends with a verifiable artifact. Markup rules are configured only after real user scenarios are fixed — otherwise automation locks in an incorrect screen structure.
- Interface audit. We go through key screens: heading structure, keyboard traversal order, forms, contrast, focus visibility. The output is a defect map prioritized by scenario frequency, not by how "scary" the error is.
- Integration scheme. We determine connection points: at build time, in markup templates, or on top of the finished interface. We record what data the system receives from your platform and in what form it returns the result.
- Markup rule configuration. We define semantic roles, traversal order, text description templates, and labels for non-visual controls. A rule defined once then works on all new pages.
- Testing on real scenarios. We run typical tasks — search, form filling, checkout — with a screen reader and keyboard only. We check whether the scenario reaches completion, not just whether checks pass.
- Acceptance testing. We compare the result against the agreed list of criteria: the share of screens that passed the check, the list of exceptions, and the rationale for each.
- System handover. We provide rule documentation, a support procedure, and team training: how to add a new component without breaking the accessibility of neighboring screens.
After handover, new defects are caught during the build and in markup edits, not in user reports. Refining one component takes minutes because the rules and checks are already described.
Documentation, Diagrams, and Procedures Package
The documentation package is not a report for the sake of a report, but a working tool for your team after project handover. Each artifact describes how the system is currently configured, what can be changed without a developer, and where responsibility boundaries lie. Everything is versioned together with the release: change a rule — the description is updated too.
- System configurations — settings for trigger thresholds, replacement dictionaries, and markup parsing rules, with a note on what each parameter affects.
- Data flow diagrams — the path from interface scanning to report: where fragments are stored, how long they live, what goes to external services.
- Access policies — roles, who sees source materials, who edits verification rules, how access is granted and revoked.
- Exception descriptions — nodes and content types deliberately excluded from automated verification, with the reason for the decision, even if they formally fall under accessibility requirements.
- Support procedure — frequency of quality checks, procedure for updating models, and rules for rolling back to a previous version.
- Team instructions — how to add a new content type, handle a false positive, and make sure an update has not broken reporting.
- Acceptance checklist and decision log — which indicators are considered normal, which deviations require intervention.
We review the package together with your engineers during handover — so that six months later you do not have to reconstruct the logic from code.
Case Study: How We Reduced the Share of Inaccessible Blocks in a Catalog
A catalog with several tens of thousands of cards: markup is assembled from shared templates, and accessibility was checked manually once a quarter across a dozen random pages.
At the start of the implementation case, the sample showed about a third of blocks with violations: icon buttons without labels, filters inaccessible from the keyboard, contrast below threshold, heading order that broke screen reader navigation.
The error lived in the card template and filter panel, so it was reproduced across thousands of pages at once.
What Was Changed in the Markup
The main shift was that verification moved from manual audit into the build. The rules were described in terms of WCAG: mandatory text alternative for controls, logical focus order, accessible names for fields and drop-down lists, text contrast against the background.
Verification was connected to the catalog build pipeline, so the build fails on a violation in the shared template, not on an individual page; in parallel, a dashboard appeared showing the share of blocks with violations by template.
Metrics Before and After
Over two release cycles, the share of inaccessible blocks in the sample fell from 34% to 4%, with only a few critical violations remaining per release. Manual audit shrank from a quarterly sweep to targeted checking of new components — the same modals and dynamic filters.
Repeat violations almost disappeared: the cause is fixed in the template once, not in a thousand cards.
Side effect: markup became predictable for automated tests — the same selectors work in both accessibility checks and checkout scenario regressions, so new components pass both checks without duplicating work.
How Automated Markup Differs from Manual Audit
Automated verification relies on formal attributes: text contrast against background, alternative image descriptions, heading order, labels for form fields, roles and states of interactive elements, keyboard control at the markup level.
A run across the entire site takes minutes and happens on every change, so regressions are found before release, not after a user report. The reference for the rules is WCAG, level AA as the baseline.
The boundaries of automation lie where meaning is needed, rather than matching a template.
The tool sees that an image description is filled in, but does not understand whether it describes the content; it will find a modal, but will not check whether focus returns to the button after closing.
This is where the AI part works: the model suggests a draft description, flags disputed blocks, and prioritizes the report, while the decision remains with the engineer.
Manual audit is scenario-based manual checking: go through an application path using only the keyboard, listen to the page with a screen reader, zoom in and make sure meaning is not lost.
This catches defects that are formally "green" in the report: unclear error messages, broken traversal order, focus traps in drop-down lists.
The combination of approaches is built by frequency: automated verification on every change, manual audit on key scenarios and before major releases.
Automation closes about a third of violations, but most importantly it prevents them from returning; the rest is covered by manual review. The output is not a one-time report, but a process where semantic defects do not accumulate until the next audit.
Technical Concerns Before Starting a Project
Before starting, clients test us for durability: will markup work on their custom interfaces, what will happen to already released materials, who is responsible for the result after handover. Below are five questions that are asked most often.
How accurate will markup be on custom widgets and modals?
We start with an inventory of components and check each with a screen reader. For non-standard nodes, we describe roles, focus order, and labels manually — automation skips such places.
What will happen to already released content — will it have to be rewritten?
No. Materials are checked, edits are made selectively, only where markup interferes with reading. Mass re-layout is not needed: new rules apply to what is released next.
How does markup behave in dynamic blocks — lazy loading, filters, pop-ups?
We check such blocks separately: it is important that focus is not lost and changes are announced. For each scenario, we fix a behavior rule and cover it with a check.
Who is responsible for the system's operation after handover?
We hand over verification configurations, markup rules, and instructions for your team, and provide support under the agreed procedure for an agreed period — responsibility remains until stable metrics are reached.
Can implementation be phased without stopping releases?
Yes, we proceed in waves: first one section or page type, then the rest. Releases do not stop — new rules are applied to the next stream of materials.
Let's Discuss the Task and Come Back with an Estimate and Plan
So that the scope estimate is based on facts rather than assumptions, it is worth gathering several inputs for the task discussion. They significantly shorten the path from the first conversation to the start of work — engineers do not have to clarify basic things along the way.
- List of interfaces: which screens, pages, mobile applications, and internal panels fall within the accessibility scope, and which remain outside it.
- Access to systems: a test environment with representative data, accounts for verification, the ability to connect automated checks to the build.
- Current state: user complaints, external audit reports, a list of already fixed violations — so as not to start from scratch.
- Target coverage and priorities: which user categories and violation types we address first, which compliance level we consider sufficient.
- Project constraints: security requirements, prohibition on data export, approval procedure for edits, release windows.
- Responsible people on your side: who accepts the result by stage and to whom questions about product decisions go.
Based on the conversation, we come back with a scope estimate, a stage-by-stage work plan, and a list of what needs to be prepared before the start: where we issue access, on which environment we verify, and at what point we bring in the development team.
Describe the task — we will come back with an estimate and plan, without general promises: what we do, in what sequence, and what will be required from your side.
