Accessibility as a Competitive Advantage, Not a Checkbox

Accessibility enters most projects through the back door: an email from the client two weeks before launch, an automated report with 240 errors, and the inevitable question — what will it cost to make those go away. From that moment the conversation is already lost. A product quality problem has been converted into a line item, and line items always get negotiated down.

The useful reframe is simple: accessibility is not a layer applied on top of design, it is a property of design done well. A button that reads clearly against its background, a form that says exactly what went wrong and where, text that stays legible in sunlight — these are not concessions made to a minority. They are evidence that somebody thought the interface all the way through. Work this way and you stop paying at the end for remediation; you pay at the beginning for decisions, and good decisions cost nothing extra.

An inaccessible site is not primarily breaking a rule. It is losing users silently, with nothing showing up in analytics.

The default mental image — a blind user with a screen reader — is real, but it is a thin slice of a much wider audience. The model that helps most in practice sorts limitations into three groups.

Permanent: low vision, color blindness, tremor, hearing loss, dyslexia, limited hand mobility. In Europe that is tens of millions of people, and the share grows as the population ages.

Temporary: an arm in a cast, conjunctivitis, a migraine, recent eye surgery, a stretch of exhaustion where dense text simply will not parse. Everyone spends a few weeks a year here.

Situational: a phone in harsh sunlight at 200 nits, one hand busy with a toddler or a grocery bag, a noisy train with no headphones, a weak connection, a four-year-old phone with a small screen and battery saver on. That category is, practically speaking, all of your users, repeatedly.

Look at that list and good contrast stops being a requirement for blind users — it is what makes the button visible on a terrace at noon. Generous tap targets are not about essential tremor — they are about somebody's thumb while walking down the street. Accessibility is not an edge case. It is the ordinary case, under real conditions.

You do not need to memorize the full standard to get a good result. In real projects, the same handful of categories keep coming back.

1. Semantic HTML, Before Anything Else

The cheapest win is still using the right element. A real button is focusable, activates on Enter and space, announces itself as a button, and gets native states for free. A div with a click handler does none of that, and you then spend a day badly rebuilding what the browser was handing you. Headings in a logical hierarchy, lists that really are lists, tables with headers, landmarks for navigation and main content. Practical rule: if you need more than two ARIA attributes to make something work, you picked the wrong element.

2. Keyboard Navigation and Visible Focus

Walk any page using only Tab, Shift+Tab, Enter, space and arrow keys. Can you reach everything? Does the order make sense? Can you see where you are at every step? Do you get trapped inside an open modal? Removing the focus outline because it does not match the design is the most widespread act of vandalism in front-end work. Do not delete it — draw it. A deliberately designed focus ring with adequate contrast is a mark of craft, not a defect.

3. Color Contrast

Body text needs a ratio of at least 4.5:1 against its background, large text 3:1, and interface components and their states 3:1. Light gray on white looks sophisticated in Figma, on a good laptop, in a room with the blinds half closed. On a phone in sunlight it vanishes. Check it, and never rely on color alone to carry meaning: an error cannot just be red, it needs words and ideally an icon.

4. Text Alternatives

Every image that carries information needs a short, concrete description. Purely decorative images get an empty alternative so they are skipped, rather than a noisy readout of the file name. Icons with no visible label need an accessible name, via the aria-label attribute or visually hidden text. The golden rule: write what somebody who cannot see the image needs to know, not a pixel-level inventory of what is in it.

5. Labels and Form Errors

Every field gets a persistent, programmatically associated label, not just a placeholder that disappears on the first keystroke. Error messages sit next to the offending field, explain in words what to do, and are announced rather than merely colored. Do not move focus unexpectedly and do not submit on a stray keystroke. Forms are where the money is lost — and also where accessibility problems reliably pile up.

6. Motion Sensitivity

Aggressive parallax, auto-playing carousels, sweeping transitions and scroll-jacking cause genuine dizziness and nausea for some users. Respect the system preference by querying prefers-reduced-motion and offer a calm variant: a short fade instead of a long translation, a stopped animation instead of an infinite loop. You do not lose your visual identity — you just become less tiring.

7. Target Size

Interactive elements need room, and space between them. Roughly 24 pixels is the floor, and 44 is a comfortable target on mobile. Tiny icons packed shoulder to shoulder in a bottom bar are a dexterity test, not an interface.

8. Zoom and Reflow

Enlarging text to 200 percent has to work without overlaps and without horizontal scrolling. Content has to reflow at narrow widths, meaning the equivalent of 320 pixels. If you lay out with relative units and trust normal document flow, you get this almost for free. If you pin heights in pixels everywhere, you will lose days.

The market answered the demand for compliance with a seductive product: a script you paste into the page that promises to make the site accessible overnight. It does not work, and it is worth stating plainly why.

An overlay repairs at runtime, by guesswork, what is missing in the structure. It cannot know whether an image is decorative or essential, it cannot rewrite the flow of a badly conceived checkout, it cannot invent correct labels for ambiguous fields. At best it adds a panel of contrast and zoom buttons that the operating system already provides better. At worst it fights the user's own screen reader and breaks the very experience it claims to fix. The assistive technology community has been saying this consistently for years.

Worse, an overlay creates the impression that the problem is handled. The budget closes, the team moves on, and the structure stays exactly as bad. The same money spent on correct markup stays in the product forever.

Here is the part that persuades stakeholders who do not respond to ethical arguments: accessible markup is, to a large degree, the same markup search engines and answer systems want.

A correct heading hierarchy is also the structure crawlers parse. Alternative text feeds image search. Descriptive link names — see the product specifications rather than click here — help both the screen reader user and the algorithm. Landmarks and semantic HTML make content extraction more reliable, which matters increasingly now that answers are generated from your page without anyone opening it. All of this ties directly into what we covered in the guide to technical SEO for modern websites.

There is a performance overlap too. Less JavaScript spent reimplementing native behavior means a smaller bundle and faster interactivity. Explicit image dimensions prevent both layout shift and the disorientation of a user browsing at heavy zoom — the same thing measured by Core Web Vitals. This is no coincidence: all three disciplines reward the same basic hygiene.

Automated tools are necessary, but they catch somewhere between a third and a half of the issues, on an optimistic reading. They know how to flag insufficient contrast or a missing alternative. They cannot flag an alternative written badly, an illogical focus order, or a flow that is impossible to complete. An honest test plan has four layers.

• Automated, in CI: an accessibility linter and a suite running on every pull request. It catches the cheap regressions immediately.
• A keyboard-only pass: five minutes on the main flows, no mouse. It has the best ratio of effort to problems found of anything on this list.
• A screen reader smoke test: VoiceOver on Mac or iPhone, NVDA on Windows. You do not need to become an expert; walk the home page and one form and listen to what gets announced. You will immediately hear things that make no sense.
• Real users: when the stakes are high, one paid session with two or three assistive technology users is worth more than three paper audits.

The direction is clear, even if the details vary by jurisdiction and deserve a lawyer's review for your specific case. Public sector bodies in the European Union are already required, under the directive on the accessibility of public sector websites and mobile applications, to meet accessibility requirements and publish an accessibility statement. The European Accessibility Act extends comparable requirements to a range of private sector products and services — e-commerce, consumer banking, passenger transport, e-books, electronic communications — with carve-outs for microenterprises.

The technical reference used in practice is the harmonized European standard EN 301 549, which largely adopts the WCAG success criteria at level AA. In other words, the operational target for teams is unchanged: WCAG 2.x level AA, applied seriously.

I am not going to invent deadlines and article numbers here. What matters is the trend: requirements are expanding from the public sector into the private one, and procurement passes them down the supplier chain. If you sell software or websites to large companies, this will show up in tender documents regardless of what the law says directly about you.

Set the moralizing aside. An accessible site delivers measurable things.

• A larger audience: the share of adults in Europe living with some form of disability is comparable to the biggest market segment you are already targeting. Add the older population, which has money and shops online.
• Better usability for everyone: the same improvements raise form and checkout completion rates. A clear error message is a conversion fix wearing an accessibility badge.
• Fewer support requests: every phone call that starts with I cannot find the button costs more than the development hour that would have prevented it.
• Access to contracts: public tenders and large enterprise buyers ask for conformance explicitly. Without it you do not even reach evaluation.
• Reduced risk: complaints and lawsuits already exist in several markets, and their cost dwarfs any preventive remediation budget.

The difference between a cheap project and an expensive one here is not the team's talent, it is when the question gets asked. Building it into the process looks like this.

In the wireframe: you settle the logical content order and heading hierarchy before colors exist. If the structure makes sense as a plain document, you are already halfway there.

In visual design: you pick the palette and type scale while checking contrast on the spot, not afterwards. You draw the states explicitly — hover, focus, active, disabled, error — and put them in the design file as variants, not as margin notes. You fix minimum target sizes in the grid.

In the component system: you solve accessibility once, at component level, and inherit it across every page. A correct button, form field, modal and menu are the highest-return investment available. It is exactly the logic described in the piece on building a design system for a small brand.

In the definition of done: a task is not finished until somebody has walked it with the keyboard. Full stop. This is not a separate QA phase, it is part of what shipped code means.

In content: whoever writes copy gets simple rules for image alternatives, link names and heading structure. Most accessibility problems in a mature site come from content added after launch, not from the template.

The part many designers take longest to accept is that accessibility does not narrow your options, it removes the weak ones. Mandatory contrast pulls you out of the gray-on-gray zone where interfaces go when they want to look elegant without deciding anything. The need for clear hierarchy forces you to state what matters on the screen — the exercise every overloaded page avoids. Focus states force you to design the interaction, not just the resting image. And the ban on encoding meaning through color alone pushes you toward better labels and microcopy.

These constraints work like meter in poetry: they feel like a burden until you notice they strip out the noise and demand precision. The best interfaces I have built are not accessible in spite of their visual rigor. They are accessible because of it.

If you want to see what that looks like in delivered work, the examples are in the portfolio. And if you already have a site and do not know where to start, one hour spent walking your main flow with the keyboard will tell you more than any automated report — and you are welcome to get in touch if you want an opinion grounded in evidence rather than assumptions.