DEV Community: Chris

French courts just rejected a 71% accessibility compliance score

Chris — Fri, 10 Jul 2026 12:04:52 +0000

Disability groups took Carrefour to court because visually impaired users were routinely blocked from completing basic tasks on their site and mobile app.

In June 2026, the French judicial court ruled against Carrefour.

Carrefour didn't deny their legal obligation but their defence would match what many project managers try and argue - they claimed they were already 71% compliant under the RGAA (the official French digital accessibility framework).

They essentially argued: "Look, we've done some work"

The court’s response was a sharp reality check

"The eCommerce site in question cannot just be somewhat accessible it must be totally accessible."

Carrefour has exactly six months to achieve compliance across all 106 criteria of the technical framework, or face a daily penalty of €500 for every day they remain non-compliant. Ultimately this is a failure under their CTO Olivier Gibert's leadership.

Why "mostly accessible" is a nonsense.

The court used this example

If a building has a staircase, 100% of the steps must be covered by a handrail. If you only install a handrail on 71% of the steps and leave the top 29% completely bare, the staircase is fundamentally unsafe and unusable for someone who relies on that rail.

In code, accessibility works exactly the same way. If a user can browse your store, filter categories, and add an item to their cart, but your checkout form fields lack proper HTML labels or your "Place Order" button is a flat <div> with no keyboard focus state, the entire site is broken for that user.

You don't get partial credit for letting a user build a shopping cart if you block them from spending their money at the final step.

Why Developers need to shift their mindset

An automated score really tells a disabled user nothing about if they can use your website. If a company thinks they're doing great but the mega-menu doesn't even work with keyboard properly it indicates there is still lots of work to do.

This case proves, arguing "we did some work" is not going to prevent fines. If the company is not testing with disabled users, what the team is doing has a technical name:

Guessing

Raising a good Pull Request

Chris — Fri, 10 Jul 2026 11:41:05 +0000

A great Pull Request (PR) should read like a high-quality blog post.

I'm sure everyone's experienced this, you open a teammate’s PR only to find a blank description, an obscure title, and a wall of changed code.

You have a million questions. What is this? What issue does it fix? How do I test this? Who approved this decision? Who did you speak to? What were the trade-offs? How do I run this locally? What visually does it change? Why did you do it like this?

Sloppy PRs are a plague on development teams, laziness leads to bad habits, random project nicknames, and a sea of unexplained acronyms that nobody else understands. When you submit a lazy PR, you are telling your team, "my time is more valuable than yours."

For those early in their career, mastering this skill is one of the fastest ways to stand out and show great professionalism. To demonstrate clear technical communication.

It's one of the telling signs of a poor development culture. It can snowball, once this becomes culture, normalised, developers can get more and more sloppy.

A PR requires the reviewer to checkout the code, review it locally and verify it works. This can take days. It doesn't mean put your finger in the air and glance at the code to get sense if it's OK. However if your pull request looks like this that's can encourage that behaviour. Throwing it over the fence getting someone else to do the work.

The 1 year test

When you open a PR, imagine you are returning to this exact page in one year's time. The context will be completely gone from your memory.

A great PR acts as a permanent historical record for your repository. It bridges the gap between your immediate thoughts and the long-term documentation of your codebase.

Anatomy of a high quality PR

To write a PR that your teammates will love to review it can follow a simple format.

What

Link directly to the tracking ticket or issue. State exactly what problem this code solves.

Why

The "Why" document the technical trade offs you made and mention who you spoke with to align on this solution.

Screenshots

If you changed the user interface, attach a screenshot, an image, or a short video demonstration.

Anything else?

Write a step-by-step guide explaining how the reviewer can pull down your branch and verify the changes locally.

Ban internal acronyms

Add comments to the code. If someone is unclear of there is something that needs to be explained add this.

Add any resources that support your decision, how did you arrive this?

Create a markdown template

The easiest way to break bad PR habits is to automate the process. You can use platforms like The GitHub Blog to set up a standard pull_request_template.md file in your repository.

When a template autofills every time a team member opens a new branch, it forces everyone to slow down, fill in the blanks, and provide the clarity the team deserves.

React's architectural accessibility gaps

Chris — Wed, 01 Jul 2026 09:38:47 +0000

Unless you build it yourself there's no auto lang sync, change announcements, or focus management

Imagine a language toggle on a website. The user clicks it, the content and UI swaps from English to French, it looks done but what's expected for accessibility? There are 3 aspects that need checking in this context.

WCAG 3.1.1 (language of page) `<html lang="">`has to update

Screen readers use the lang attribute to choose a pronunciation engine. If it's stuck on en while the visible text is now French, every word gets read with English phonetics. Its completely mispronounced, it's a bit like Siri reading French in a English accent, it's going to get all sorts of things wrong.

WCAG 2.4.2 (page titled) `<title>` has to update

As the language changes so does the title "Welcome to our website" changes to "Bienvenue sur notre site web." Screen reader title announcements, and browser history all rely on this.

WCAG 2.4.3 - focus has to be considered

The user clicks the language toggle, the content changes however the user's focus needs to be considered.

WCAG 4.1.3 - status messages

Requires that important changes, be announced to screen readers even if the user's focus never moves there.

React has an architectural gap

React doesn't automatically handle any of these, it's down to the Developer to be aware and fill in these gaps.

Does SSR (server-side rendering) fix these issues within React?

Not really. SSR (Server-Side Rendering) simply means computing the HTML on the server before sending it to the client. SSR is a prerequisite for progressive enhancement in JavaScript frameworks.

Server-side rendering lets you compute the correct lang and <title> before the HTML leaves the server. Search, AI crawlers and assistive tech that read the document before hydration get the right values immediately.

But SSR has nothing to say about what happens after hydration, when a user clicks the toggle without a full page reload. That's a client-side state change happening entirely within the React tree, and SSR's job is already finished by then. SSR fixes the document the server ships on first load. It doens't handle the interaction that happens after, React doesn't ship an aria-live title-watcher to address that gap automatically.

Quick aside, this client-side interaction gives a smooth interaction to the user, they don't get a page reload flash when interacting with the page, but this is less relevant with @view-transition now shipping in many browsers, a great demo can be found here.

Does React Router fix things?

Ryan Florence, who built Reach Router wrote about why automatic focus management on route change got dropped, he laid out the actual blocker, "focus management and scroll restoration are, in most cases, mutually exclusive, because moving focus to a new element also scrolls it into view, which fights with React Router's scroll restoration on back/forward navigation."

"this is a big problem that I don't know how to solve and why I've opened this discussion. Without a resolution here this effort is blocked"

The official migration guide from Reach Router to React Router v6 stated a goal of the rewrite "stop doing not-good-enough focus management by default." The people who built the router, hit this wall and documented hitting it. React Router's own current accessibility docs now frame it as your problem to solve.

React Router doesn't make any assumptions about your UI as the route changes. There are some important features you'll want to consider as a result, including: Focus management and Live-region announcements.

Chris Ferdinandi ran into the same issue last year, "I recently worked on a project with React Router, which I thought handled this automatically, but for some reason was not in my app".

Ok this is React, does Next.js fix this?

The App Router's generateMetadata solves <title> and announcement issue with caveats better than plain React but there is an open bug that mentions the focus issue in particular saying "Today, nextjs does nothing to help with this." It seems like some version of this has been around since 2019.

So what actually fixes these issues in React?

Ok, so now we know the problems and a bit of the history of what-is-and-isn't-possible what are the steps needed for the fixes?

1. Change the `lang` attribute

This is the only one that's a single, simple DOM write addressing WCAG 3.1.1

useEffect(() => {
  document.documentElement.lang = locale; // 'fr'
}, [locale]);

A quick note, if your language toggle lives inside a design system (DS), it generally can't reach past its own subtree to mutate document.documentElement and doing so anyway is bad practice for a shared component. The realistic pattern is for the DS component to tell the app something changed via a callback, the app is responsible for updating the document.

2. Announce the change with custom text, not the title

One fix is creating new element with an aria-live region so this can announce the content changes "Language changed to French", as a spoken message addressing WCAG 4.1.3. There might dedicated React plugins that address this.

const [announcement, setAnnouncement] = useState('');

useEffect(() => {
  document.title = translatedTitle;                          // updates the real title, for tabs/history
  setAnnouncement(`Language changed to ${languageName}`);    // separate, custom text for AT
}, [locale, translatedTitle, languageName]);

<div aria-live="polite" className="visually-hidden">{announcement}</div>

This doesn't touch document.documentElement.lang, so it's possible to ship an aria-live="polite" region that proudly announces a language switch, in an English-voiced, mispronouncing the French it's reading, because the structural lang attribute it depends on is still wrong.

Quick digress, there is a hack to announce a document's title changes with aria-live with display: block on <head> and <title>, but it's fragile and inconsistently supported across screen readers not a real fix.

3. Shift focus, but where? It depends on context

In this context switching the language acts as a full content change, managing the focus so assistive tech users aren't left stranded on the toggle. Shifting focus to the body is one choice but this is debatable.

In 2019, Marcy Sutton did some disabled user testing with Fable, across five participants using screen readers, screen magnification, voice navigation, keyboard-only, and switch access, found three workable approaches:

Focus the heading <h1> this tested as the fastest, clearest experience, it announces the new content immediately and drops the user straight into it.
Focus the content wrapper <main>, also moved screen reader users past top-level navigation successfully, though testers found it noticeably more subtle than a heading.
Focus a visually hidden skip-link. Headings and wrappers worked well for screen readers but broke down elsewhere. Screen magnification users hit some problems, a wrapper or heading spanning a wide layout caused the browser to scroll to the middle of it when zoomed in, cutting off text at both edges. For this group, doing nothing sometimes beat the "best practice" pattern. Separately, keyboard-only users couldn't reach the <main> landmark at all, since landmark regions aren't keyboard-focusable by default. A small, focusable skip-link sidesteps both problems.

For a complex UI, the skip-link appears to be the safer default specifically because it was the only pattern that held up across every disability group tested. For a straightforward use-case or site, focusing the <h1> or <main> wrapper gives a good experience.

import { useEffect, useRef } from 'react'

function Page({ locale }) {
  const headingRef = useRef(null)

  useEffect(() => {
    // tabIndex={-1} lets us focus it programmatically
    // without adding it to the natural tab order
    headingRef.current?.focus()
  }, [locale])

  return (
    <h1 ref={headingRef} tabIndex={-1}>
      {translatedTitle}
    </h1>
  )
}

Anything else?

For the title specifically, React 19 added native support for hoisting <title> tags rendered anywhere in your tree up into <head>. Worth knowing if you're on an older React version but native hoisting only covers <title>, <meta>, <link>, <style>, and <script> but it explicitly does not cover lang, which is htmlAttributes, and it does nothing for the announcement live region either.

React is one of many options, SvelteKit doesn't have these issues

These gaps don't apply to all JS libraries / frameworks. For example, SvelteKit ships fixes for all three problems as framework defaults.

SvelteKit's accessibility docs describe a built-in fix, the framework injects a live region onto the page that reads out the new page name after every navigation, determining what to say by inspecting the <title> element itself.

You still have to set a unique title per page, using <svelte:head> which can appear in any component and writes directly into document.head but the live-region announcement on top of it is the framework's job, not yours.

However just like React, if you are doing a client side route change without a full page reload, you still need to update the lang attribute client-side using <svelte:document> and focus is returned the body but this can be managed using autofocus. React has none of this.

The takeaway

These are architectural gaps with React, its down the the developer to be aware, resolve and manage these issues with ensure accessibility standards are met.

Your accessibility score is lying to you

Chris — Tue, 07 Apr 2026 22:38:35 +0000

Automated accessibility testing tools, such as axe-core by Deque, WAVE, Lighthouse are bit like a spellcheck for web accessibility. They are really useful for identifying and resolving many common accessibility issues quickly.

There are a whole range of tools that provide similar services, a way to detect some of the most common accessibility issues across a page.

The problem with automated accessibility scores

The problem is the way their reporting gives a score of out 100%. It gives the impression to the uneducated that an automated scoring once it reaches 80 or 90% is pretty good. However, these scores can be deeply misleading.

Automated tests typically detect only 20% to 40% of real accessibility issues. What about with AI I hear you scream? I'm sure that will increase but for now let's pause that for this post. Like a spell-checker that flags spelling mistakes but cannot understand meaning or context, it can't tell you if the book makes sense. These tools identify technical errors but miss many barriers that only humans can detect.

Deque’s own marketing materials claim they can detect up to 57% of issues, although at the time of writing I find it hard to review how they're arrived at this. Which websites? How was this tested etc? Are there user testing videos?

How this scoring misleads those in power

I was sat in a presentation recently, cringing, where a Product Owner and Lead Designer proudly assert their automated score of 70% suggesting their "almost there" when they are so far away from the reality...

Suddenly there was another epic piece of work to educate certain stakeholders about this misleading nature of this score.

A site scoring 70% might appear nearly compliant but if we accept the marketing claims of 57% then a “70%” score equates to roughly 39.9% of actual accessibility compliance. This discrepancy leads people to believe that accessibility work is largely complete, when in fact the majority of blockers remain unresolved.

Automated score (%)	Approx. % of actual issues detected (57%)
30	17.1
40	22.8
50	28.5
60	34.2
70	39.9
80	45.6
90	51.3
100	57

The wider consequences

When teams focus on improving their automated score, accessibility becomes a checkbox exercise rather than a genuine effort to create accessible experiences. Developers start “fixing for the tool” instead of fixing for disabled users. The whole goal is to simply get the tooling to give a green light.

This has several negative effects:

Teams make superficial somewhat performative, changes to satisfy tooling rather unblock disabled people.
Businesses suddenly think they are compliant when they are not, giving them a sense of false confidence.
Leadership tend to use these scores to justify reducing investment in accessibility.
Most importantly, disabled users remain unable to complete tasks such as checking out, navigating menus, or using interactive features.

Why automated tools still matter

Don't get me wrong, automated accessibility tools should not be dismissed, They are excellent for identifying obvious issues and ensuring consistency across large codebases. However, they are only a starting point, not a comprehensive solution. They are not a replacement for testing with real disabled users.

The things below can't be skipped

Manual testing with assistive technologies
User testing with people with disabilities

Without these, even a “perfect” automated score is somewhat meaningless.

Time to get uncomfortable

The uncomfortable truth is that, in many organisations Accessibility isn’t treated as a commitment to unblocking people, it’s a risk management piece. For some leaders, it’s not about people, it’s about protection.

They invest in automated tools, chase high Accessibility scores because if they’re ever challenged legally, they can point to those numbers as “evidence” of compliance, hoping no one looks too closely.

Sometimes the companies selling these Accessibility testing tools also have a vested interest in keeping those scores high. Their products are compared against other platforms, and a higher “score” looks better in sales demos. They get their subscription fees whether or not disabled people can actually use the product or service.

Update the metrics

I would love for these tools to update their scoring metrics.

Change their metrics, imagine if axe-core or Lighthouse had a maximum score of 57%. There was no way to get to 100%, that would shift the understanding instantly.

Misunderstanding these scores can give an organisations a dangerous illusion of compliance and may not actually improve the experience for disabled people.

Why accessible video is still not possible on Instagram

Chris — Tue, 16 Dec 2025 09:38:42 +0000

TL;DR - Basic video accessibility features, closed captions and audio descriptions are still not possible on Instagram.

Instagram was launched in 2010, it has grown into a cultural force. While Meta doesn’t publish Instagram’s profit precisely, it is estimated that Instagram’s advertising revenue alone reached approximately $39 billion in 2023 (and will likely make up over half of Meta’s US ad revenue in 2025). The cultural and financial impact of the platform is impossible to understate.

However for millions of disabled people, the short-form-video experience is incomplete, frustrating, and often exclusionary.

The missing accessibility features

The core issue lies in the lack of support for industry-standard accessibility features:

Closed captions are not fully supported

Closed captions (CC), like those found on Netflix or broadcast television, are not really possible on Instagram. Closed captions are a vital feature for the deaf and those hard of hearing community. They usually appear at the bottom of the video with high-contrast text (eg white text on a black background) and, crucially, can be switched on and off by the user. They also allow for adjustments in text size and shape, and can be picked up and processed by assistive technologies.

Instagram offers some users automated closed captions but it doesn’t let users edit this text or really control any aspect of it relying on automation. It’s not possible to add a relevant caption file which is essential for accuracy and compliance.

Open captions which are often ‘burned’ directly into the video file, meaning they cannot be turned off, adjusted, or read some assistive technology. These are possible but which is something, but open captions have been normalised as an aesthetic addition to a video, rather than an accessibility need. They are often flashy and are used to drive engagement rather than serve deaf people and those with hearing loss.

Audio description is not possible

Equally, audio descriptions which is a secondary audio track that narrates key visual elements for people who are blind or have low vision is not a built-in possibility on Instagram’s video features. This means content creators cannot easily upload a separate audio track to ensure their visual stories are accessible to everyone.

There are 3 core layers of why this is happening

The missing features are basic and would be simple for a company with Meta’s resources to implement. The reasons for this failure are structural and I can sort of break them down into three parts.

Regulation (the Government layer)

In jurisdictions like the UK, broadcast television is bound by strict laws that force broadcasters to include features like closed captions and audio description. Instagram, however, removes this legal obligation because it is classified as a tech platform, not a traditional broadcaster, allowing it to operate in a regulatory grey zone with fewer accessibility requirements.

Legal Liability (the structural layer)

On broadcast TV, the channel or network is legally responsible for the content’s accessibility. On Instagram, that legal liability has been effectively shifted to the user creating the content. The platform doesn’t feel compelled to provide the tools because the creators shoulder the burden. Netflix only started to take captioning seriously after they were sued in 2015. (Does the European Accessibility Act apply? Quite possibility, but that’s another post)

Culture (the top-down layer)

Ultimately, this points to a deep-seated cultural issue. Meta has a long, public history of deprioritising accessibility features in favour of new monetisation tools and engagement drivers. Threads was launched without features to add alt text. The lack of basic functionality points to a persistent top-down culture where the needs of disabled users are not treated as a priority, if at all.

What is the solution?

The fix is almost laughably simple for a company of Meta’s scale. They possess virtually unlimited resources and could:

Establish a dedicated, empowered Accessibility Team within Instagram.
Run a short development sprint (allocate time) to allow users to upload external caption files (SRT, VTT formats) and separate Audio Description tracks.
Launch a global marketing campaign to educate content creators on the importance and process of adding these features.

Will they do it?

Instagram short-form-video “Reels” launched over 5 years ago in 2020, and the fact that such a basic, fundamental features are still missing speaks volumes. It is unlikely to happen until the regulatory or public pressure becomes financially too great to ignore

In the meantime, what are the workarounds?

Use other platforms. Creators who value accessibility should post their video content on platforms like YouTube, which have robust, fully adjustable closed caption support and audio description options, and then link back to their Instagram profile.

The platform may be an cultural force, but until it provides truly accessible tools, it excludes a significant portion of people with health conditions or impairments.

Cover image: Instagram Reels, with the Reels icon on the left (a play button inside a stylised film strip) and two smartphones on the right displaying the Instagram app. One phone shows a user profile, and the other shows a dancing video playing in the Reels interface.

Accessibility: FashionNova fined $5.15M, Vueling Airlines €90,000

Chris — Thu, 02 Oct 2025 10:48:51 +0000

FashionNova, Vueling Airlines, Auchan, Carrefour, E. Leclerc, Picard Surgelés logos on white background

The European Accessibility Act (EAA) came into force on 28th June this year. But what’s happened since June?

On 7 July 2025, two visual-impairment advocacy groups (apiDV and Droit Pluriel), with legal support from the collective Intérêt à Agir, issued formal warnings to four large French retailers Auchan, Carrefour, E. Leclerc, and Picard Surgelés for failing to make their online supermarket services fully accessible.

If the retailers haven’t fully complied by 1 September 2025, the associations plan to take legal action to enforce their obligation.

Vueling Airlines

Meanwhile last year in 2024, airline Vueling in Spain was fined €90,000 in for failing to make their website accessible. They were fined even before the EAA came into force, demonstrating that accessibility enforcement isn’t just theoretical, the EAA will only make expectations even clearer.

Fashion Nova was fined millions

Fashion Nova in the US was fined $5,150,000, individuals who are legally blind and attempted to access the Fashion Nova using screen reading software now may be eligible to submit a claim.

Featured on TGPi, Weekly Reading List August 18 2025

Want more simple, actionable tips? I'm Chris, a UX Developer with a focus in accessibility, available for hire.

Follow me on LinkedIn

Why does big tech not run Accessibility bug bounties?

Chris — Thu, 02 Oct 2025 10:45:11 +0000

A dark blue background filled with a grid of light blue binary code (ones and zeros). In the center, a large, stylised outline of a beetle or bug is visible in a slightly brighter blue. The bug is flanked on either side by a large, light blue curly brace, enclosing it like a piece of code. The overall image represents a programming or software bug.

10 reasons why this would be great

The biggest names in tech, from Google to Netflix, invest millions in security bug bounty programs. They pay ethical hackers, also known as researchers, to find vulnerabilities, Netflix can pay upto $25,000 for a critical bug viewing it as a smart business move to prevent security vulnerabilities in their software, systems, or websites.

So why not for Accessibility bugs?

It’s a somewhat perfect analogy to security. The principle is identical, crowdsource the identification of critical flaws that the internal Production team might miss. Lack of proper keyboard navigation is a critical bug, just like a security vulnerability. The only difference is who is at risk.
A bug bounty program provides a direct and immediate channel for feedback. Issues can be reported and triaged in real-time, allowing for rapid fixes and a continuous cycle of improvement.
A bounty program almost gamifies accessibility bugs in a way. It creates this technical competitive environment that encourages technical experts to find and report the most critical issues, accelerating the discovery of flaws and raising the standard of Accessibility testing across the industry. It also creates this technical environment where Accessibility bugs are treated like the technical bugs they are.
It aligns the financial incentives, Accessibility professionals, Designers and other Developers are being paid for their detailed labour and feedback, bugs are being fixed while the company benefits from the labour. It encourages others to learn about Accessibility and even try and find bugs as now there’s a method to get paid for this labour. Someone posting they were "paid $1,000 to fix a P3 Netflix Accessibility bug" might help change the culture.
It's proactive, not reactive. Many companies fix accessibility issues only after receiving a legal threat or public backlash. A bug bounty program would incentivise a proactive approach, encouraging companies to find and fix issues before they become a liability.
Companies that publicly champion accessibility through a bounty program can build a reputation for inclusivity. This not only attracts a wider customer base but also helps recruit and retain talent who want to work for socially responsible organisations.
A bug bounty program allows companies to pay for verified bugs on an as needed basis with a fixed allocated budget.
Accessibility advocates and testers often perform valuable, unpaid labour by reporting bugs and providing feedback. A bounty program would finally validate and compensate for this work, turning a moral obligation into a paid, professional pursuit.
A public bug bounty program signals a genuine commitment to Accessibility. It makes a company's efforts transparent, showing the community that their feedback is not only heard but valued and compensated.
Beyond all business justifications, running a bug bounty program would also acknowledge the ethical duty companies have to ensure their products are usable and accessible to everyone, regardless of ability. By doing so, they demonstrate that they value the well-being of all their users.

Someone at a big tech company with the budget to launch an Accessibility bug bounty program might like to see this post.

Want more insights? I'm Chris, a UX Developer with a focus in accessibility, available for hire. Follow me on LinkedIn

Use of Colour (Level A) WCAG 1.4.1 - Accessibility Design tips

Chris — Thu, 02 Oct 2025 10:36:56 +0000

Don't use colour as the only way to tell people something important. Colour is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

Why is WCAG 1.4.1 important?

There are various eye conditions that mean people see colours in different ways. This includes various types of colour blindness, some people need high contrast, some people need low contrast, there’s a whole spectrum of people that might see the world differently.

Web Content Accessibility Guidelines (WCAG) 1.4.1 means by not relying on colour alone within a Design,

Let’s give an example, what's the problem with these links?

Only colour is communicating what is a heading and what is a link. In this example “Overview” is a heading but the rest are links, all the spacing is the same, the font size and weight is the same. Meaning what is a link and what isn't is harder to determine.

Below is what someone with blurred vision might see.

Someone with cataracts, glaucoma, age-related macular degeneration might see reduced contrast. Notice how the contrast is harder to see so the colour difference of what's a link and what isn't makes less of an impact, it’s less noticeable.

Achromatopsia, is one type of colourblindness in this context the colour is stripped this is what this person might see.

The solution to WCAG 1.4.1 is to add a second visual cue. Colour is not used as the only visual means of conveying information.

In this example, the links or headings need to have a second visual cue. Often links as historically blue and underlined. The blue colour lets sighted users know it's a link, but the underline provides that extra visual cue for people who might see colours differently.

Historical fun fact, the creator of the blue link chose it because he liked blue and it was partially down to the fact that screens at the time could also show a small amount of colours, so they could have easily been green or something else.

How to meet WCAG in this context?

So, for links to be accessible, you need to ensure they are:

Distinct from other text, they shouldn't blend in with the surrounding text.
Identified by more than just colour, they need a non-colour visual cue.

Underlines are typically the best, easier and simplest solution to this problem. More on this in a moment, however underlines are not the only solution to this problem. WCAG often describes the problem rather than a set of solutions.

Solution 1 - change of size and shape

In this solution the headings are made bigger, bolder and there is more spacing between the heading and the links. This ensures that 1.4.1 is met and more than colour is being used to determine the difference. The headings are very clear and they are different. Not as good as it could be but still works.

Solution 2 - remove the confusion

Another solution is to remove the headings entirely, this way there’s no confusion at all, all of these are links due to the positioning.

Solution 3 - underline the links

The most simple solution is to add an underline to the links, this sticks with a known convention.

Solution 4 - style the underlines

Don't like the way those underlines look? How about giving the underline more breathing room, along with a reduced opacity to make it more subtle?

Solution 5 - what about overlines instead?

Don’t like underlines at all, how about overlines, so lines on top? A bit more unconventional, however still manages to comply with WCAG 1.4.1

Solution 6 - how about an icon?

Don’t like the overline, how about an arrow icon or shape so that the links are clearer?

Those were 6 Design solutions that take the WCAG constraints and implement a creative Design solution. There's probably 100s more that could also work.

I personally prefer adding a border, an outline, or an underline, or increasing the thickness of the text (or a combination of any of these) to highlight the active link. - Sara Soueidan

“It is amazing to me how this suggestion causes so much angst and fighting. Designers often argue that they look ugly, some users claim they are distracting, others even claim they reduce accessibility.” - Adrian Roselli

This is where some designers bristle. If there are a lot of links on a page, it could look awfully cluttered with underlines. That’s why some designers would rather remove the underline completely - Jeremy Keith

But I don’t like any of these it spoils the vibe...

Look I get it, there’s a layer of what visually looks good, feels nice. Some argue that underlines create visual noise, making the design look cluttered or less sophisticated. Change can be difficult.

For many users, a lack of an underline is even more distracting. They have to scan the entire section, mentally hover over each piece of text, or rely on a slight colour difference to figure out what is clickable and what isn't. This mental effort is called cognitive load. An underline eliminates this problem instantly, making the section scannable and reducing frustration.

The problem is what one person sees as "visual noise" is, for another, a vital, expected cue that makes the page easier to use. This is when WCAG comes into play, to make things more detailed. A set of international technical standards that move away from opinion.

I’ve done a lot of audits in the first half of this year and at this point a believe that designing links without underlines is a kink. The idea that users don’t understand that links are clickable arouses some designers. I can’t explain it any other way. - Manuel Matuzović

This is often the crux of this argument, there is an aversion to change due to aesthetics, meaning it looks nicer to some people. However this goes back to the concept of Design. Design is about function first. Something can be beautiful first and lack function.

Function first, beauty second

This watch (below) is beautiful, it might be the perfect choice for a photoshoot, for an Instagram profile picture or something where the goal is visual aesthetics.

However, if the goal is to tell the time, consistently, reliably, this design choice fails as it's much harder to see the numbers

Most people aren’t typically visiting most websites to admire the website. Typically they are trying to do something, they are trying to get in and get out. They are trying to find some information, buy something, contact someone, get something done. It should be usable, accessible, first and beautiful second.

What's another example?

Notice how the text adds a secondary visual cue to inform the user whether someone is online

Some more amazing examples can be found on Access Guide

Why are NHS trusts buying Accessibility overlays?

Chris — Thu, 02 Oct 2025 10:26:41 +0000

The NHS is bound by the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018. These regulations require websites and apps to meet the Web Content Accessibility Guidelines (WCAG) and to be usable by everyone - including disabled people.

Unfortunately, some NHS trusts are relying on so-called accessibility overlays, which I've written about in more depth. These are plug-in toolbars that claim to “fix” accessibility problems automatically. These overlays don’t make websites compliant. In fact, they can create new barriers, often make things worse, interfere with assistive technologies like screen readers, and give organisations a false sense of compliance. Sometimes people mean well but often they are sold products that don’t work.

NHS Trusts using Accessibility overlays

After some short amount of time doing some research, I discoverd at least 15 NHS trusts that have currently deployed overlays (there could easily more).

Why this matters

By using overlays instead of making their websites genuinely accessible, these trusts are failing to comply with accessibility law. That puts them at legal risk, wastes money, but more importantly, it lets down the disabled patients, staff, and carers who rely on accessible information.

The way forward

Accessibility can’t be bolted on with a widget. NHS trusts need to commit to building accessibility into their websites from the ground up. Stay tuned for part 2.

Accessibility failures -FashionNova fined $5.15M, Vueling Airlines €90,000

Chris — Mon, 18 Aug 2025 10:07:28 +0000

The European Accessibility Act (EAA) came into force on 28th June this year. But what’s happened since June?

If the retailers haven’t fully complied by 1 September 2025, the associations plan to take legal action to enforce their obligation.

Vueling Airlines

Fashion Nova was fined millions

Fashion Nova in the US was fined $5,150,000, individuals who are legally blind and attempted to access the Fashion Nova using screen reading software now may be eligible to submit a claim.

Accessibility pushback

Chris — Mon, 18 Aug 2025 09:52:06 +0000

Talking openly and debunking some common pushback

Pushback or objections when advocating for accessibility is unfortunately very common. Companies are all at different points in their journey, and the Accessibility Maturity Model from W3C outlines these different stages. The less mature a company is in its journey, the more often pushback will be encountered, and the more nonsensical this pushback can be.

“It’s very common, everyone does it”

A classic. One that’s used time and time again. This is really a simple bandwagon fallacy that pops up a lot in Accessibility as a way to justify a decision. Just because lots of companies do it, doesn’t mean it’s accessible. It doesn’t mean it aligns with WCAG, it doesn’t mean it’s been tested with disabled people.

Other flavours of this include “but Google does it..” There is an amazing blog post that tackles this common fallacy in depth.

I Don’t Care What Google or Apple or Whoever Did

It also compounds, sometimes these decisions are made in 2 seconds on a Thursday afternoon, if the company is a household name then other people copy it and thus the cycle continues.

Does the pushback have engagement with the Web Content Accessibility Guidelines (WCAG)? No, then this is ableism. We’ve all absorbed ableist ideas, because society itself is built on them, the good news is we can unlearn these. Is there a follow up task created to revisit it? No. Ableism. However, does the pushback engage with WCAG and provide solutions and compromises? This is healthier.

“Accessibility can’t be a bottle neck”

There’s a lot to unpick in this sentence. This phrase frames accessibility compliance as a type of obstruction, not a normal part of the process. This misrepresents accessibility, this extra burden or the “cherry on top” rather than the flour in the cake that’s baked into the process. If something is a bottleneck, it suggests it’s an additional step tacked onto an existing process. It implies Accessibility is an add-on or afterthought. This is why it’s crucial to have an experienced accessibility specialist on the team from the beginning.

It usually is used to ignore taking action. A way to argue that urgency has to override the work being asked to be completed. A way to create pressure and convenience so it can be ignored. However it just creates more work, if this is not fixed at Design stage, it ends up being way more expensive later on to resolve.

Accessibility is about baking it in from the very first thought, rather than trying to retrofit it later. There’s been quite a few food analogies. One that has been popularised is from an web accessibility engineer at Salesforce and co-host of the 13 Letters Podcast

You can’t put the blueberries in the muffin after the muffin is baked. – Cordelia McGee-Tubb

I’ve seen other variations of this

You can’t sprinkle on eggs after the cake comes out of the oven…taste along the way - Sara Basson

Also by calling it a bottleneck, this tries to shift responsibility. Someone or a team can implicitly “blame” accessibility itself for delays. Rather than looking inward at their own processes, lack of proactive planning, lack of training, poor hiring, unwillingness to change habits, read documentation, or insufficient knowledge. It also devalues the expertise of accessibility professionals. The language can be disheartening for those championing accessibility. It signals that their efforts are perceived as hindrances, annoyances to business as usual.

“We have to live in the real world”

By suggesting that accessibility is not a part of the “real world,” it implies that the experiences and needs of 24% of people are somehow not part of this “real world”.

It also frames the request as an extreme or unreasonable demand when the actual request is likely a very reasonable, well-documented best practice (“Can we add alt text to these images?”). By misrepresenting the request, it’s easier to dismiss it as impractical.

Airbnb introduced a new accessibility category and generated an extra $5.5 million in 4 months.

“We just sell [product] we’re not a bank”

The sentiment behind is built on a foundation of really shaky logic. There are multiple fallacies at play here.

First, it uses the simplicity fallacy, implying that because a product is not essential, the need for accessibility is trivial. This ignores the fact that 1) the European Accessibility Act (EAA) is active and 2) a user’s experience is defined not by the product, but by the user interface.

Second, this statement presents a false dichotomy, suggesting that a business is either a high-stakes, high-risk company like a bank that needs to care about accessibility, or it isn’t. In reality, the legal obligation to provide equal access exists for all, regardless of the industry.

Third, the argument often stems from a place of appeal to ignorance, where a lack of personal experience with disability leads to the assumption that a website is universally usable simply because it works for the speaker. They’ve never been blocked making a purchase so “who cares”.

Finally, this perspective often employs a straw man fallacy, arguing against a caricatured version of accessibility as an overly burdensome and costly process, rather than what it actually is: a set of foundational best practices that improve the experience for everyone.

It sort of implies some companies need to be more accessible than others as they can cause larger harm. In some ways I can understand this while I don’t agree with it. The idea that a financial product needs to be more accessible than a luxury scarf company. If someone can’t buy a luxury scarf they can purchase a different scarf. However doesn’t everyone deserve a to be able to purchase a luxury scarf if they want to?

Also, what happens when digital professionals that work at the luxury scarf company take their skills into the healthcare sector?

“This WCAG advice is from 2017?!”

The implication of this sentiment is that because the advice is older therefore it’s not valid. It’s the inverse of an appeal to novelty fallacy. This fallacy suggests something is superior because it’s new.

Of course there is the possibility that changes might have happened since 2017 and there is a better way to do things, a more accessible way. However this should be easily evidenced. Is there an issue raised against this pattern? Is there an existing discussion to read? Some new research to review?

However, if recommended WCAG patterns are dismissed simply because they are old without any other justification it sets a really odd precedent.

I think this stems back to a cultural issue. As WCAG was published in 1999, WCAG 2.0 in 2001, WCAG 2.2 in October 2023. Private companies have now been building digital products and services for over 26 years and have been able to ignore WCAG.

26 years is a lifetime (and then some) in tech, there will undoubtedly be some digital professionals that have been able to progress to the most senior levels, sell courses and pass on “best practice” without even considering WCAG. Also, in the age of context collapse, casual advice can be presented with the same authority as in-depth research from professionals.

“If we’re sued we’ll revisit it”

The argument implies that because no lawsuit has been filed yet, there is no problem, and therefore no action is needed. The absence of a lawsuit is being used as evidence that the issue isn’t important enough to address. This is a terrible strategy for several critical reasons. It’s a reactive, not proactive.

Also, “the biggest lie in software is Phase 2” - Jeff Gothelf from Lean UX

When dealing with pushback, ask

Is someone only looking for some type of last-minute sign off?
Has someone engaged with the detail? With WCAG? With the the - resources shared? Have they chosen to reply selectively and ignored all other points?
Is the person acting in good faith or engaging in demagogue behavior? Good faith means they are genuinely trying to find a solution. Demagogue behavior means they are focused on gaining support, even if it means ignoring facts or expert advice to do so.
Can this be clearly captured as a bug to be prioritised later on?

When intent and expertise are aligned, accessibility challenges can be addressed as technical issues by professionals working together toward solutions. With the right people in the right roles, accessibility can stop being a tick-box exercise and becomes a natural, integrated part of creating better products.

Scandinavian Airlines were fined $100,000 for accessibility bugs

Chris — Sat, 14 Dec 2024 05:58:08 +0000

They faced legal action in two different markets.

Did you know, in 2017 the Norwegian government gave Scandinavian Airlines (SAS) 12 months to fix accessibility bugs on their website.

Instead of building their main website so that it was accessible inline with WCAG, SAS made a separate website after advice from a third-party company. They created a separate “assistive” experience for people with disabilities.

Creating a separate experience for people with disabilities might seem like a good idea, it’s not. A separate experience is continued discrimination not equality.

Meanwhile in the United States, the Department of Transport (DOT), also found that SAS’s website had accessibility bugs and ordered them to fix them. Airlines operating in the U.S. have to make their main website accessible to people with disabilities, as per the Air Carrier Access Act (ACAA).

Why did SAS create a different experience?

They were sold the wrong solution by a third party. They were told this new, different, website would fix all of their accessibility issues and legally protect them - it didn’t.

Separate assistive websites have more issues

They often don’t have all the same information as the main site.
They can be hard to keep up to date, maintaining two codebases.
They might not have all the features of the main site.

What happened next?

SAS were told by the Norwegian government they would be charged €15,000 per day should they not fix the issues. In under 10 days they resolved many of the issues.

However in the US, DOT fined SAS $100,000. They then had 12 months to fix their website otherwise they would face another £100,000 fine. SAS also had to stop using this different website, they had to make their main website accessible.

They were told user journeys have to be able to be used by all people, including:

Booking or changing reservation (including all flight amenities)
Checking in for a flight,
Accessing a personal itinerary
Accessing a personal frequent flyer account,
Accessing flight schedules, and
Accessing carrier contact information.

Companies should focus on making their main site accessible to everyone.

A competitor Norwegian Airlines didn’t face such issues. If SAS simply made their website accessible from the start they wouldn’t have faced legal action in two different markets.

Read more about this case and why separate but equal is never OK by Sheri Byrne-Haber

The European Accessibility Act

The European Accessibility Act (EAA), which will come into force in 2025 is a law designed to create equal access for Europeans with disabilities by requiring a mix of products and services to be accessible. This will impact private companies should they wish to operate in the EU.

DEV Community: Chris

French courts just rejected a 71% accessibility compliance score

Why "mostly accessible" is a nonsense.

Why Developers need to shift their mindset

Raising a good Pull Request

The 1 year test

Anatomy of a high quality PR

What

Why

Screenshots

Anything else?

Create a markdown template

React's architectural accessibility gaps

Unless you build it yourself there's no auto lang sync, change announcements, or focus management

WCAG 3.1.1 (language of page) <html lang="">has to update

WCAG 2.4.2 (page titled) <title> has to update

WCAG 2.4.3 - focus has to be considered

WCAG 4.1.3 - status messages

React has an architectural gap

Does SSR (server-side rendering) fix these issues within React?

Does React Router fix things?

Ok this is React, does Next.js fix this?

So what actually fixes these issues in React?

1. Change the lang attribute

2. Announce the change with custom text, not the title

3. Shift focus, but where? It depends on context

Anything else?

React is one of many options, SvelteKit doesn't have these issues

The takeaway

Your accessibility score is lying to you

The problem with automated accessibility scores

How this scoring misleads those in power

The wider consequences

Why automated tools still matter

Time to get uncomfortable

Update the metrics

Further reading

Why accessible video is still not possible on Instagram

The missing accessibility features

Closed captions are not fully supported

Audio description is not possible

Regulation (the Government layer)

Legal Liability (the structural layer)

Culture (the top-down layer)

What is the solution?

Will they do it?

In the meantime, what are the workarounds?

Accessibility: FashionNova fined $5.15M, Vueling Airlines €90,000

Vueling Airlines

Fashion Nova was fined millions

Why does big tech not run Accessibility bug bounties?

10 reasons why this would be great

So why not for Accessibility bugs?

Use of Colour (Level A) WCAG 1.4.1 - Accessibility Design tips

Why is WCAG 1.4.1 important?

Let’s give an example, what's the problem with these links?

How to meet WCAG in this context?

Solution 1 - change of size and shape

Solution 2 - remove the confusion

Solution 3 - underline the links

Solution 4 - style the underlines

Solution 5 - what about overlines instead?

Solution 6 - how about an icon?

But I don’t like any of these it spoils the vibe...

Function first, beauty second

What's another example?

Further reading

Why are NHS trusts buying Accessibility overlays?

NHS Trusts using Accessibility overlays

Why this matters

The way forward

Accessibility failures -FashionNova fined $5.15M, Vueling Airlines €90,000

Vueling Airlines

Fashion Nova was fined millions

Accessibility pushback

Talking openly and debunking some common pushback

“It’s very common, everyone does it”

“Accessibility can’t be a bottle neck”

“We have to live in the real world”

“We just sell [product] we’re not a bank”

WCAG 3.1.1 (language of page) `<html lang="">`has to update

WCAG 2.4.2 (page titled) `<title>` has to update

1. Change the `lang` attribute