Is an accessible website only of use to people with disabilities?

The range of people who benefit is far wider than most assume. Alongside users with visual, hearing, or mobility impairments, it includes older people whose eyesight has declined with age, anyone looking at a phone in bright sunlight where contrast falls away, anyone on public transport without headphones who therefore needs captions, anyone with a temporary hand injury who can only use a keyboard, and anyone on an unstable connection whose images never load. Put differently, accessibility deals with the full range of less-than-ideal conditions — and everyone falls into some of them at some point. That makes it closer to baseline quality than to a value-added service for a particular group.

Will accessibility make the site ugly, or restrict what the designers can do?

Most of the perceived conflict comes from a misunderstanding. Accessibility asks for things to be perceivable and operable; it does not dictate a color palette or a layout. What genuinely gets ruled out is a handful of specific habits: small light-gray text on a white background, using color alone to indicate status with no supporting text or icon, styling buttons so they do not look clickable, and motion effects that play automatically and cannot be paused. All of those make the site harder for ordinary users to read and operate anyway. State the accessibility conditions during the design phase and designers have ample room to work; it is only when the work is retrofitted afterwards that it feels constraining.

Does bringing an existing site up to standard mean rebuilding it?

Usually not. In practice you start with the handful of items that have the greatest effect without touching the architecture: add alternative text to images, correct text and buttons with insufficient contrast, associate form fields properly with their labels and hints, confirm that every function can be completed with a keyboard alone, and make the focus position clearly visible. Most of that sits at the level of styles and markup. What genuinely warrants folding into a redesign is a confused navigation structure, or a layout that replaces text with images so assistive tools cannot read the content at all. The sensible approach is to audit first, then decide what to repair now and what to defer to the next redesign.

Web Accessibility: Why It Pays and How to Check

A user who cannot see the screen operates your website by having screen reader software read it aloud. If your button carries only an icon and no text, what they hear is the single word “button” — and they have no idea whether it adds an item to the cart or deletes an order.

That is the kind of problem web accessibility addresses. It sounds like a compliance item that only public-sector bodies need to worry about, but it is simultaneously improving something every business cares about: how many people can successfully complete the action you want them to complete.

What accessibility actually addresses

Accessibility means enabling users with different abilities, on different devices, in different circumstances, to obtain information and complete tasks. The guidelines referenced internationally group this under four principles, which in plain language come down to:

They can see it or hear it: information must not be conveyed through a single sense alone. Images need text descriptions; video needs captions.
They can operate it: a mouse cannot be the only option — every action must also be completable with a keyboard.
They can understand it: interface behavior should be predictable, and error messages should be written in human language.
It is compatible: content must be interpretable by screen readers and other assistive tools.

Not one of those four is a “special requirement”. They are simply good interface design.

One common misconception is worth clearing up first: accessibility does not mean building a separate accessible version of the site. In most cases it means getting the markup and styles right on the same site, rather than maintaining two sets of content — the latter doubles the cost and, over time, lets the two versions drift further and further apart.

Why it pays

Audience reach

Far more people benefit than you would expect, and most of them would never describe themselves as disabled users: older people whose eyesight has declined, people looking at a phone in strong sunlight, people on public transport without headphones who need captions, people with a temporary hand injury who can only use a keyboard. Every circumstance your site fails to accommodate is another group of visitors who cannot convert.

Search performance

A lot of accessibility practice overlaps naturally with search engine optimization: alternative text helps search engines understand what an image contains, a clear heading hierarchy lets machines read the structure of a page, and captioned video with a transcript provides text that can be indexed. This is part of why accessible sites tend to fare better when it comes to having their content understood and cited; for the related content planning logic, see how to run a brand blog.

Everyday usability

Text with adequate contrast is easier to read, clear form error messages mean fewer mistakes, keyboard operation makes experienced users faster, and a clean heading hierarchy lets people scan straight to the section they want. All of these improvements work for everybody — nobody just tends to mention them.

The regulatory direction

Requirements around the accessibility of digital services continue to increase internationally, and public-sector and certain industry procurement processes generally already include them. No specific provisions are cited here, because the rules are updated; confirm the scope that actually applies to you against the latest guidance from the competent authority, and take legal advice where necessary. The principle to plan around is this: treat it as a direction that will keep tightening, and do not wait to be asked.

The five most common problems

One: insufficient color contrast

Light gray text on white, or a brand-colored button with white text where the two are close in brightness — this is the single most widespread problem in practice, and the cheapest one to fix.

How to check it: use an online contrast checker, enter the text color and the background color, and the tool will tell you directly whether it passes. Running your brand palette through it during the design phase saves every argument that would otherwise follow.

A related problem is using color alone to convey meaning, such as red and green to distinguish order statuses. Users who perceive color differently cannot tell them apart; add text or an icon alongside.

Two: it cannot be operated with a keyboard

Walk through your entire website using the Tab key. The typical problems you will find:

Some buttons cannot be reached (because they are images or divs rather than actual buttons)
When you land on an element you cannot tell where the focus is (the focus outline has been removed by the styles)
After a modal opens, focus stays on the page behind it, or the modal cannot be closed
Drop-down menus only expand on mouse hover

This test requires no tools and takes you five minutes, and the problems it catches are often the most severe ones.

Three: images without alternative text

Alternative text (alt text) is the written description of an image, for people and machines that cannot read the image itself. Three mistakes recur: nothing written at all, the file name used as the description, or every image described simply as “image”.

The rule for judging it: if the image conveys information, describe that information; if it is purely decorative, mark it as decorative. A product image should describe the product and the setting; for a chart, put the key figures in text alongside it.

Four: forms that are hard to complete

The form is the last mile of conversion, and the place where accessibility problems most readily cause concrete losses:

Field labels are not correctly associated with the input, so the screen reader cannot announce what the field is for
Placeholder text is used as the label, and disappears the moment typing begins
Errors are indicated only by a red border, with no text explaining what is wrong
Required fields are marked only with an asterisk, with no supporting text
No clear success message after submission

Five: video and audio without captions or alternatives

Video needs captions (not only for users who are deaf or hard of hearing, but for anyone in a quiet or noisy environment). Audio-only content should come with a transcript. Media that plays automatically should be pausable. Where motion effects are strong, the system’s “reduce motion” setting should be respected.

How to check it at acceptance

Writing accessibility into acceptance works the same way as writing speed into acceptance: the point is to convert a vague requirement into checks somebody can actually perform. A workable acceptance checklist:

Check	How to verify it
Color contrast	Run body text, buttons, and form fields through a contrast checker
Keyboard operation	Complete the main flows with the keyboard only (browse, search, fill in, submit)
Visible focus	As you Tab through, the current position is obvious at a glance
Alternative text	Spot-check each category of image and confirm the descriptions are meaningful
Heading hierarchy	Heading levels descend in order, without skipping levels or being used as styling
Form labels	Every field has a correctly associated label and error message
Media	Captions, transcripts, and the ability to pause
Automated scanning	Run a testing tool across the main pages and work through the report

Automated tools only catch a portion of the problems — a machine can determine contrast ratios and missing markup, but not whether the alternative text is well written or whether the flow makes sense — so manual checking cannot be skipped. The sensible approach uses both: the tool sweeps a large number of pages for obvious faults, and a person walks the main flows.

For how to write acceptance criteria into a specification document, see how to write a software requirements specification.

Get a real user to try it once

A checklist catches problems at the level of rules. It cannot catch the situation where every rule passes and the site is still painful to use. If circumstances allow, ask someone who routinely uses a screen reader or magnification to walk through your main flow. Half an hour of that is usually worth more than an entire report.

The next best substitute is an internal simulation: turn the screen brightness to its lowest, set the system font to its largest, unplug the mouse and use the keyboard only, then ask a colleague who was not involved in the build to place an order or submit an inquiry. Wherever they get stuck is what needs fixing.

How to think about the cost

The cost of accessibility depends almost entirely on when you start thinking about it.

Built into the design phase: most of the work is a series of choices — pick a palette with adequate contrast, make buttons look like buttons, give form fields labels. The additional hours are limited.

Retrofitted after development: styles have to be revisited, structure changed, components rebuilt. The cost rises noticeably, the blast radius is wide, and the risk is higher.

Addressed years after launch: this generally gets folded into a redesign, because the return on fixing it in isolation does not compare well with restructuring the whole thing.

So the most economical moment is always the design phase of the project in front of you. That is also why it is worth listing as an explicit condition during requirements discovery rather than raising it the week before acceptance. For how overall build costs are composed, see how website costs are calculated.

NETVANA’s software development process runs design first and only begins development once the interactive prototype is confirmed, which is the point at which accessibility adjustments cost least. During development we work in two-week sprints and provide a working demo each cycle, which also means problems like keyboard operation — the kind you only find by actually using the thing — surface early.

Accessibility is neither charity nor pure compliance overhead. It deals with the fact that some people wanted to use your service and were blocked by the interface — and the people who were blocked do not write in to tell you. They simply leave.

If you want to establish how your current site performs, or you want these conditions written clearly into the specification for a new project, talk to NETVANA about your requirements. NETVANA’s software services are quoted after an initial consultation; for what each service includes and delivers, see the software services overview.

Further reading: the other half of page quality is speed, covered in the website speed optimization guide. For the structure of build costs and what drives them, see how website costs are calculated. And for a method of writing requirements and acceptance criteria clearly, see how to write a software requirements specification. For the redesign checklist to run alongside accessibility fixes, see The Website Redesign SEO Checklist.