Editorial illustration; it does not depict a specific website or user.
Published on October 23, 2026.
A website can look polished in a design review and still be frustrating to use. A menu may only open with a mouse. A form may show an error in red without explaining it. A light-grey paragraph may be technically present but practically unreadable. A product image may carry important information that never reaches someone using a screen reader.
Accessibility is not a final coat of paint. It is the habit of making content and controls usable by people with different ways of seeing, hearing, moving, reading and interacting with technology. It also helps people who are temporarily distracted, using a small screen, working in bright sunlight or navigating with a broken trackpad.
Quick Answer
Start with a short manual check before reaching for a large audit tool:
- Move through the page using only the keyboard.
- Check that headings, links, buttons and form labels explain themselves.
- Confirm that text remains readable when zoomed and that colour is not the only signal.
- Review alternative text, captions and error messages.
- Test the real task on a phone and with the browser’s built-in accessibility features.
No single automated scanner proves that a page is accessible. Automated tools are useful for finding patterns, but a person still needs to try the page as a person would.
1. Begin with the task, not the checklist
Pick one important journey: reading an article, finding a product, submitting a contact form, booking an appointment or signing in. Write down the expected path in plain language.
For example: “A visitor can open the menu, find the pricing page, choose a plan and submit the enquiry form.” That gives you something concrete to test. A page can pass an isolated colour check and still fail the actual journey because the focus disappears or the next action is unclear.
Ask what information the visitor needs at each step. If a button says “Click here”, the label does not tell anyone what will happen. “Download the pricing guide” is more useful in a visual scan, a screen reader’s link list and a keyboard-only journey.
2. Use headings as a map
Headings are not merely large text. They describe the structure of the page. Use one clear page heading, then organise sections under it in a sensible order. Do not choose a heading level only because its font size looks attractive.
A good outline might be:
H1: Choosing a website plan
H2: What each plan includes
H3: Storage and bandwidth
H3: Support options
H2: How to choose
H2: Frequently asked questions
The exact visual design can be changed with CSS. The document structure should remain meaningful when the styling is removed or a user navigates by headings.
3. Make keyboard use a first-class test
Put the mouse aside. Press Tab to move forward, Shift + Tab to move backwards, Enter to activate a link or button, and the arrow keys where a control supports them. At every point, ask three questions:
- Can I see which element has focus?
- Is the focus order logical?
- Can I reach and operate the control without a pointer?
An invisible focus outline is a common mistake. A custom design may replace the browser outline with a subtle border that disappears against the background. Keep a visible, high-contrast focus style. If a modal opens, move focus into it and return focus to the triggering control when it closes.
Do not turn a non-interactive div into a pretend button with a click handler unless there is a strong reason. A real <button> already communicates its role, supports keyboard interaction and works better with assistive technology.
4. Write useful labels and instructions
Every form control needs a label that remains understandable outside its visual position. Placeholder text is not a durable replacement for a label: it disappears as soon as the user starts typing and may have weak contrast.
If a field has a constraint, state it before the user makes a mistake. “Password, at least 12 characters” is more helpful than showing a generic “Invalid input” after submission. When validation fails, identify the field, explain the problem and give the user a direct way to correct it.
Error messages should not depend only on colour, animation or an icon. Use text, connect it to the relevant field and make sure the message can be found by someone who navigates sequentially.
5. Treat images as information
Alternative text should answer the question: what does a person need to know from this image in this context? A photo of a damaged cable in a troubleshooting guide might need alt="Frayed power cable near the connector". A decorative background may need empty alternative text so it is ignored.
Do not stuff keywords into alt text or describe every visual detail when it does not help the task. If a chart contains important numbers, provide the takeaway in nearby text or a data table; a short label alone cannot replace the chart’s meaning.
Videos need captions when speech matters. Transcripts can make audio content searchable and useful in quiet environments. If an animation communicates a change, provide a text explanation or an accessible status message as well.
6. Check colour, zoom and reflow
Colour can support meaning, but it should not be the only way to communicate it. “The fields in red are incomplete” should become “Email address is required”, with colour as an additional cue.
The W3C Web Accessibility Initiative recommends sufficient contrast and notes that content should remain usable when text is enlarged or the viewport becomes narrow. Test a page at increased browser zoom and on a small screen. Look for clipped buttons, horizontal scrolling, overlapping dialogs and text hidden behind fixed headers.
Do not solve every layout problem by disabling zoom. Responsive design, flexible text and sensible wrapping are usually better fixes than forcing a fixed canvas.
7. Use semantic HTML before adding ARIA
Semantic HTML gives browsers and assistive technology useful information about a page. Use headings for headings, lists for lists, links for navigation and buttons for actions. Add ARIA only when the native element cannot express the required pattern.
An ARIA label cannot repair a control that cannot be reached, has no visible focus state or does the wrong thing when activated. A complicated widget also needs a tested keyboard interaction model, not just a role attribute.
When a component is built from a framework, inspect the rendered HTML rather than trusting the component name. The browser receives the output, and that output is what users interact with.
8. Test the complete flow with real content
Short placeholder text hides problems. Test long names, translated labels, empty states, validation failures, slow connections and a form that has already been submitted. Check whether the page remains understandable when one image fails to load.
Try the journey with a keyboard and, where possible, a screen reader. You do not need to become an accessibility specialist before finding obvious problems. Can you tell what the page is for? Can you find the main navigation? Can you identify the focused control? Can you understand the form error? These answers reveal more than a perfect-looking screenshot.
Common mistakes to avoid
The most common failure is treating accessibility as a plugin badge or a single automated score. Another is adding an “accessibility menu” while leaving the underlying HTML unusable. A font-resizing widget cannot fix missing labels, an impossible focus order or a button that only responds to a mouse click.
Avoid testing only the happy path. The difficult states—an expired session, a failed upload, a required field, a closed menu or a dialog that opens after a delay—are where people are most likely to lose context.
Also avoid promising that a site is “fully accessible” based on a quick check. Accessibility depends on the content, components, browsers and assistive technologies involved. Describe what you tested and keep improving.
My Take
The best accessibility work is usually ordinary engineering done with more care: meaningful HTML, clear writing, visible focus, resilient layout and errors that help instead of blame. These choices rarely make a dramatic demo, but they prevent the quiet abandonment that analytics may only show as a visitor who never completed a task.
I would add one accessibility check to every feature’s definition of done. Then I would schedule a short end-to-end manual test for the site’s most important journey. Small, repeated checks are more realistic—and more effective—than waiting for a once-a-year audit.
Bottom Line
Make the purpose of each page clear, give every control a usable name, preserve keyboard access, keep text readable, describe meaningful images and test real journeys with real content. Start with one important task today. An accessible website is not a special version of the experience; it is a website that gives more people a fair chance to complete the same task.