Accessible Web Design: What It Means in Practice

Accessibility is often described as a compliance obligation. It is more usefully described as a quality standard: the same practices that make a site usable with a keyboard or a screen reader make it easier for everyone.

In practice it is a long list of small engineering decisions rather than one large one, and the expensive moment to make them is after launch, once the markup, the stylesheet and the component library have been shaped around choices nobody re-examined.

None of it depends on a certificate. Conformance with a published accessibility standard is something a team assesses and documents about its own work. It is not granted by an outside body, and nobody can certify a site on another team’s behalf without actually testing it.

Start with structure

Using the correct elements for headings, lists, navigation and forms gives assistive technology a usable document for free. A heading marked up as a heading communicates the structure of a page to someone navigating by heading, not just visually. This is the highest-value work and it costs the least.

A heading is an outline, not a font size

What makes text a heading is the element it uses, not how large it has been set. Six type sizes and no heading elements gives a screen reader user one flat block of prose, because nothing in the markup says where one thought ends and the next begins. Getting the levels to follow the document order is the change with the highest return of any on this list.

Pick elements for what they do

A link navigates somewhere; a button acts on the page you are already on. Confusing the two is expensive, because a link opened in a new tab cannot be reached by a keyboard user who has just triggered it. A navigation menu is a list of links inside a navigation region, which is what lets somebody skip it, and data in columns belongs in a table with header cells. Semantic markup also survives a redesign, which hand-built layouts do not.

Give every control a name

A control with no accessible name is announced as “button” and nothing more, which makes a form containing several of them unusable. The name should come from a real label element wherever possible, because that also gives a larger target on a touch screen and stays put when the design changes. Where a label has to be hidden for visual reasons, hide it from the page but not from assistive technology.

Placeholders look like labels and are not labels. They vanish at exactly the moment somebody needs them, and they are usually designed to sit quietly on the background, so they fail a contrast check too. Icon-only controls need names; decorative icons beside real text need hiding from assistive technology rather than announcing themselves as “icon”.

Errors a person can act on

An error message has to say what went wrong and what to do about it. Colour on its own says something is wrong and nothing more, so pair it with text, associate that text with the field, and move focus to the first thing needing attention after a rejected submission. Keep the values the person already typed; clearing a long form because one field failed loses a customer who had done everything right. Related controls belong in a labelled group, and the autocomplete attributes should be filled in.

Everything must work from the keyboard

If a control cannot be reached and operated with a keyboard, it does not exist for a meaningful number of users. That includes menus, modals, tabs and anything that appears on interaction. A visible focus state is not optional; without it a keyboard user has no idea where they are.

What gets missed

Menus that trap focus. Modals that never return focus to the control that opened them, so the next keypress lands somewhere unrelated. Tabs where the arrow keys do nothing. Carousels that capture focus as they rotate. Consent banners sitting over the first heading. Controls built as a div with a click handler, invisible to a keyboard and silent to a screen reader. A skip link to the main content is one line of markup and saves somebody tabbing through the whole navigation on every page.

Two related problems travel with these. When the visual order and the order in the markup disagree, focus appears to jump around the page and nobody can follow it, which is fixed by reordering the markup rather than by positioning with CSS. And anything appearing only on hover is absent altogether for anyone on a touch screen: menus and tooltips should also appear on focus and stay while focus is inside them. The cheapest way to find all of it is to put the mouse down and try to finish the task, which is part of what happens during front-end development before a build is called finished.

Contrast is a design constraint

Text needs enough contrast against its background to be readable in daylight on a mediocre screen. The thresholds are well defined and worth testing rather than estimating.

The published figures are 4.5:1 for normal body text, 3:1 for large text as defined by size and weight, and 3:1 for the boundaries of interactive components and for the focus indicator. Treat them as a floor rather than a target, because a muted grey on white that measures just under the line is exactly what fails outdoors on a cheap panel. Confirm the numbers against the current published document and the level you have agreed to build to, since they differ between versions.

Where it usually fails: placeholder text, light grey labels on a coloured button, white text on a pale tinted banner, placeholder content in a card grid that was never replaced, and text over a photograph, which needs a solid layer behind it because the image changes. Dark mode doubles the work, since a palette tuned for white rarely survives on near-black.

Do not disable what you cannot style

Browsers provide default focus rings, autocomplete and error behaviour that exist for good reasons. Overriding them for visual reasons frequently removes functionality. If a default is visually unacceptable, replace it with something that looks better and works the same way.

The usual offenders

• Removing the focus outline and putting nothing back, the most common single failure on otherwise careful sites.
• Rebuilding a select, date picker or dropdown from divs, so the native control and its touch, keyboard and assistive technology behaviour disappear with it.
• Stripping list semantics from a navigation menu because the bullets were unwanted, rather than hiding the markers.
• Hiding a real heading because it did not match the mock-up, leaving the page with no outline at all.
• Disabling zoom or user scaling in the page header, which removes the feature from the people who most need magnification.
• Opening links in a new tab without saying so, so somebody who has navigated through several pages discovers they have lost the ones behind them.

Small targets are the quieter problem. A close button a few pixels across is hard to hit with a tremor and worse on a moving train, so interactive elements need enough size and enough space around them. Replacing a platform component also carries a hidden invoice, since a custom date picker has to reimplement everything the browser was doing for free. Decisions of that kind sit naturally in UI and UX design work, because the reason to make them is nearly always visual.

Images, media and anything that moves

Every image needs a decision. An image that carries information needs alternative text describing what it conveys rather than what it depicts: “submit button” tells a reader nothing, while “choose your bank” on a form tells them everything. A purely decorative image gets an empty alternative attribute so it is skipped rather than announced by filename. An image made of text fails in almost every context, search engines included. Charts need a text equivalent carrying the same conclusion, because a caption repeating the title does not.

Video, audio and motion

Captions are a translation with a technical delivery attached: the file, the timing, the player controls, and the contrast of caption text against whatever is moving behind it. Audio needs a transcript, anything starting by itself must be stoppable, and a play button still needs a name. Motion needs the same treatment differently: carousels, parallax and animated backgrounds all require a way to be stopped, none should move text somebody is reading, and the reduced-motion preference in a visitor’s own system settings is worth honouring because honouring it costs a media query. If a carousel genuinely carries content, it needs controls, a pause and a non-rotating fallback.

Where a user is: titles and landmarks

A page that changes its content without changing its title fills the browser history with identical entries and tells a screen reader user nothing about where they have gone. Titles should say what the page is and, where it helps, which part of it they are in.

Landmarks do the same job at page level: mark the header, navigation, main content and footer once each, and label them where a page carries more than one of a kind. Main matters most, since it is how somebody skips everything else in a single keystroke. The heading outline handles navigation within the page. This is also what a template change tends to strip out, which is a good reason to check after every significant release.

Test with the tools, then with people

Automated tools find a meaningful portion of problems quickly and are worth running on every build. They do not find the rest. A short session with someone who uses assistive technology daily reveals the issues that matter.

What a checker finds

Missing alternative text, fields with no label, contrast failures, jumps in heading order, duplicate identifiers, links whose text says nothing, and a fair share of keyboard traps if the tool is allowed to drive the page rather than only read it. They are cheap and repeatable, which is why they belong in the build pipeline: a regression then appears in the week it was written.

What it cannot find

Whether the heading outline tells a coherent story. Whether the reading order matches the visual order. Whether an error message is comprehensible to somebody who has never seen the form. Whether the focus indicator is visible on that particular background. Whether the video has captions at all. A checker compares markup against a rule; it cannot tell you whether the result is usable by a person.

Testing with people

Book a session with somebody who uses a screen reader or a switch device daily, and pay them for their time. It is worth doing even if the team turns assistive technology on itself, because reading a report is not the same as completing a checkout with a magnifier and a keyboard. Test the journeys rather than the pages: signing up, paying, submitting an enquiry, recovering from a rejected form. Record what was found, fix it, test again. Some issues come back, and that is maintenance rather than failure.

None of this produces a claim anybody grants. A conformance statement is written by the team that built the site, describing the standard it aimed at, what was tested and what was found outstanding. It is not an award, and a badge reading “fully accessible” tells a visitor nothing they can rely on.

Keeping it from slipping back

Accessibility degrades quietly. A component library update, a marketing page built from an unchecked template, a new consent banner, a chat widget with a video feed in it. Each is small, and together they undo months of careful work.

Put a short checklist alongside the rest of the acceptance criteria, so it forms part of what ready means rather than a favour somebody does when there is time. Fix things in the system rather than on the page, because a correction applied to one template is overwritten the next time the template changes, while the same correction applied to the button component repairs every button on the site, including the ones added next year by somebody who has never heard of this.

Retrofitting a live site means re-testing everything already there, which is more work than doing it as you build. If a site has to be repaired after launch, start with an audit of the existing site and work down a prioritised list: keyboard operation first, then form labels and error handling, then contrast, then focus visibility. Third-party widgets deserve their own decision, since chat tools, map embeds and consent banners all arrive carrying their own markup. Agree which are permitted and who checks a new one before it reaches a page.

None of this needs a large budget or a special week. It needs the requirements written down, tested on a schedule, and the fixes made in shared code. Ask for the accessibility decisions to be included in the written scope, alongside the rest of the project’s commitments, and they get made as a matter of course. When SmartEdge IT Solutions builds a site, these decisions are made during design and recorded, rather than left for someone to raise after launch.