Chris Gibbons - Journal

You've Made a Start. Then What?

2026-04-27T00:00:00Z

The audit closes. The findings get logged. Tickets get raised, some of them get fixed, and the organisation moves on with a slightly shorter list of accessibility issues than it had before. Six months later, most of those findings will be back. Different components, sometimes, but the same patterns. The next audit will produce a list that overlaps with the last one in ways nobody’s surprised by anymore.

This is the part of accessibility work that doesn’t get written about much. Not because it isn’t happening, but because it isn’t dramatic. The failure mode isn’t a designer who removed a focus outline or an engineer who didn’t understand semantic HTML. Those are the public-facing failure modes. The quieter one is what happens after the audit, when the people who care about accessibility try to make the fixes hold.

The pattern after the audit

I’ve watched this play out in three organisations now and it’s the same shape every time.

Audit lands. Findings get triaged. The big ones get assigned to teams who have a fortnight to fix them before the report goes out to whoever commissioned it. The small ones get added to a backlog where they sit indefinitely, occasionally getting picked up when someone has spare capacity and remembers them. The middle ones get fixed in the components that were audited and not fixed in the components that weren’t, because nobody’s job is to extend the fix laterally.

Six months pass. New features ship. Old components get extended. The components that were fixed get touched by engineers who weren’t around when they were fixed, and the fixes erode because the engineer doesn’t know what the fix was for. New components get built that repeat the same patterns the audit just flagged, because the audit findings never made it into the documentation, the linting, the code review checklist, or the engineer’s working knowledge.

Audit number two is commissioned. The findings overlap with audit number one’s findings in ways that, if you stared at them long enough, would tell you something specific about what went wrong. Mostly nobody stares at them long enough. The fixes get re-raised. The cycle continues.

This isn’t anyone’s fault, exactly. It’s what happens when you treat accessibility as a project that has an end.

A maintenance problem in disguise

The disciplines that figured this out years ago are security and performance. Both started as exceptional concerns: things you brought in a specialist for, audited periodically, fixed with a project, and considered done. Both eventually got reframed as ongoing engineering work, because the field collectively realised that anything you treat as a one-off audit will regress.

Security has SAST scanners in CI. Dependency vulnerability checks. Threat modelling baked into design review. A security champion in every team. A platform team that owns the standards and the tooling. Performance has lighthouse budgets, RUM telemetry, regression alerts, performance reviews of new features before they ship. Both have role definitions, certifications, recognised career paths.

Accessibility is, in most organisations, still where security was in 2008 and performance was in 2012. Audited periodically. Fixed in batches. Owned by nobody specifically. Considered solved when the report comes back clean, even though the report is a snapshot of one moment in a system that changes every day.

The maintenance frame matters because it changes what good looks like. If accessibility is a project, success is ‘no findings in this audit’. If accessibility is a maintenance discipline, success is ‘we caught the regression in PR review, before it shipped’. Those are different problems with different infrastructure. The first one needs an audit budget. The second one needs people, process, and tooling that lives in the development cycle.

Most organisations are still buying audits and wondering why the findings come back.

The role nobody quite owns

Here’s the structural thing that nothing else fixes.

Accessibility, in most organisations, is everyone’s responsibility. Which means it’s nobody’s job. The designer is supposed to consider it. The engineer is supposed to implement it. The QA is supposed to test it. The product manager is supposed to prioritise it. The accessibility champion in the team is supposed to advocate for it, in the time they have left over after their actual job. There’s no individual whose performance review depends on whether accessibility holds.

When something is everyone’s responsibility, the failure mode is predictable. It becomes the responsibility of whoever cares most, which means the work falls on the same two or three people across the organisation, who burn out or leave. Their replacements don’t pick it up because there’s no role definition saying they should. The institutional knowledge walks out the door with the person who built it.

The fix is unglamorous: name the role, give it real authority, fund it. Not ‘accessibility champion’. That’s the volunteer pattern that creates the burnout. A specialist, full-time or close to it, whose remit is the standards, the tooling, the review, the training, the audit response, the regression prevention. The person whose job depends on whether accessibility holds.

A few organisations have figured this out. Most haven’t. The ones that have tend to be the same ones that get accessibility right structurally. They’ve made it someone’s job, given them backing, and held them accountable for the outcome. The rest run on volunteer enthusiasm until the volunteers run out.

What sustaining it actually looks like from inside

It’s the PR comment on a colleague’s branch flagging that the new modal doesn’t manage focus, written carefully because you don’t want to be the person who makes accessibility feel like nagging. It’s the design review where you ask, again, whether the new colour token meets contrast, knowing the designer has been asked this before. It’s the documentation page you wrote that nobody reads, but that you maintain anyway because the day someone needs it they’ll need it badly.

It’s the audit response document that takes two weeks to write properly because you’re not just listing fixes, you’re trying to capture why the patterns appeared in the first place so the next round of new components doesn’t repeat them. It’s the conversation with the engineering manager about why the linting rule that catches missing alt text needs to fail builds rather than warn, and the follow-up six weeks later when it gets reverted because it slowed down a sprint. It’s the slow, repeated argument that the accessibility statement on the website isn’t a marketing asset, it’s a legal commitment, and the practice needs to match the wording.

It’s noticing that the new junior engineer’s first PR has three accessibility issues, and choosing whether to flag them now or build the relationship first and flag them next time. Deciding, eventually, that you’ll always flag them, but you’ll do it in a way that teaches rather than corrects. Recognising that this calculation is your job, not theirs.

It’s the small win of someone, one day, asking the question before you’ve had to. The new designer who annotates focus order in the spec without being prompted. The engineer who pushes back in review on a colleague’s commit because the markup doesn’t carry through to the accessibility tree. These moments mean the foundations gap is closing somewhere. They are also rare enough that you remember them.

When it’s working, it looks like nothing’s happening. When it’s not working, the audit report tells you.

What this all adds up to

Accessibility holds in organisations that treat it as a maintenance discipline with a named owner, not a project with an end date. The technical work is genuinely the easier half. The harder half is structural: making it someone’s job, building it into the development cycle, treating regression as a problem you actively prevent rather than discover six months later.

Most organisations aren’t there yet. The ones that are tend to have got there because someone fought the case internally for long enough that the structure changed around them. That fight is part of the work, even when it doesn’t feel like it. The audit doesn’t sustain accessibility. The role does. The role doesn’t exist by default. Someone has to make the case for it, then keep making it.

If you’re the person inside an organisation trying to make this hold, the pattern is recognisable and it isn’t your fault. The system is designed to slowly absorb accessibility work into background hum until the next audit. Resisting that absorption is most of what sustained accessibility work actually is.

The first audit is a start. The role is the rest of the work.

What Good Actually Looks Like

2026-04-07T00:00:00Z

This series started with engineering. Then design. Then the organisations above both. Three failure modes, each one compounding the others. If the argument holds, the natural question is: does it ever not fail?

It does. But the conditions that make it work are harder to replicate than most people want to admit.

What it actually takes

The organisations that get accessibility right don’t tend to have a single thing in common. Not a tool, not a process, not a framework. What they share is a set of conditions that rarely arrive fully formed. They get built, usually slowly, usually by people operating without enough authority or resource, until enough of them are in place that the thing starts to hold.

It usually starts with a moment. A transformation, a structural decision, a piece of legislation that makes indifference harder to sustain. Something that creates enough space for accessibility to get a foothold. That moment alone isn’t sufficient (plenty of organisations have had the moment and squandered it) but without it, the conditions for change rarely materialise.

Then something has to give it structure. A design system with accessibility embedded from the start rather than retrofitted later. A champions network that spreads the thinking across teams rather than concentrating it in one person. A Centre of Excellence with enough authority to set standards and enough credibility to make them stick. These aren’t interchangeable. Different organisations need different structures. But the common thread is that accessibility needs somewhere to live that isn’t dependent on a single individual’s goodwill.

And underneath all of it, the organisations that sustain progress tend to serve people for whom accessibility isn’t optional. Older customers. Customers with disabilities. Customers for whom a broken journey isn’t an inconvenience but a barrier to something that matters. That’s not a coincidence. When the people your product excludes are the people your business depends on, accessibility stops being a compliance question and becomes something harder to defer. It doesn’t make the work easy. It makes the indifference harder to sustain.

What’s Still Not Working

None of that makes it solved. The organisations closest to getting it right are still dealing with the same failure modes as everyone else, just at a lower level, with less excuse for them.

The skills gap doesn’t close because an organisation has good values. Intent doesn’t equal depth. A team can care about accessibility and still not have the front-end knowledge to implement it well. That gap closes through hiring, through training that’s actually technical, and through giving people the time to develop craft they don’t yet have. That’s slow and expensive, and most organisations (even the good ones) don’t invest in it properly.

Discipline pushback is real at every level. Accessibility has a home in design-ops, in the Centre of Excellence, in the champions network. It doesn’t always have a home in product, in delivery, in the people deciding what’s in scope for the next sprint. The people who care about it are not always the people with the most power over what gets built. That gap doesn’t close through goodwill either.

And then there’s Phase 2. The politest way to deprioritise something indefinitely. Not a no. Just a later that never arrives. It happens in good organisations, on good teams, with people who genuinely believe they’ll come back to it. They don’t. The next sprint starts. The next deadline lands. Phase 2 is where good intentions go to die.

The three failure modes in this series (engineering, design, organisation) don’t disappear once an organisation gets accessibility on the agenda. They become lower-level problems. Harder to excuse, but still present. Still requiring active work to hold back.

What changes is the default. In an organisation that doesn’t value accessibility, the default is exclusion. It requires someone to fight for every inch of progress, usually without the authority to make it stick. In an organisation that does, the default shifts. Progress is still incomplete. The skills are still uneven. Phase 2 still happens. But the fight is smaller, and the wins are more likely to hold.

Accessibility doesn’t get solved. It gets embedded, slowly, imperfectly, by organisations that decided it mattered before they were required to, and by the people inside them who kept asking the question even when nobody was listening.

The Organisation That Never Prioritised It

2026-03-30T00:00:00Z

The first piece in this series was about engineering. The second was about design. But engineering doesn’t hire itself. Design leadership doesn’t set its own values in a vacuum. Both failures have a source. And the source is the organisation above them.

This is where the problem actually lives.

The Agency Problem

Start with agencies and consultancies, because the failure mode there is the most naked.

A client brief arrives. It has a budget, a timeline, a list of deliverables. It does not mention accessibility. The agency does not add it. Not because they’ve weighed it up and decided it’s out of scope. Because nobody in the room has the experience to know it should be there. Accessibility isn’t being deprioritised. It’s simply not part of how they think about the work.

That’s a skills problem dressed up as a process problem. And it runs deeper than a single project.

Because when a client does ask for it (and increasingly, under the European Accessibility Act, some of them are), the agency has a problem. There’s nobody in-house who can deliver it properly. No front-end engineer with genuine accessibility depth. No designer who knows the difference between annotating for accessibility and designing for it. What happens instead is a scramble: a subcontractor brought in late, an audit bolted on at the end, a compliance report produced by someone who ran a tool and called it done. The client asked the right question. The agency couldn’t answer it.

They ship something anyway. It goes live. The audit report goes in the appendix. The people who can’t use it never appear in the case study.

The Enterprise Problem

Then there’s the enterprise.

Different failure mode. Same outcome.

Large organisations don’t scope accessibility out. They bury it. Not in a single decision, but in the accumulated weight of process, governance, and the particular kind of leadership that gets rewarded for not changing things.

The thinking isn’t modern. It doesn’t need to be. Nobody has required it to be. Digital transformation arrived at these organisations as a phrase before it arrived as a reality, and in many of them it still hasn’t fully landed. There are people in decision-making positions at major organisations who genuinely do not understand what a screen reader is, why it matters, or that there are legal obligations around it. They have survived this long without knowing. The organisation rewarded them anyway.

Below them, accessibility teams exist. Sometimes. They produce guidelines. They run workshops. They write standards documents that nobody reads. They push from the bottom of the hierarchy and find, repeatedly, that the organisation above them is not structured to respond.

Because the process wasn’t built for it. Governance cycles that predate WCAG. Procurement frameworks that don’t assess for it. Sign-off chains where accessibility never appears as a criterion. You can have the most capable accessibility specialist in the country embedded in an enterprise and watch them achieve almost nothing, because the organisation they’re embedded in was never designed to act on what they find.

That’s what glacial looks like from the inside. Not stupidity. Structure. A set of processes and incentives and reporting lines built for a different era and never fundamentally questioned.

The engineer who doesn’t understand semantic HTML didn’t appear from nowhere. They were hired by an organisation that decided front-end specialism wasn’t worth the cost. The creative director who removed focus outlines didn’t operate in a vacuum. They worked in an organisation that never made accessibility a value: never put it in a brief, never raised it in a crit, never included it in what counted as excellent work.

The disciplines fail because the organisation permits the failure. Sometimes actively, by scoping it out. More often passively, by never requiring anything different.

When It Does Work

Some organisations are getting this right. Not many, but some. The ones that are tend to share a common trait: somebody at a senior enough level decided accessibility was non-negotiable, and built the conditions for that to be true. Not a workshop. Not a policy document. A sustained, structural commitment that changed what the organisation hired for, what it measured, what it rewarded.

That’s not a small thing. It requires leadership that understands what it’s committing to, and that’s rare in organisations where digital literacy thins out at the senior levels.

For the majority (the agencies still leaving it out of scope, the enterprises still running governance processes designed for a pre-digital world) the EAA provided a legal nudge. Some of them will respond to that nudge. More of them will find the minimum viable compliance response and treat the problem as solved.

It isn’t solved. It’s documented.

An accessibility statement in the footer and a completed audit checklist do not make a product accessible. They make it defensible. That distinction has run through this series from the start. But it starts here, at the organisational level, before a brief is written, before a designer opens Figma, before an engineer writes a line of code.

The organisation that never prioritised accessibility will not produce accessible products. Not through any individual failure of the people inside it, but because the system was never built to. And systems produce what they’re designed to produce.

Unless someone inside decides to build differently anyway. Designers who ask the question the brief didn’t ask. Engineers who fix what wasn’t required. Accessibility specialists who refuse to let the governance cycle be the last word. They’re not fixing the system. But they’re doing the work anyway: side of desk, under the radar, between the things the organisation actually asked for. That matters. It’s just not a substitute for the organisation doing its job.

The Design Brief That Never Mentioned Disabled People

2026-03-26T00:00:00Z

Someone once told me that focus outlines were ugly. Not a junior designer finding their feet. A senior creative director. Decades of experience and a large portfolio. No idea that removing them made the interface unusable for keyboard users.

That’s not ignorance from the early web. That’s sadly more recent.

Accessibility has always had a design problem.

In the Flash era it was obvious. Entire interfaces built in a plugin that screen readers couldn’t touch, keyboard navigation that simply didn’t exist, content locked behind technology that prioritised spectacle over substance. It was a different time, and the web was still finding itself. That’s the generous read.

The less generous read is that nobody asked the question. Not the designers, not the creative directors, not the clients signing off the work. The people who couldn’t use those interfaces weren’t in the room, weren’t in the research, and weren’t in the budget.

The tools changed. The attitude largely didn’t.

Flat design brought its own failures. Low contrast text because it looked elegant. Placeholder text used as labels because it looked clean. Interactive elements with no visible affordance because someone decided that was sophisticated. Each of those is a design decision. Each of those excludes someone.

The pattern isn’t ignorance of the technology. It’s indifference to the consequence. Designers making aesthetic calls without asking who pays for them.

The Authority Problem

The focus outline gets removed. The contrast ratio gets overridden. The interaction pattern gets simplified in a way that breaks keyboard navigation. And the designer who made that call never finds out.

That’s the authority problem.

Design decisions carry weight precisely because they come from people with the seniority to make them stick. A junior engineer pushing back on a focus outline removal is easily dismissed. A creative director’s sign-off is final. The hierarchy that gives design leadership its influence is the same hierarchy that insulates it from accountability.

And the industry has built a perfect mechanism for reinforcing that insulation: awards.

An interface that looks stunning in a judging panel screenshot wins. The contrast ratio that fails in direct sunlight on a cheap Android handset doesn’t get flagged in the submission. The interaction pattern that breaks for a keyboard user doesn’t feature in the case study video. The award gets framed. The work gets into the portfolio. The designer moves on, reputation intact, consequences unexamined.

Meanwhile, somewhere, a person with low vision is squinting at text that was made light grey because it looked more refined. A keyboard user is trapped in a modal with no way out because focus management wasn’t considered a design problem. A screen reader user is navigating a carousel that announces nothing useful because the visual elegance was the only brief that mattered.

These aren’t hypothetical edge cases. They’re people. People trying to book a GP appointment, check a bank balance, apply for a job. Tasks the rest of us complete without thinking. Tasks that become obstacles (or impossibilities) when the person who designed the interface never had to consider them.

The consequences are real. They’re just invisible to the people who caused them. And visibility is what drives change.

The Culture Problem

I’ve worked under design leaders who didn’t get it. Not junior designers finding their feet. Senior people. Experienced. Decorated. Indifferent.

Not hostile to accessibility. Something more corrosive than that. Indifferent to it. Dressed up as pragmatism.

Accessibility didn’t win pitches. It didn’t feature in award submissions. It didn’t show up in the metrics that mattered. So it didn’t exist.

That attitude sets the culture for everyone beneath it. When a creative director doesn’t ask the question, the team stops asking too. When accessibility never appears in a brief, never gets raised in a crit, never factors into a decision, it becomes invisible. Not banned. Just absent. And absent long enough that nobody notices it’s missing.

This is how design culture fails at the top. Not through active opposition but through the slow normalisation of indifference. The things a design leader values get resourced, debated, refined. The things they don’t get quietly dropped from the conversation until they stop being a conversation at all.

And the industry built the perfect conditions for this. Decades of design culture organised around visual craft, commercial impact, and peer recognition. Awards that judge on aesthetics. Portfolios that showcase beauty. Briefs that don’t mention the people who might not be able to use what gets built. A generation of design leaders who are genuinely excellent at what they were trained to value, and genuinely indifferent to what they weren’t.

That indifference has a cost. It just gets paid by someone else.

The Fix

The fix isn’t a checklist. It isn’t an audit. It isn’t hiring one person to care about accessibility so nobody else has to.

It’s design leadership that considers accessibility a core value, not a compliance requirement, not a nice-to-have, not a phase-two priority. A value. Something that shapes briefs, informs crits, features in portfolio work, and gets asked about in interviews.

That starts with education, but not the kind that gets scheduled as a one-off workshop and forgotten by the following sprint. The kind that changes how a design leader asks questions. Does this work for someone who can’t see it? Can someone navigate this without a mouse? Does this make sense without the visual context? Those questions have to come from the top before they become normal anywhere else.

It starts with briefs that include accessibility requirements from the first line, not appended as an afterthought after the creative direction is already set. An inaccessible design direction is expensive to fix in code. It’s cheap to fix before a single pixel has been placed.

It starts with the industry recognising that the things it rewards shape the things it values. Awards that don’t consider accessibility are telling an entire generation of designers that accessibility doesn’t count. That’s a choice. It could be a different one.

And it starts with honesty about what seniority actually means. Twenty years of experience building things people can’t use isn’t twenty years of expertise. It’s twenty years of an incomplete brief, executed well.

The Accessibility Problem Isn't Design. It's Engineering.

2026-03-23T00:00:00Z

The European Accessibility Act came into force on 28 June 2025. Teams audited their components, ran Axe, added ARIA attributes, and ticked boxes. Compliance documents were written. Statements were published in footers. And then most of them moved on.

Nine months later, it’s worth asking what actually changed.

Accessibility isn’t a design problem with a checklist solution. It never was. The specs were written, the components annotated, the guidelines documented. And then engineering shipped something broken anyway. The design was right. The code wasn’t. It’s the same story on almost every team, in almost every organisation, repeated endlessly while the industry pretends the problem is about awareness.

It isn’t about awareness. It’s about who’s writing the front-end code, and whether they’re qualified to write it.

Somewhere in most organisations there is a designer who cares about accessibility. They annotate their components. They specify focus states, label associations, heading structures. They do the work.

And then engineering builds something else entirely.

Not out of malice. Out of a fundamental skills gap that the industry created, normalised, and is now actively accelerating.

The full-stack engineer has become the default hire. One person, one salary, covering the database, the API, the back-end logic, and the front-end interface. Efficient on paper. Straightforward to justify in a headcount meeting. And quietly catastrophic for the quality of what gets built.

Because front-end isn’t a layer. It’s a specialism. Semantic HTML, document structure, keyboard interaction, ARIA, the relationship between visual design and accessible implementation: these aren’t things you absorb by proximity or pick up in an afternoon. They require years of focused attention. They require someone whose job it is to care about them, not someone who gets to them after the back-end is done.

The full-stack engineer doesn’t have that depth. They can’t. They’re stretched across too many concerns, context-switching too frequently, and operating in a discipline they were never trained in. The front-end work gets done last, under time pressure, by someone who fundamentally doesn’t understand what makes it hard. The result is exactly what you’d expect: div soup where semantic elements should be, heading structures that skip levels or don’t exist, interactive elements with no keyboard support, ARIA attributes cargo-culted from a Stack Overflow answer by someone who had no idea what they were doing.

This isn’t an edge case. It’s the norm. And the industry built it deliberately in pursuit of cheaper, leaner teams.

The audit finds it eventually. But by then, real people have already been excluded.

The Accelerant

Now add AI to that picture.

Copilot doesn’t know your design system. It doesn’t know your component architecture, your token structure, or the accessibility decisions baked into your foundations. It has no context for any of it. What it does have is a vast dataset of code (including a vast dataset of inaccessible code) and the ability to generate confident, plausible-looking output faster than anyone can meaningfully review it.

For an engineer who understands front-end, that’s a powerful tool. They can evaluate the output critically. They know when it’s wrong, why it’s wrong, and how to correct it. The tool amplifies existing expertise. It makes good engineers faster.

That is not what is happening on most teams.

For an engineer without front-end foundations, Copilot isn’t a productivity tool. It’s a mechanism for generating broken code at scale with complete confidence. The output looks clean. It passes a cursory review conducted by someone with exactly the same blind spots. Nobody in the chain (not the engineer, not the reviewer, not the lead who approved the PR) has the knowledge to see the problem. So it ships. And because it arrived quickly and looked professional, nobody questions it.

This is what makes the current moment so dangerous. It was always possible for an under-qualified engineer to write inaccessible front-end. But there were limits. It took time. The gaps were sometimes visible. Somebody occasionally noticed.

AI removes every one of those friction points. It produces more broken code, faster, at greater scale, with more conviction than any engineer could manage alone. The interface fails a screen reader user. The keyboard trap goes unnoticed. The heading structure is a disaster. And the team that shipped it is proud of how quickly they moved.

Automated accessibility tooling catches around 30 percent of issues, according to research by the UK Government Digital Service. The rest require human judgment: someone with the craft knowledge to find what the tools can’t see. When that person isn’t on the team, the other 70 percent stays broken indefinitely. Copilot won’t find it. Axe won’t find it. A real user will.

And a real user just did.

The Wrong Fix

Here is the uncomfortable truth about the European Accessibility Act. Compliance with it is not the same as being accessible. Not even close.

WCAG 2.2 AA is a floor. A low one. It’s a set of technical criteria that can be audited, documented, and signed off by a legal team that has never used a screen reader. It says nothing about whether a real person, with a real disability, using real assistive technology, can actually complete a journey through your product with any degree of dignity or independence. You can pass every single checkpoint and still build something that excludes the people it’s supposed to serve.

That is precisely what the checklist mentality produces. Not accessible products. Defensible ones. A compliance statement in the footer. A report that satisfies procurement. A document that keeps legal quiet until the next audit cycle. The minimum viable defence, dressed up as progress.

Inclusion asks different questions entirely. Not “does this pass?” but “can someone who relies on a screen reader complete this journey without hitting a wall?” Not “is this labelled?” but “does this label make sense in context to someone who can’t see the visual relationship?” Not “did we run Axe?” but “did we test with a real person, and did we listen to what they told us?”

Those questions can’t be answered by a tool. They can’t be answered by a designer working in Figma. They can’t be answered by a compliance report. They can only be answered by someone with the front-end depth to understand how the implementation behaves in the real world, across real devices, with real assistive technology.

Compliance is what you get when you treat accessibility as a legal problem. Inclusion is what you get when you treat it as an engineering one. The industry has spent years optimising for the former and wondering why the latter remains out of reach.

The Fix

So what does the fix look like?

It starts with the industry being honest about what it has done. It stripped out front-end specialists in favour of cheaper generalists, told itself that full-stack was the future, and is now surprised that the front-end is broken. That’s not bad luck. That’s a predictable consequence of a deliberate decision. Fixing it requires acknowledging that the decision was wrong.

It means treating front-end as a specialism again. Hiring people who have that depth. People who understand semantic HTML not because they looked it up last week, but because they’ve spent years understanding why it matters and what breaks without it. People who can look at a component and know (before the audit, before the user research, before the complaint lands) where it’s going to fail and why.

It means not outsourcing that judgment to a tool. AI can help. Automated testing can help. But neither can substitute for craft knowledge. The tools are only as useful as the person interpreting their output, and right now, on most teams, that person doesn’t exist.

The European Accessibility Act didn’t create this problem. It just made it legally uncomfortable to keep ignoring it. Teams that respond by ticking boxes will keep producing accessible-on-paper, broken-in-practice interfaces, and will keep being surprised when real users can’t use them. Teams that respond by treating accessibility as an engineering discipline (one that requires genuine front-end expertise, embedded in the process from the start, not audited in at the end) will build something worth using.

That’s the difference. It was always the difference. And no amount of AI-generated code, automated tooling, or compliance documentation will close that gap until the industry stops pretending that front-end is a layer anyone can handle.

It isn’t. It never was.

2025 — That's a Wrap

2025-12-12T13:59:50Z

I nearly didn’t publish this. Not because it felt untrue, but because it felt inconvenient. And I’m increasingly wary of the instinct to keep the inconvenient bits private while polishing everything else.

2025 resists summary. It wasn’t marked by a single turning point, but by accumulation: repeated pressures, ongoing adjustments, and a widening gap between what was expected and what was actually supported. That gap matters.

The hard yards

It was a hard year, not in a dramatic, headline way, but in a grinding one. The kind of hard that settles into your shoulders, your sleep, your patience. A year that kept asking for more focus, more resilience, more output, while quietly removing the conditions that make any of that sustainable.

Pay is part of this story, and pretending otherwise is dishonest. Flat pay alongside rising expectations doesn’t just bruise morale. It creates burnout that is physical, mental, and financial.

Physically, it showed up as exhaustion that sleep didn’t fix, tension carried day after day, and a baseline fatigue that became normalised.

Mentally, it meant carrying more context, more responsibility, and more risk, with less slack and less certainty.

Financially, it meant absorbing all of that in a cost-of-living landscape that kept rising regardless, where food, energy, travel, and childcare don’t politely stay flat just because pay does.

Layered onto that were commute days: twice a week, with around three hours of travel each way. Six hours spent getting to and from work, on top of a full working day, turning those days into thirteen-hour stretches that start early and end late. They’re often dismissed because they’re ‘only’ a couple of days a week, framed as a personal choice. And yes, I chose it: because I had to. Because survival sometimes looks like trade-offs that aren’t really choices at all. The cost of those days wasn’t abstract. It was paid in energy, attention, and the narrowing space left for recovery.

Add to that more time in the office being framed as ‘culture’, and the picture sharpens further. Less flexibility. Less room to recover. Less acknowledgement of the cumulative cost. The unspoken expectation was clear enough: work comes first, and everything else needs to adapt around it.

That was the point where I stopped treating time with my partner and our kids as something that merely helped me cope, and started treating it as something I was actively unwilling to sacrifice. Ordinary moments (shared meals, school runs, walks that went nowhere in particular) stopped being ‘nice to have’ and became essential. Not sentimental. Structural.

My partner carried more than her fair share at times, with a steadiness I don’t take lightly. The kids, blissfully uninterested in any of this, kept pulling me back into the present: into noise, questions, silliness, joy. They didn’t need me to be productive or composed. They just needed me there. And honestly, that was a relief.

That grounding didn’t make the year easier. But it made my priorities impossible to ignore.

Professionally, 2025 stripped away any remaining tolerance I had for pretending that care, accessibility, and sustainability are optional extras. They’re not. They’re foundational. When organisations treat them as negotiable (when they ask people to do more with less, indefinitely) the cost doesn’t vanish. It lands somewhere. Usually on the people least able to push back.

I’m done translating those values into something quieter or more convenient. Accessibility isn’t a bolt-on. Sustainability isn’t a vibe. People aren’t abstractions. If a system only works when everyone overextends, it’s not a good system.

Writing has been part of how I’ve processed all of this. Not hot takes. Not neat conclusions. Just notes from the edges, trying to understand how power, language, and responsibility actually play out in practice. Writing as a way of staying honest, rather than agreeable.

If 2025 took a lot out of me, it also clarified things.

So, what next

Going into 2026, I’m far less interested in momentum for its own sake. Fewer projects, chosen properly. Work that’s well-supported, thoughtfully paced, built to last, with people who don’t confuse pressure with performance, and who understand that paying people properly is part of sustainability. Full stop.

On a personal level, I’m protecting what kept me intact this year. Time with my family that doesn’t get squeezed into the edges. Rest that doesn’t need a productivity justification. Space to notice the small, grounding moments. Because they aren’t small at all. They’re the point.

I don’t expect 2026 to be easier. But I do expect to meet it with clearer boundaries, less tolerance for nonsense, and a firmer grip on what I’m willing to give. And what I’m not.

Why I Write

2025-01-06T00:00:00Z

Writing is how I figure out what I actually think.

That’s it, really. Everything else (the essays, the technical pieces, the short scrappy fieldnotes) comes from that one thing.

I’ve had ideas that felt solid for months. Turned them over, stress-tested them in my head, felt pretty confident. Then tried to write them down and found the gaps immediately. The writing doesn’t just capture the thought. It finishes it. Sometimes it kills it. Both are useful.

This site is where that happens in public.

Some of what’s here takes a long time and makes arguments I’ll stand behind. Some of it is technical: practical, specific, close to the work. Some of it is short and half-formed, and that’s deliberate. Not everything needs to resolve. The fieldnotes especially: they’re thoughts before they’ve hardened into opinions. A thinking space more than a publishing platform.

It’s not a content strategy. There’s no posting schedule I’m going to pretend to stick to. I’m not building a brand. I’m a front-end developer who cares about craft, about how the industry works and why it often doesn’t, and about building things that last. That’s what you’ll find here.

If something’s useful, good. If it makes you think differently about something, even better.

But mostly I write because not writing makes the thinking worse. This is the fix for that.

2024 — That's a Wrap

2024-12-12T00:00:00Z

Another year, another exhausted reflection post typed at 11pm before the Christmas break. But it was a good one. Let’s dig in.

After everything 2023 threw at me (the redundancy, the job market grind, the mental health wobbles) I went into 2024 quietly desperate for it to be boring. Not uneventful. Just stable. The kind of year where you can actually do the work rather than just survive it.

It was mostly that. Which, given where I’d been twelve months earlier, felt enormous.

The new role

The biggest thing this year was moving from AND Digital to Royal London as Lead Front-End Design Engineer. AND Digital was a decent landing pad when I needed one, but Royal London is where I actually wanted to be: the kind of role that had been on my radar for a while. Design system architecture at scale, accessibility as a genuine quality baseline rather than a compliance checkbox, and problems that are actually interesting to solve.

The first six months were deliberately slow. Not slow as in unproductive, but slow as in deliberate. Understanding how things actually work before trying to change them. Building trust before building things. Mapping the landscape: the existing token structure, the component library, the gap between what the design system claimed to be and what teams were actually using day to day. That gap, as ever, was instructive.

The second half of the year started to feel like it had some momentum to it. The token architecture work in particular (working through the naming conventions, the semantic layer, the Figma-to-code pipeline) is the kind of problem I’ll happily spend a lot of time on. It’s where design decisions become engineering decisions, and vice versa, and getting that boundary right matters enormously.

I won’t pretend it’s been without its moments of imposter syndrome. Joining a bigger organisation, in a more senior position, after a year that knocked my confidence around a fair bit: there were days where the gap between what I knew I could do and what I felt capable of doing was genuinely uncomfortable. I’m mentioning this not for sympathy, but because I think it’s more common than people admit, and pretending otherwise doesn’t help anyone.

It settled. It usually does.

Community & speaking

I spoke at a couple of events this year. Still terrifying every time. Still absolutely worth it. If you’re sitting on something worth saying and talking yourself out of sharing it, don’t. The web could do with more people willing to think out loud.

What I’m taking into 2025

The Royal London work is the main thread. The foundations are in: now it’s about shipping, and about making sure the system actually gets used rather than just existing. Adoption is a harder problem than architecture, and I’m increasingly interested in it.

I want to write more. I keep saying this. I mean it with varying degrees of commitment depending on the week. But the writing I’ve managed this year (the handful of proper pieces that actually got published) reminded me why I do it. Writing is how I figure out what I actually think, and I’d like to do more of it.

Here’s to a 2025 with fewer divs and more <main> elements.

Thank Fuck '23 is Nearly Over

2023-12-01T00:00:00Z

It is safe to say that 2023 will hardly go down in the annals of history as a classic. Redundancy, a bruising job market, and some unwelcome mental health passengers made sure of that. But it ended better than it started, which is more than could be said a few months in.

January started with so much promise

It didn’t, really.

Work was tough from the off. Everyone was dealing with the fallout of a disastrous re-org the previous year, and the cracks were showing. On a personal level, it gave me space to start asking some questions I’d been avoiding: what do I actually want to be doing, and how do I get the spark back? I wrote a lot of notes. More on those later.

Then, in the kind of timing only the universe can manage, a routine couch-to-5k session ended with a torn meniscus and a stress fracture of the tibia. Private healthcare through work meant I could get it sorted relatively quickly, which, as the year unfolded, turned out to matter more than I knew at the time.

Easter bombshell

The redundancy news dropped the day before Easter. How’s that for a send-off? Enjoy the long weekend. My contract was terminated over the summer.

Losing the job itself wasn’t the worst of it: companies overextend and correct, I’ve seen it before. What stuck was the manner of it. Scripted, emotionless, delivered right before a bank holiday weekend. A masterclass in how not to treat people.

The job hunt that followed was grim. I’ve written about it in more detail in post-redundancy thoughts: the recruiter ghosting, the live coding sessions, the boilerplate rejections, the market that seemed to have quietly decided that front-end expertise wasn’t what it was looking for. If you’re curious, it’s all there.

In August I landed a position as Tech Principal at AND Digital. The pressure lifted. I was back.

The unwelcome return

And then, just as things stabilised, the mental health stuff came back hard.

Anyone who knows me knows I’m neurodivergent and carry anxiety, depression, and an eating disorder. I mention it openly, not for sympathy, but because pretending it doesn’t exist helps no one. Most of the time it’s managed, one way or another. This year it wasn’t, for a while.

I’d come off fluoxetine too quickly the previous year. In hindsight, obviously. At the time it felt like progress. I’m back on it now, and less in a rush to treat stability as something to be fixed.

Plans for 2024

Those notes from January (the ones I wrote when work was bad and I was trying to figure out what I actually wanted) turned out to be useful. They pointed towards some things I already knew but hadn’t been honest with myself about: I want to do proper front-end work, the good kind, HTML and CSS and accessibility and design systems. I want to mentor people. I want to write more, speak more, and work with people who give a damn.

The design technologist direction (sitting properly between design and engineering rather than apologising for being at the boundary) felt right then and still does.

As it turned out: most of it happened. The Royal London move in 2024 put me in a role that matched almost everything on that list. The writing is still a work in progress. Some things take longer.

2023 was a year I won’t be rushing to revisit. But the clarity it produced (about what I want, what I won’t put up with, and what actually matters) was worth something.

Onwards to '24.

Post-Redundancy Thoughts

2023-10-10T00:00:00Z

A random, ranty, sweary collection of thoughts and feelings that I captured at various points across my redundancy journey.

Most of what I’ve noted down can be classified into one of the following: keeping motivation, keeping focus, keeping busy, keeping fresh, and keeping sane.

So, in no particular order…

Market conditions are tough, absolutely no question about that, and arguably tougher than I’ve seen them in most of my career, but that’s no excuse for some of the arcane practices I’ve seen.
Interviews are far, far more convoluted than they should be. When things get to 4–5 stages, you really need to question what on earth you are doing.
Don’t even get me started on tech tests.
Feedback, or lack of. Ghosting. Seriously. This one really fucked me off: we’re not on fucking Tinder here, we’re talking about a person’s livelihood, and you can’t even be arsed to send a fucking automated rejection. Absolute bullshit.
The phrase “hit the ground running”. Fuck off. A huge misnomer, and in hindsight, a massive red flag.
Related: “we need someone who can code.” I might be a tad rusty and I might not know all the ins and outs of TypeScript, but I’m not going to forget 15+ years of solid FE engineering overnight. It’s annoying and disconcerting when this type of comment is coming from Heads of Engineering.
Picture the scene: you ace the first few stages of a process, and get told as much via the hiring manager. You score very highly on leadership and values. Confidence is good, not cocky, but certainly not low. You go into a pair-programming test and see that there are three other people on the call.

You do the hour-long test, riddled with nerves; you get most things working. The test wasn’t perfect, but you had an hour, and for brevity you use any on some TypeScript types to get things working.

Feedback eventually comes back: you’ve not made it through. Down to the use of any and a test not mocking something correctly.

In a one-hour tech test, with three people on the call (one leading, one pairing, and one who I still don’t know what the fuck he was doing there) they deemed me not good enough and discarded all the previous positive feedback. I gave some pretty scathing feedback in return. I felt it was unfair and unjust. Still do.

So why am I writing this?

Because along the way, over those six months, all of the folks involved introduced fear, doubt, and anxiety into my life, ranking me on a small window of opportunity, in a very opaque and often outdated and drawn-out process.

And before you think “wow, how cocky is Chris”, let’s be fair: it’s absolutely both parties. I’m not without blame and not infallible in all this. Letting skills lapse due to leadership roles, maybe not prepping enough. Fair. But interviewers and businesses are equally, if not slightly more, to blame.

Unrealistic expectations in a very short amount of time. Not taking a person’s history and complete experience into account. Inexperienced interviewers. And probably the biggest one: not looking at the complete interview picture across all stages.

It's Good to Talk

2022-04-04T00:00:00Z

The following post is an update of something I first wrote back in 2016 for my personal blog but never shared. I’ve updated the content to reflect on what’s happened over the last few years on both a global and personal scale.

The content is very personal to me and a little bit meandering at times. But I’m sharing this in the hope that there are some lessons in there for everyone, or even just for someone.

If this does trigger somebody, or if anyone wants to chat to discuss experiences that may correlate with your own, then feel free to get in touch without prejudice. I’m not an expert, but I’m happy to listen and point in the direction of what’s helped me.

Bluesky: @gbbns.co
Email: chris@gbbns.co

Motivation. When it’s not there, life is tough. Everything is a struggle. Things you once enjoyed start to become a chore. Sound familiar to anyone?

Several years ago I hit this very problem, and it’s taken until now for me to speak up about it.

I (Nearly) Realised, But Never Followed It Up

In 2014 I’d hit an all-time low with ‘the internet’, to the point where I was ready to completely jack it all in and change my career. I even attended uni open days.

I don’t know when, or what, triggered this. But looking back it was a combination of many things that all came together and hit me hard. It was a worrying feeling, especially as I didn’t truly understand why.

The ‘eureka’ moment came during a session — “Burnout Is Real And It’s Coming To Get You” — at DDD North. The content struck a chord and resonated with some of the issues I’d been facing.

I remember being sat next to a few developers on the day who were cynical about the whole thing. It’s easy to judge folk when you’re not in that situation, but the lack of empathy shown was shocking.

On the train back home I started to think about what Richard had talked about, and then for the first time in what seemed like an age I got my notebook out and started to scribble notes down.

I realise now that this was the start (or at least what I thought was the start) of the long road out of the dip I was in. It helped to get things out of my head, to see them in a physical form, and to remove the noise from my thoughts.

Now, Let’s Fast Forward a Few Years

2019 was the start of the latest chapter in my story and it began in a pretty innocuous manner. I’d damaged my knee moving some Christmas decorations and had an appointment to see what I’d done.

As I sat in the car I felt anxious. I was trying to psyche myself up to tell the doctor a secret that I’d kept locked away from everyone for nearly 20 years.

The following timeline isn’t a direct comparison to 2014: it’s more a potted history of exactly what, and how much, has happened over the last few years.

2019 — Eating disorder diagnosis and Cognitive Behavioural Therapy (CBT)

I realise that is quite the sentence. The eating disorder is the thing I was psyching myself up to tell the doctor about. And do you want to know a secret? I nearly didn’t mention it. I spoke to the doctor about my knee, and had the doctor not ended by asking “Is there something else bothering you?” then I would probably have walked out and continued as if nothing was wrong.

2020 — Lockdown, big change in personal circumstances, moved jobs

2021 — New house, temporary mental respite, cycling, new job (again), then Christmas: this is where things really started to nosedive

2022 — Breakdown, counselling, eating disorder relapse, the realisation that I did actually need help and support

Next Steps?

Wow. If you’re still here reading, you might be wondering what the point of this post is.

It’s certainly not some narcissistic woe-is-me post. It’s one I’m very passionate about, and that’s mental health: being open about it where possible.

Taking that first step is hard. But it’s an important step to take. It’s hard because you’re aware you want, or need, to change, but you’re scared and anxious about the journey ahead. Me of 2014 never fully realised this, never spoke to anyone, and ultimately never fully healed.

One of the quotes that’s helped at various stages along my journey:

“You don’t have to see the whole staircase — just take the first step.”

I’m nearing the end of my counselling sessions and can’t rate them enough. This experience might not be shared by everyone, and if not, the advice I was given by a friend was to ask for a different counsellor.

The sessions have directly led me to seek out more specialist advice and treatment, but I’ll save that story for another time.

Also, I want to go back to the simple question the doctor asked me: “Is there something else bothering you?”

This is something that every single one of us can ask a friend or colleague if we think something isn’t quite right. You might not get the right answer there and then, but from my experience, the fact that someone has asked will mean the world.

I’m lucky in that I’ve had an amazingly supportive line manager who regularly chats and checks in with me, as well as colleagues who have noticed when something wasn’t right and sent a private message to check in. Let me tell you: it felt incredible.

And so it goes back to the title of the post — “It’s good to talk”.

Watch the original BT “It’s good to talk” ad on YouTube

Dealing with Rejection

2016-07-12T00:00:00Z

“A rejection is nothing more than a necessary step in the pursuit of success.” — Bo Bennett

Twice in the space of four weeks, I found myself on the wrong end of a decision I’d been hoping would go the other way. I’m not going to go into the specifics: that’s not the point. The point is what happened in the hours and days after.

I want to write this down. Partly as a permanent reminder to myself, partly because someone else might find it useful.

When the call came, I knew from the first few words. The full range hit at once: anger, upset, nausea, a heart rate that felt entirely disproportionate. I got off the phone and tried to carry on. Couldn’t. Those around me could tell something was wrong, and I pushed them away. I nearly made myself ill.

Then I did something that turned out to matter: I found somewhere quiet, sat down, and wrote everything out. Brain dump, no filter: what was said, what I felt, what I thought I might have done differently. It took an hour or two. By the end, the cloud had started to lift.

On the train home that night I turned those notes into something resembling a plan.

A month on

Things have settled. I still turn it over occasionally, still second-guess moments I can’t fully reconstruct. But I’m glad I forced myself through that extra hour of discomfort: because what came out the other side wasn’t self-pity. It was something to work towards.

The notes gave me tangible things to act on. More importantly, they gave me a goal.

That’s the thing about rejection. It’s only wasted if you don’t do anything with it.

What a Year

2016-02-04T00:00:00Z

It’s now February 2016, almost a year to the day that Samuel was born, and things are only just beginning to slow down enough to actually gather my thoughts from the last twelve months.

I always knew that 2015 was going to be a stand-out year: fatherhood was imminent, and I had some sense of what that might mean. I had no idea just how much of a year it would actually be.

January brought a mandatory period of abstinence from alcohol: partly due to the usual Christmas excess, but mainly because we were on-call for a trip to the hospital at any moment. In the early hours, that became very real. Contractions started. I worked from home through the day keeping a close eye on things, and then at 18:20 everything shifted.

The next morning, my little boy was born. From that moment, everything changed.

The other significant event of the year was leaving Code Computerlove after just over seven and a half years, to join Zuto. Still front-end, but a different context, working as part of a dedicated in-house team rather than building things for one. It was a bigger move than I expected, in every sense.

Two enormous things in twelve months. The rest of it (the quieter stuff, the adjustments, the things that don’t have neat summaries) that’s harder to write about, and probably not for here.

Wow. What a year.