Written and reviewed by the Green Arrow Consultancy team, led by Darren Tyler, founder and chief executive.
Accessibility is not a plugin, a badge or a script you paste before the footer. It is a set of testable engineering requirements, and increasingly a legal exposure attached to a named person in your organisation. We audit, we fix, and we leave you able to prove it.
Green Arrow Consultancy is a web accessibility agency that audits, remediates and maintains digital estates against WCAG 2.2 Level AA. We pair automated scanning with manual keyboard and screen reader testing, fix the code rather than mask it, repair PDF and PowerPoint libraries at scale, and write the accessibility statement that has to stand behind the claim.
Run an automated scanner over a page and it will return a tidy list: contrast ratios, missing alt attributes, unlabelled inputs, duplicate identifiers, a handful of ARIA violations. Every one of those is a real defect and every one is worth fixing. They are also the failures a machine can decide on its own, which is a minority of the Web Content Accessibility Guidelines success criteria. The rest require judgement.
A scanner can confirm that an image has an alt attribute. It cannot tell you the alt text says “image1.jpg”. It can confirm a heading exists. It cannot tell you the page jumps from an h1 to an h4 and back, so a screen reader user navigating by heading gets a garbled outline of your pricing page. It can confirm a button is focusable. It cannot tell you the focus ring is drawn behind a sticky header, that the modal never returns focus to the control that opened it, or that the error summary appears visually but is never announced.
We start with automated coverage across the estate using axe, because clearing mechanical failures in bulk is cheap and it stops the manual pass drowning in noise. Then the real testing begins. Keyboard only, with no mouse, through every journey that matters. Screen reader passes with NVDA on Firefox, JAWS on Chrome, VoiceOver on macOS and iOS, and TalkBack on Android, because assistive technologies disagree with each other and with browsers constantly. Browser zoom to 400 percent. Reflow at 320 CSS pixels. Forced colours mode, which reveals every component that carried meaning in a background image. Speech input on the controls a customer would use to buy something.
Nobody audits forty thousand URLs, and nobody needs to. We sample by template, by shared component and by journey, because a defect in a header, a form field or a card component is a single fix that repeats across the estate. A good sample is one where every distinct interaction pattern in your codebase appears at least once: navigation, search, filters, data table, modal, carousel, video player, checkout, account area and error states.
An audit that ends in a percentage is not much use to a development team. Ours ends in an issue register: the failing success criterion, the severity, the templates affected, the assistive technology and browser combination that exposes it, a reproduction path, and a suggested fix written against your actual markup. Issues are grouped so a developer can close twenty instances in one pull request rather than twenty tickets.
Ten patterns account for the large majority of what we log on a first audit. None of them is exotic, and most of them originate in the design system rather than in any individual page.
| Failure type | Who it affects | The fix |
|---|---|---|
| Alt text that describes the file, not the function | Screen reader users, people on slow or blocked connections | Write alt that carries what the image does in context. Mark genuinely decorative images empty. |
| Text contrast below 4.5 to 1 | People with low vision, older readers, anyone on a phone in daylight | Correct the colour tokens in the design system, not each component. Test the hover and disabled states too. |
| Focus indicator removed with outline: none | Keyboard users, people with motor impairments, switch users | Restore a visible indicator that meets the WCAG 2.2 focus criteria against every background it lands on. |
| Custom widgets built from div and span | Screen reader users, voice control users | Use the native element. Where a custom control is unavoidable, implement the full ARIA pattern including state and keyboard model. |
| Placeholder text used instead of a label | Screen reader users, people with cognitive and memory difficulties | A persistent, programmatically associated label on every field. Placeholders are a hint, never a label. |
| Drag-only interactions: sortable lists, sliders, map pins | People with tremor, limited dexterity, or using a switch or head pointer | Provide a single-pointer alternative. This is what WCAG 2.2 Dragging Movements requires. |
| Modal dialogs that do not trap or return focus | Keyboard and screen reader users | Move focus in on open, contain it, restore it to the trigger on close, and label the dialog. |
| Video without captions or a transcript | Deaf and hard of hearing users, people in noisy or silent environments | Accurate captions, plus a transcript. Auto-captions are a draft, not a deliverable. |
| Timeouts on forms and baskets with no warning | People with cognitive impairments, motor impairments, or anyone using a translation tool | Warn before expiry, offer an extension, and preserve entered data. |
| PDFs and decks with no tags or reading order | Screen reader users, anyone reflowing content on a phone | Tag the document, set the reading order, add alt text and table headers, set language and title. |
Drawn from audits across managed client estates. Presented as recurring patterns, not as a measured frequency distribution.
WCAG 2.2 keeps everything in 2.1 and adds nine success criteria, six of which are summarised here. It also removed the old parsing criterion, which is the one piece of good news in the update. If you conformed to 2.1 AA, you are close, but the new criteria concentrate in exactly the places where money changes hands.
A focused element must not be completely hidden by other content. Sticky headers, cookie banners and chat widgets break this constantly, and it only appears when you tab through with the keyboard rather than click.
Sets out how substantial a focus indicator has to be, in area and contrast. It sits at Level AAA, which confuses people, but Focus Visible remains Level AA, so a hairline indicator is still a problem worth fixing.
Anything achieved by dragging needs a single-pointer alternative. Sortable lists, range sliders, signature fields, map interactions and drag-to-upload widgets are where this bites, and the fix is design work, not CSS.
Interactive targets need a minimum size unless an exception applies. Dense icon toolbars, pagination and inline text links inside tables are the usual failures on mobile checkout journeys.
If help is available, it appears in the same relative place across pages. Sites that move the contact link between header, footer and a floating widget depending on the template fail this without anyone noticing.
Do not make somebody re-enter information they already gave you in the same process, and do not gate login behind a memory or transcription test with no alternative. Both hit registration and checkout hardest.
This section is general information, not legal advice. We are engineers and privacy practitioners, not your solicitors. Take the technical picture below to your own advisers and let them tell you what applies to your entities, your markets and your contracts. We deliberately do not quote enforcement dates or penalty figures here, because they vary by jurisdiction and they change.
The European Accessibility Act is European Union legislation on the accessibility of certain products and services placed on the EU market. It reaches into categories including e-commerce, consumer banking, transport services, telecommunications and e-books. It is a directive, so it takes effect through each member state's own transposing law, so the detail, the enforcement body and the treatment of smaller organisations differ by country. Alongside it sits EN 301 549, the harmonised European standard for accessibility requirements in ICT products and services, which incorporates the WCAG success criteria and adds requirements for software, hardware and documentation. EN 301 549 is what European public sector procurement points at, so if you sell to government in the European Economic Area you will meet it in a tender questionnaire before you meet it in a court.
The UK did not adopt the European Accessibility Act, but the practical requirements have not gone away. Public sector bodies are covered by their own accessibility regulations, which require conformance to a named WCAG level and a published accessibility statement. Private sector organisations sit under the Equality Act 2010 and its duty to make reasonable adjustments, which is where most UK complaints originate. And any UK business selling into the EU is dealing with EU rules regardless of where it is registered.
The Americans with Disabilities Act does not contain a technical web standard in its text, which is why the US picture has been shaped by litigation and by Department of Justice rulemaking rather than by a single statute. A federal rule sets WCAG 2.1 Level AA as the technical standard for state and local government web content and mobile apps, with phased compliance timing set out in the rule itself. Federal agencies and their suppliers work to Section 508, whose revised standards incorporate WCAG by reference, which is why American buyers ask for a VPAT before they ask for a demo. Private sector obligations under Title III continue to be argued in court, and demand letters remain common.
Accessibility overlays are sold as a single line of JavaScript that makes a site compliant. They cannot do that. An overlay operates on the rendered page after your code has produced it, so it is guessing at intent it cannot see. It cannot know why an image is on the page, so it cannot write alt text that carries meaning. It frequently conflicts with the screen reader and settings a disabled person has already configured, which is why disability advocacy groups have been so consistently critical of them. It does nothing for your PDF library, your native apps or your emails. And because the defects stay in the codebase, every release regresses. Organisations running overlays have still received demand letters. The only durable remedy is corrected source code.
Most organisations have more inaccessible content sitting in document libraries than on their website, and almost no website audit ever touches it. Public sector suppliers, financial services and manufacturers with technical documentation carry the largest backlogs.
Annual reports, datasheets, manuals and policy documents exported straight from InDesign or Word with no tag tree. To a screen reader they are an undifferentiated wall, or a scanned image with no text layer at all. Tagging, reading order, table headers, bookmarks, language and title all have to be set.
PowerPoint reads slides in the order objects were added, not the order they appear. A deck built by duplicating and dragging boxes will be read out backwards. Layout placeholders, reading order, alt text on charts and real tables instead of pictures of tables are the difference between a usable deck and a locked one.
Headings created by making text bigger and bolder are not headings. Lists made with hyphens are not lists. Neither survives conversion to PDF or HTML, so a single bad template propagates through everything generated from it for years.
We run a production tool that processes PowerPoint and PDF libraries in bulk: it drafts alt text for images and charts, corrects slide and document reading order, and flags what a machine should not decide alone. A reviewer signs off before anything is republished.
The demonstration on this site is a generalised version of software we use on client libraries. The production application, including batch processing of real files, runs separately and is available to clients under an engagement.
Repairing a library is a one-off cost. We rebuild the master templates, the export settings and the editor guidance so the next thousand documents are born accessible, which is the only version of this that stays fixed. Content editor training is part of the handover.
Six stages. Teams that start at stage three, page by page, are still there a year later with a backlog that grows faster than they close it.
Audit representative templates, shared components and complete journeys against WCAG 2.2 AA. Agree the target level in writing, including anything you will not meet and why, because a claim you cannot evidence is worse than an honest exception.
Colour tokens, focus styles, target sizes, form field patterns, the modal, the accordion, the data table. One correction in a shared component closes the same issue everywhere it is used, and it stops the backlog regrowing while you work through it.
Checkout, registration, search, contact, account management. Brochure pages come after the routes where a blocked user is a lost customer and a complaint. This is also the order that removes the most legal exposure per day of effort.
Alt text, heading structure, meaningful link text, captions and transcripts. Then the PDF, PowerPoint and Word libraries, prioritised by what customers actually download rather than by what is oldest.
Automated checks in continuous integration, an accessibility line in the definition of done, component tests, a pull request checklist, and training for the designers, developers and content editors who will otherwise reintroduce the same defects within a quarter.
An accessibility statement with a real known-issues list and a date against each item. Retest after each release train, and review the estate on a fixed cycle as part of ongoing website management rather than as an annual panic.
The same list whether the engagement is a single audit or a year-long programme.
Darren Tyler has been doing work for me on Energizer's website compliance. Not only has he met our teams expectations but exceeded them.
More on standards, jurisdictions and ways of working in the full FAQ and the glossary.
A WCAG audit tests a representative sample of your templates, components and user journeys against the Web Content Accessibility Guidelines success criteria, at the conformance level you are targeting. A real audit is part automated and mostly manual: keyboard-only operation, screen reader passes, zoom and reflow, forced colours, and judgement calls that no scanner can make, such as whether alt text carries the meaning of the image or whether an error message is announced. The deliverable is an issue register with the failing criterion, severity, where it occurs, how to reproduce it and a code-level fix, not a score.
No, and the gap is not small. Automated engines such as axe and the accessibility audits in Lighthouse are excellent at what they can decide mechanically: missing alt attributes, contrast ratios on plain text, unlabelled form fields, duplicate identifiers, some ARIA misuse. They cannot tell you whether the alt text is right, whether the heading structure describes the page, whether focus order follows the visual order, whether a custom component announces its state, or whether captions match the audio. Those are the failures that actually stop somebody completing a purchase, and they need a person and a screen reader.
Level AA is the level almost every law, procurement standard and contract points at. It means text contrast of at least 4.5 to 1 for body copy, every function operable by keyboard, visible focus, content that reflows at 320 CSS pixels without horizontal scrolling, captions on pre-recorded video, form fields with real labels and error messages that describe the fix, and consistent navigation. WCAG 2.2 keeps everything in 2.1 and adds criteria covering obscured focus, dragging movements, target size, consistent help, redundant entry and authentication that does not depend on a cognitive test.
It depends on what you sell, to whom and where, and it is a question for your legal advisers rather than for us. In general terms the Act is European Union legislation covering the accessibility of certain products and services placed on the EU market, including categories such as e-commerce, consumer banking, transport and e-books, and it is transposed into national law by each member state, so the detail varies by country. Micro-enterprises are treated differently. The practical technical answer is usually the same either way: conform to WCAG 2.2 Level AA, follow EN 301 549 where it applies, and be able to evidence it.
No. An overlay is a script that modifies the rendered page after it loads. It cannot repair source semantics reliably, it cannot write alt text that reflects why an image is on the page, it can conflict with the assistive technology a person has already configured, it does nothing for your PDFs or your native apps, and it leaves the underlying defects in the codebase so every release regresses. Disability advocacy groups have been consistently critical of them, and installing one has not prevented organisations from being sued. Fix the code.
For a typical marketing site or a mid-sized web application, expect two to four weeks from access to report. Sampling is what drives the timeline, not page count: we test templates, shared components and complete journeys, because a fault in a header or a form component is one fix that repeats across thousands of URLs. Large estates and complex single-page applications take longer, and we scope those after a short reconnaissance pass.
Audits are fixed price once we have seen the estate. Remediation is quoted per workstream, because the honest range is wide: a design system with token-level contrast and focus problems can be corrected in days and the fix lands everywhere, while a bespoke component library built from unlabelled div elements is a rebuild. Document libraries are priced by volume and by how much structure the originals have left. We will tell you which fixes remove the most exposure first so the budget can be staged.
Yes, and this is the half of accessibility that most audits never reach. We repair tagging and reading order, add alt text that describes function rather than decoration, correct table headers, set document language and titles, and rebuild slide structures that were assembled from floating text boxes. We run a production tool that processes PowerPoint and PDF libraries in batch, generating draft alt text and correcting reading order, with a human review pass before anything is republished.
Yes. We draft the accessibility statement, including the conformance claim, the known issues with a plan and a date against each, the feedback route and the escalation path. Where a buyer or a public sector customer asks for a Voluntary Product Accessibility Template or an Accessibility Conformance Report, we produce it from the audit evidence rather than from a questionnaire, which is why ours tend to survive scrutiny.
Our own team, using keyboard, NVDA, JAWS, VoiceOver on macOS and iOS, TalkBack on Android, browser zoom to 400 percent, reflow at 320 CSS pixels and forced colours mode. Automated scanning runs first to clear the mechanical failures cheaply, then the manual work starts. We do not outsource the judgement calls, because the judgement calls are the audit.
Written and reviewed by the Green Arrow Consultancy team, led by Darren Tyler, founder and chief executive.
We will tell you what fails, how deep the problem goes, and whether you are looking at a fortnight of component work or a genuine rebuild. No score out of a hundred.