A prospective customer should not have to use a mouse, distinguish subtle shades of grey, hear a video, or process a dense page quickly to understand what you offer. Yet those assumptions still find their way into otherwise polished websites. What makes a website accessible is not a single feature or a badge in the footer. It is the practical work of making content, controls and journeys usable by people with different access needs.
For founders and product teams, that matters because accessibility affects who can enquire, sign up, buy, get support or complete a task without help. It also tends to produce clearer interfaces, better technical SEO and fewer frustrating edge cases for everyone. The best time to address it is while decisions about content, design and architecture are still easy to change — the same thinking behind a good product discovery workshop.
What makes a website accessible?
An accessible website allows people to perceive, understand, navigate and operate it using the tools and methods that work for them. That may mean a keyboard instead of a mouse, a screen reader instead of a screen, voice control, browser zoom, captions, reduced motion settings, or simply more time and clearer language.
The widely used technical benchmark is the Web Content Accessibility Guidelines, usually shortened to WCAG. For most business websites and web applications, WCAG 2.2 AA is a sensible build target. It gives a detailed, testable standard, and if you want the full list of criteria in one place, our WCAG 2.2 AA compliance checklist works through it section by section. WCAG should not, however, be confused with a complete user experience strategy. A site can technically pass individual checks and still be difficult to use if its forms are confusing or its language is needlessly complex.
Accessibility is therefore both an engineering discipline and a product discipline. The engineering provides correct HTML, predictable behaviour and compatibility with assistive technology. The product work makes sure the task itself is understandable.
Start with semantic, properly structured content
A browser and a screen reader need more than visual styling to understand a page. A heading that merely looks large is not equivalent to a real heading in the underlying HTML. A clickable div is not automatically a button. These details determine whether someone can move through a page efficiently, discover a control and understand its purpose.
Use one clear page heading, then organise the content with a logical heading hierarchy. Mark navigation as navigation, main content as main content, and supplementary material as complementary content where appropriate. Use real buttons for actions such as opening a menu or submitting a form, and real links when moving someone to another location.
This is especially relevant in React and Next.js builds, where teams can create attractive custom components quickly. A component library should preserve native behaviour rather than replace it. If a custom select menu, modal or tab panel is harder to operate than the browser’s native alternative, its visual polish is not worth the trade-off.
Good structure also benefits technical SEO. Search engines and assistive technologies both gain useful signals from clear headings, meaningful link text and properly labelled content — much of it overlaps with the checks in our technical SEO checklist. The objectives overlap, but neither should be treated as a shortcut for the other.
Write content that does not rely on guesswork
Accessible content is specific. “Click here” gives little context when read out of place. “View our web application development process” tells the reader where the link leads. Similarly, form instructions should explain what is required before a user makes an error, not only afterwards.
Plain English helps, particularly on high-stakes pages such as sign-up, account access and support. This does not mean flattening your message into bland copy. It means avoiding unexplained acronyms, long multi-part instructions and calls to action that leave the next step ambiguous.
Make every interaction work without a mouse
Keyboard access is one of the quickest ways to reveal whether an interface has been built carefully. Pressing Tab should move through interactive elements in a logical order. The currently focused item must be clearly visible. Enter and Space should activate controls in the expected way, and keyboard users must be able to close menus, dialogs and overlays.
A common failure is the mobile navigation that works perfectly with a pointer but traps keyboard focus behind an open panel, or loses focus entirely when it closes. Another is a modal window that visually appears on top of the page while keyboard focus remains in the content beneath it. These are not rare edge cases. They stop users completing core journeys.
When building custom interactive components, test the full lifecycle: opening the component, moving within it, making a selection, receiving any validation message and returning to the right place afterwards. Native HTML controls handle much of this for free. Custom behaviour should be introduced only when it solves a genuine user need.
Use colour, contrast and layout with care
Colour can support meaning, but should never be the only way meaning is communicated. An error state that changes from green to red needs accompanying text, an icon or another clear indicator. A chart should not rely solely on coloured lines to distinguish categories.
Text and essential interface elements also need sufficient contrast against their backgrounds. Pale grey body copy, low-contrast placeholder text and subtle focus outlines are frequent problems because they can look restrained on a designer’s monitor while becoming unreadable in real conditions.
There is a balance to strike. Not every decorative element requires the same contrast treatment, and forcing contrast into every brand flourish can make a design heavy. The practical question is whether a person needs that element to read content, understand status or operate the interface. If they do, make it clear.
Responsive layouts need similar scrutiny. Users may zoom text substantially, use a narrow viewport, or enlarge browser text without changing the rest of the page. Content should reflow without horizontal scrolling for ordinary reading, controls should remain usable, and text should not be clipped by fixed-height containers.
Provide alternatives for images, video and motion
Images need text alternatives when they convey useful information. The right alternative describes the image’s purpose in context, rather than mechanically listing what it contains. An image that is purely decorative should be hidden from screen readers so it does not create noise.
For video, captions help people who are deaf or hard of hearing, people watching without sound, and anyone trying to follow a speaker with an unfamiliar accent. A transcript is often valuable where the spoken content contains detail users may want to search, review or quote. If important information appears only on screen, it needs an equivalent description too.
Movement needs restraint. Auto-playing carousels, animated counters and decorative effects can distract users and make content harder to follow. Respect reduced-motion preferences and ensure a user can pause, stop or hide motion where necessary. Animation can add character, but it should not block comprehension or control.
Build forms that explain themselves
Forms are where accessible website design becomes directly commercial. A visitor may understand your service, want to contact you, and still abandon the process because a field has no clear label or an error message is vague.
Every input needs a visible label. Placeholder text is not a replacement because it disappears once a user starts typing and is often low contrast. Explain unusual formatting requirements before submission. Where a field has an error, identify the field, explain what needs changing and move focus or announce the error in a way assistive technology can detect.
Be cautious with aggressive validation. Checking an email address while a person is still entering it, for example, can create distracting messages. Validate at useful moments and use wording that helps someone recover: “Enter a work email address in the format [email protected]” is more useful than “Invalid input”.
Test with people, not only automated tools
Automated accessibility checks are worthwhile. They can catch missing labels, invalid attributes, some contrast issues and other repeatable defects quickly. They cannot reliably tell you whether the heading order makes sense, a checkout flow is understandable, or a keyboard user can complete a complex task without confusion.
A sensible testing routine includes:
- checking key pages with keyboard-only navigation;
- reviewing headings, landmarks and form labels with a screen reader;
- testing at browser zoom and on smaller screens;
- running automated checks in development and before release; and
- involving people with relevant access needs when the product or journey is significant.
The final point is the one teams skip most often. Lived experience reveals problems that a checklist cannot. It is particularly valuable for products with repeated, complex or time-sensitive workflows. If you would rather have this checked independently, it is worth understanding what a website accessibility audit service finds before you commission one, so you know what depth of review you are actually buying.
Treat accessibility as part of delivery, not a late fix
Retrofitting accessibility is possible, but it is more expensive in attention and disruption than building it into the system. Design tokens should include accessible colour choices. Component acceptance criteria should cover keyboard behaviour, focus states and labels. Content editors need guidance, because a well-built site can still become inaccessible through vague links, uncaptioned media or poorly structured pages.
There are trade-offs. A highly bespoke interface may need more testing than a simpler pattern. An embedded third-party tool may have limitations you cannot fully control. In those cases, identify the risk early, choose the most accessible option available and provide a workable alternative route rather than quietly accepting a broken journey.
At DELLIUX, WCAG 2.2 AA is considered alongside performance, SEO and maintainable code from the start of every website and web application build. That does not mean adding compliance theatre. It means making everyday product decisions that let more people use the service you have invested in.
If you are planning a new website or reviewing an existing one, start with the journeys that matter most: finding information, contacting your team, creating an account, completing a form and getting support. Ask whether each journey works without sight, sound, a mouse or perfect concentration. The answers will usually point to the next useful improvement.
If you want a second opinion on where your site currently stands, book a free consultation and we will talk through the priorities for your specific product.
