Accessibility at Scale with Craig Abbott

🎧 New Señors @ Scale Episode

This week, I spoke with Craig Abbott, Principal Accessibility Specialist at TetraLogical, where he specialises in sustainable accessibility and embedding accessibility into organisational policies and processes. Craig is the former Head of Accessibility at the Department for Work and Pensions, one of the largest government departments in the UK, where he established the department's dedicated accessibility practice from scratch. He spent years as a designer in government before a single conference talk sent him down the rabbit hole.

In this episode, we dig into what building a practice out of nothing actually involves, why culture is the hardest of the three C's, how to test with screen readers without paying for licences, what you can genuinely automate in a pipeline, why a page can pass WCAG and still be unusable, how AI-generated frontend inherits every bad example on the web, and the AAA criteria everyone ignores.

⚙️ Main Takeaways

1. He fell into it, like nearly everyone in accessibility does

The origin story, and it starts with someone else's talk.

• Before: A designer in government who knew nothing about it. "I think back to some of the stuff that I must have put out into the world and what an inaccessible mess it must have been."
• The turning point: A talk at Camp Digital by Molly Watt, now Molly Barnes, who is deaf and blind, on how Apple devices help her navigate the world — the watch, the phone streaming straight into her hearing devices. "I was like, well, this is cool. Like I had not thought about any of the stuff that I designed in this kind of way."
• Why it stuck: "With me being autistic and ADHD, if I get a special interest, I kind of go to town on it. And it just so happened that that was the thing."
• What everyone learns first: Alt text and colour contrast, especially for designers. And the learning never finishes — "you always find some problems you've never come across before."
• A nice full circle: Years later at Elastic, with a budget to spend, he brought Molly in to speak.

2. Head of accessibility, at home, during lockdown, with no practice to lead

What building it from scratch really looked like.

• The setup: DWP has around a hundred thousand people. He got the head of accessibility role because he'd been "always the person on the team that was nagging everyone to do it."
• The reality: "It was like head of nothing." No practice, no dedicated teams. He started in March 2020, everyone went home, "and I was kind of just kicking rocks on my own at home. Like, I've got no idea what this job is."
• Where he began: Auditing what already existed — stray templates, some WCAG documentation — to find out what could be leveraged.
• The research: Talking to developers, product managers, delivery managers and user researchers across the department to find the pain points and where existing processes fell over.
• The method: Treat it as product delivery, because that's what he knew. Map high-impact/low-effort work against the harder things that go into the next phase of the roadmap.

3. Sustainable accessibility means the team can check its own work

The core concept, defined against the thing most organisations actually do.

• The common pattern: Build the product, pay a third party to audit it, get told what failed and how to fix it.
• Why that decays immediately: "Say you do another release of your product — you might have introduced more accessibility issues that you now don't know about. And several releases later, you might have introduced a whole bunch of them." You're blind until you buy another audit.
• The definition: "An organisation is able to consistently deliver services and products that are accessible" — teams checking their own work, doing inclusive research, and building it into daily ways of working, rather than design and development happening first and somebody else doing the accessibility bit afterwards.
• The comparison that lands: "You don't release an app if it's full of security issues. That work just gets done automatically by the team." The goal is accessibility becoming that ordinary.
• What it takes: Policies, governance, checklists, definitions of ready and done — and a culture change that's genuinely hard.

4. Compliance, culture, capability — and culture is the hard one

The three C's, including the honest story of where the name came from.

• The original: His DWP strategy was compliance, culture and education. Carl Groves adapted it, and a content designer on that team swapped education for capability, making it the three C's. "I was like, man, I really wish I'd thought of that, because that works so much better." His note on it: "This is what happens when you open source stuff. Other people make it better."
• What each one is: Compliance is meeting the standards. Capability is whether the skills exist in the team. Culture is whether anyone actually wants to do it.
• Why they're inseparable: "You can enforce compliance, but if you don't have the capability in your teams, you can't do it. Even if you've got the capability and nobody wants to do it, then you're still going to have non-compliant services." He compares it to the fire triangle — remove one and it goes out.
• The one that's hardest: Culture, without question. "There's a lot of really good developers who can learn anything. If you throw them a new framework, they'll learn it in a week. So they're definitely capable. But if they just don't see the value in it, then they don't do it, because it's just seen as a barrier to delivery."

5. Stop the practice from leaving when the enthusiast leaves

The question I most wanted answered, and his answer is about documentation and hierarchy.

• The failure mode: "You get people like me where they've just got an interest in it and they go around being this evangelist for it. And then when they leave, it all just kind of stops."
• The organisational excuse it enables: "Well, that's fine, because that person over there does this thing, therefore we don't need to think about it."
• The lever that works best: Get senior people talking about it. "If you can get senior stakeholders invested in it and they're talking about it, then everyone just goes, oh well, this is what we're doing now, because the people with authority have said this is what we're doing."
• The lever that works when that fails: Document relentlessly and make it communal. "If you just talk about it, everyone goes, yeah, that's cool, and then they go about their day to day. But if you can document it, put it all in a repo, put stuff where people can get at it, and encourage people to contribute to it, then you can do a lot of that stuff organically."
• The DWP Accessibility Manual: Never an official project. "We just did it. And then once it was active and people were using it, it became a thing that the department had to maintain, because it was in use."
• The budget trick: Global Accessibility Awareness Day in May is often the only time you can get money for external speakers. It bothers him that it works this way — "it's like Valentine's Day, right? Like you don't bother all year and then you buy flowers on Valentine's Day" — but he uses it anyway.

6. The worse screen reader is the better test

Genuinely counterintuitive, and immediately useful.

• Why JAWS misleads you: "JAWS is very good for users, but it isn't the best for testing, in the sense that it papers over the cracks a lot. Sometimes your product doesn't seem as bad as it is, because JAWS will do a lot of that heavy lifting." It also costs around a thousand pounds for a licence.
• Why VoiceOver is better for testing: "VoiceOver on a Mac isn't particularly great, and it'll expose the issues a lot more." Less forgiving is the point.
• The pairings: JAWS with Chrome, NVDA with Firefox, VoiceOver on iOS, TalkBack on Android.
• How to do it all for free: A JAWS trial runs 40 minutes at a time before shutting off — "when you're trying to test a screen, 40 minutes is plenty." Genymotion on a Mac spins up an Android device for TalkBack. UTM on a Mac gives you a VM for NVDA and JAWS.
• The real cost: "There's maybe half an hour of setting up the VM, but once it's good to go, then it doesn't take that long to run through all the different testing scenarios."

7. What you can actually automate in a pipeline

Concrete, and further than most people assume.

• The baseline: Acceptance tests written in Gherkin — "given I load this page, when I inspect this element of the DOM, then it should have this attribute on it" — run through Playwright, Selenium or WebDriver to check computed values.
• Where it's easiest: Isolated design system components. "It's very easy to write automated tests for — it needs this attribute, when it expands or collapses it needs to add this ARIA attribute."
• How far Playwright can go: He described checking a focus indicator by taking the component's bounding box and sampling the pixels at the corners, because a focus indicator can end up rendered behind something else. "Obviously it's a little bit more involved, but once you've written the test, then you can reuse it."
• Driving the screen reader itself: Guidepup can boot and control the screen reader on your machine the way Playwright drives a browser, then extract what it announced. "It can be a little bit flaky at times, but you can get it to work."
• Where BrowserStack is heading: Running screen readers in hosted environments and exposing the readout as text. "In theory, you should be able to boot it up in BrowserStack in the browser you want, run the screen reader you want, get the text back, and then in your automated tests assert that it said what you expected it to say."
• What stays manual: Anything subjective, like whether a heading or a label actually makes sense.

8. Automated tools find around 40% of the problems

The number everyone building a compliance dashboard should know.

• Where it comes from: GDS built what he calls the world's most inaccessible webpage — roughly 144 deliberate errors — and threw every automated tool at it. "The best tools only find around 40% of those errors." He re-runs new tools against that same page as they come out.
• Why: "They're very binary. They're really good at testing things like colour contrast, because they can get to colour values, run some maths and get a binary answer. But it's really difficult to do the subjective ones."
• What that means for your pipeline: Still absolutely run them — they take seconds and catch everything obvious. Just don't mistake a green result for a finished job.

9. Compliant does not mean usable, and the examples are brutal

The section that will change how you read an audit report.

• The gap: "I've seen some stuff which is non-compliant that's very usable. And I've seen some stuff which is compliant, which just doesn't work."
• Why the gap exists: WCAG focuses on whether someone with an impairment is disadvantaged relative to everyone else, not on whether the experience is good.
• The invisible link: Take the underline off a link and make it black so it blends into the surrounding text. "It wouldn't actually fail any WCAG criteria, because nobody's disadvantaged. If you can see colour and you can't see colour, everyone's got the same experience. It's just a terrible experience."
• Two-pixel text: WCAG asks whether you can increase the font size by 200% without it breaking. "But it doesn't say you could have a minimum font size to start with." So two-pixel body text passes. There's advice about not going below 12, but no failure.
• The takeaway: Passing the automated tool, then passing a screen reader pass, then being compliant — those are three separate bars, and none of them is "usable."

10. Most accessibility issues are design problems

His argument for shifting left, from someone who was a designer first.

• Where the responsibility actually sits: "Most of the time, the accessibility issues you'll find are design problems. As a designer, we have to take a lot of responsibility for that stuff. But often we just sit in Figma and come up with all these whizzy designs and then throw them over the wall at the developer and just expect them to fix everything."
• Why dumping it downstream creates friction: "If you've got colour contrast issues in the design, it's not really the developer's job to fix those. If the developer changes the design, then the designer is going to be like, you've changed all my colours, why have you done that?"
• Start before design: In research, include a genuine variety of people. Otherwise "you'll get a middle-aged white manager go and talk to a middle-aged white manager in another organisation who's using the product, and between the two of them they'll come up with a feature that they want delivered."
• The cost of finding out late: "You'll design and build the whole project and then somebody will put their hand up and be like, I can't use this. And by that point it's too late and it'll cost you a whole bunch of money."
• Everyone's slice: Designers own contrast, target sizes and not hiding things behind hover. Developers own correct attributes and responsive behaviour as intended. QA owns tests that back the user stories. "More often than not, everyone just expects it's the developer who is going to fix all of the problems."

11. You cannot detect screen reader users, and you shouldn't want to

Why the old "who are my users" instinct doesn't transfer here.

• The technical reality: On the web you generally can't tell. It's deliberately hidden from analytics.
• The reason: Privacy and discrimination. His example — "if you're applying for health insurance and they detect a screen reader and they bump your premium, something unethical like that."
• What to do instead: Research. And ask the right question, because the obvious one fails.
• The research finding that proves it: His wife, a product manager, ran a study asking people whether they used assistive technology. Almost everyone said no. Later in the same survey they asked whether people increase the font size on their phone — "and a whole bunch of people were like, yes, I do." Same behaviour, and "that's a form of assistive technology. They just didn't know that's what they were called."

12. Three things that get you most of the way

His answer to what to do if you're only going to do a few things.

• Automated tools: "If it can find 40% of problems, then you're already 40% of the way there. Plus they're easy, they take seconds to run."
• Use it without a mouse: Keyboard-only navigation exposes a huge amount. Things you can't reach with a keyboard usually can't be reached with a screen reader either. Tab order jumping around predicts a screen reader reading things in the wrong order. And a drag-and-drop list you can't reorder with a keyboard is a barrier for anyone with a tremor or motor impairment.
• Structured content: Correct headings in the correct order, and the right elements for the right things. He calls out polymorphic components — "there's a lot of frameworks now where you can essentially just make a button a div with three characters changed."
• The historical footnote: HTML parsing was a WCAG 2.1 criterion and was removed in 2.2, because the issues it caught tended to surface under other criteria anyway. His view stands regardless: "making sure that the underlying code is sound, you've used the right elements and it's structured properly, is just best practice frontend development."
• The payoff: "If you've got those three things down, it's very rare you'll find something that is an absolute blockout of somebody doing something."

13. CSS isn't opinionated enough, and neither is your design system

The argument from his article, and it's a good one.

• What we do now: Reset all element styles, then apply everything to a class. "We'll create a class called button or BTN, and then put the class on the button element. But by doing it this way, we can essentially style a div or a span or a heading to look like a button."
• The consequence: "Semantically it isn't a button. So when you hit it with a screen reader, they have no idea what it's supposed to be. And people spend a lot of time trying to make things behave like the elements that they should have just used in the first place." You can write around thirty lines of code to make a div behave almost like a button, or use a button.
• The inversion he proposes: Style the element, not the class. "Then you cannot make something look like a button unless you use a button element — because if you want it to look like a button, you have to use the right tag, which gives it all the right semantics."
• The same trick for state: People add an open class with JavaScript so an accordion looks open, while the DOM never announces it. "Whereas if you applied it to the CSS selector for aria-expanded="true", then you physically can't have it open unless you've attached the semantics to it."
• Design systems have the same disease: Teams try to serve every designer in the organisation. "We've got to have ten variants because ten designers want different things... this one over here is a slightly different shade of blue." His view: be far more opinionated, and say no to the variant.

14. AI writes frontend from a web that's 95.8% broken

The most uncomfortable statistic in the episode, and a fair-minded read of what it means.

• The number: The latest WebAIM survey found 95.8% of the top million websites had accessibility failures detectable by automated tools alone.
• The inference: "When you think about the sheer amount of data that gets fed into LLMs, they're fed all of these bad examples of frontend code. And I think it just inevitably comes back out."
• Why HTML specifically: "HTML is so forgiving. And because HTML is so forgiving, there's a lot of bad examples that AIs get trained on." Backend code with a determined, testable outcome is a different story — there he finds it genuinely strong.
• The fair version of the criticism: "It's very easy just to say they can't do it, and I don't think that's necessarily true." Give it detailed requirements — what the accessibility tree must convey when an accordion is open, and when it's closed — "then it absolutely can just smash out a component and probably get it pretty good."
• Why that rarely happens: "That's not how I see people using AI. They're just vibe coding — now do this, now do that, and I've built the whole app in four minutes."
• His talk on it changes constantly: "It changes every two weeks. When I first started doing it, I had loads of examples of stuff that it was terrible at, and as time moves on I've had to take those examples out because it gets better."

15. Agents browsing the web won't rescue an inaccessible site

On whether AI intermediaries make the problem go away.

• The genuine wins: Camera glasses describing a scene or reading ingredients off a packet for someone who is blind. "You can effectively have these AI glasses be your eyes." With the obvious caveat — "any technology, humans tend to abuse it," and there's a real problem with people walking around with cameras on their face.
• Why it doesn't solve the underlying issue: "If there's a website that's completely inaccessible to somebody who's using a screen reader, the chances are AIs are going to struggle with it as well. They rely on HTML content being structured properly and having the right attributes."
• The irony he points at: "If you go on Claude or ChatGPT and you run accessibility tests against their software — just the chat interfaces — they've all got detectable accessibility issues in them."
• His feeling about the direction: "There's this notion that the whole way we interact with the web might change to the point where people don't even browse websites anymore, they just interact with an AI. To me that seems quite sad. That's not the world I want to live in."

16. Cognitive accessibility is stuck behind the AAA wall

Where the standard itself falls short, and what's coming.

• The structural problem: "A lot of the criteria that helps people who are neurodivergent is AAA criteria." Regulations — the European Accessibility Act, public sector accessibility regulations, Section 508 — all mandate AA. "So anything that's AAA just gets ignored. It's as if it doesn't exist."
• What's in there: Writing to a reasonable reading age, avoiding abbreviations, avoiding jargon — all readability criteria, all AAA.
• The result: "You can have a totally compliant website and nobody can understand any of the language in it, because it's written like a lawyer."
• What's being built: W3C's cognitive accessibility guidance, a set of principles for designing for neurodivergent people — content structure, reading level, plain English.
• The framing he wants people to adopt: "WCAG is supposed to be the base level. It's not supposed to be the finish line." Compliance still leaves room to exclude people — "you can be totally compliant and have a really terribly worded question about gender and still be excluding a whole bunch of people from using your service."

17. Have a repeatable audit process, because your own bias creeps in

A small, honest point about doing the work well.

• Everyone has bugbears: "Most people who do accessibility tend to have a handful of things that bother them, and they're the things that they'll go to town on." For him it's flashing and moving content, which is the ADHD side more than the autism.
• The professional consequence: "As a designer, I tend to find a lot of the design problems. If you're a developer, you'll probably find more of the development problems. So if you don't have a solid process for it, it's really easy to just find the things that bother you and then move on."
• What he actually does: "There's loads of times where I think I'm done, I'll have a whizz through a page — right, I found all the issues — and then I'll go to write it up, double check the process, and go, I've not checked for that."

🧠 What I Learned

• Third party audits alone don't produce accessible products — every release after the audit is unmeasured until you buy another one.
• Sustainable accessibility means the team can check its own work, the way teams already handle security without being asked.
• The three C's are compliance, culture and capability, and they're interdependent like a fire triangle — but culture is by far the hardest to change.
• A practice survives its founder through documentation people can contribute to, plus senior stakeholders who talk about it publicly.
• Global Accessibility Awareness Day in May is often the only reliable route to budget for external speakers.
• JAWS papers over the cracks and costs around a thousand pounds; VoiceOver and NVDA are less forgiving, which makes them better test tools.
• You can test on everything for free: a 40-minute JAWS trial, Genymotion for TalkBack, UTM for NVDA and JAWS on a Mac.
• Accessibility acceptance tests belong in CI — Gherkin plus Playwright for attributes and computed values, pixel sampling for focus indicators, Guidepup to drive the screen reader itself.
• The best automated tools find around 40% of errors, measured against a deliberately broken GDS test page with roughly 144 of them.
• Compliant is not usable: black underline-less links and two-pixel body text both pass WCAG, because nobody is disadvantaged relative to anyone else.
• Most accessibility issues originate in design, so contrast, target size and hover-dependent interactions are the designer's responsibility, not the developer's cleanup job.
• You can't detect screen reader users, deliberately — but asking "do you increase the font size on your phone?" gets the honest answer that "do you use assistive technology?" never will.
• The three highest-impact checks are automated tools, keyboard-only navigation, and correct content structure.
• Styling the element rather than a class makes it impossible to fake a button out of a div; styling aria-expanded="true" makes it impossible to look open without announcing it.
• 95.8% of the top million sites fail automated checks, which is the training data every LLM writing your frontend learned from.
• Detailed, requirement-level prompts do get accessible components out of an LLM; vibe coding does not.
• Most cognitive accessibility criteria sit at AAA, which regulation never mandates, so neurodivergent users get designed around rather than for.

💬 Favorite Quotes

"I think back to some of the stuff that I must have put out into the world and what an inaccessible mess it must have been."

"It was like head of nothing."

"You don't release an app if it's full of security issues. That work just gets done automatically by the team."

"This is what happens when you open source stuff. Other people make it better."

"If you throw them a new framework, they'll learn it in a week. So they're definitely capable. But if they just don't see the value in it, then they don't do it."

"It's like Valentine's Day, right? Like you don't bother all year and then you buy flowers on Valentine's Day."

"JAWS is very good for users, but it isn't the best for testing, in the sense that it papers over the cracks a lot."

"If you can see colour and you can't see colour, everyone's got the same experience. It's just a terrible experience."

"Often we just sit in Figma and come up with all these whizzy designs and then throw them over the wall at the developer."

"You can write about thirty lines of code and you can make a div behave almost like a button, or you could have just used a button element in the first place."

"That's not how I see people using AI. They're just vibe coding."

"WCAG is supposed to be the base level. It's not supposed to be the finish line."

🎯 Also in this Episode

• How our team gates mobile releases on accessibility testing, and why blocking a release is the guardrail that makes the rest work
• The DWP Accessibility Manual, built unofficially by a handful of people and then adopted because it was already in use
• Why he'd never recommend learning accessibility by reading WCAG directly — it's hard to understand and harder to piece together
• Our shared nostalgia for the era of checking browser and locale splits before designing, and what the industry lost to Chrome's dominance
• The privacy reasoning behind not surfacing assistive technology in analytics, including the health insurance premium scenario
• Why design system teams shipping ten variants of a button to satisfy ten designers are making the problem worse
• Meta's camera glasses as a real accessibility win and a real societal problem at the same time
• Accessibility conferences worth knowing: axe-con from Deque, Access Ginger in the UK, and CSUN in the States — plus accessibility talks now creeping into general conferences like JSHeroes

Resources

More from Craig and the tools mentioned:

• TetraLogical — Where Craig works as Principal Accessibility Specialist
• DWP Accessibility Manual — The open sourced manual built at the Department for Work and Pensions
• GOV.UK accessibility guidance — Referenced throughout as a solid public reference
• axe, WAVE and ARC Toolkit — Automated checkers to run in CI, catching around 40% of issues
• Guidepup — Drives real screen readers from your test suite
• Playwright, Selenium and WebDriver with Cucumber/Gherkin — For accessibility acceptance tests
• Genymotion and UTM — Free routes to TalkBack, NVDA and JAWS without dedicated hardware
• BrowserStack — Hosted screen reader testing environments
• W3C cognitive accessibility guidance — The AAA gap for neurodivergent users
• Global Accessibility Awareness Day — Held in May, and often your only budget window
• axe-con, Access Ginger and CSUN — Accessibility-focused conferences

Books mentioned:

• Design Justice — Covers accessibility alongside other protected characteristics we should be designing for

🎧 Listen Now

🎧 Spotify
📺 YouTube
🍏 Apple Podcasts

Episode Length: 59 minutes on building an accessibility practice from nothing, the three C's, screen reader testing without the licence fees, what belongs in your pipeline, why compliant isn't usable, and the AAA criteria nobody is required to meet.

Whether you're the only person in your organisation who cares about this, or you've just been handed an audit report full of green ticks, this one is about making accessibility outlast whoever is currently carrying it.

Happy testing,
Dan