A digital product can look clear to a sighted designer and remain difficult or impossible to use for someone with low vision, colour-vision deficiency or blindness. Accessibility asks the team to consider how people perceive, understand and operate the experience through different senses, devices and assistive technologies.

This is not a separate layer added after the interface is finished. Structure, content, interaction and implementation all affect whether the product works for more people.

How visually impaired users may experience a website

Some users enlarge text or magnify part of the screen. Others change colours and contrast, navigate with a keyboard, use a refreshable braille display or listen to content through a screen reader. A screen reader presents the interface in a linear order and relies on the underlying structure and accessible names rather than visual position alone.

That means a visually obvious layout may be unclear when read sequentially. A button labelled “Click here,” an unlabeled icon, a form error shown only in red or a modal that traps keyboard focus can block a task even when the screen appears polished.

Use semantic structure, not visual styling alone

Headings, landmarks, lists, buttons, links and form labels communicate the purpose and relationship of content to assistive technology. Styling a paragraph to look like a heading does not give it heading semantics. Making a generic element look like a button does not automatically give it the expected keyboard behaviour.

Practical design guidance

Do not rely on colour alone

Colour is useful for emphasis and status, but it should not be the only way information is conveyed. A red border without a message may not explain which field is invalid. Green and red chart lines may be indistinguishable to some users.

Combine colour with text, icons, patterns or another persistent cue. Check foreground and background contrast, including text on images, placeholder text, focus indicators and disabled states. Remember that a contrast checker cannot decide whether the overall hierarchy or language is understandable.

Design forms that explain and recover

Forms combine labels, instructions, validation, status messages and focus management. Small gaps can make the whole task fail.

Accessible form checklist

Write useful alternative text

Alternative text should communicate the purpose or information of a meaningful image in its context. It does not need to list every visible detail. Decorative images that add no information should generally have empty alternative text so they do not create noise.

Charts, diagrams and screenshots may need a nearby explanation when a short alt attribute cannot convey the full information. Buttons made from icons need accessible names that describe the action.

Support zoom, reflow and responsive layouts

People with low vision may enlarge text or zoom the page significantly. Interfaces should reflow without forcing constant horizontal scrolling or hiding important controls. Avoid fixed containers that clip text, and test what happens when headings, buttons and error messages become longer.

Responsive design should account for content adaptation, not only common device widths.

Understand the WCAG principles

The Web Content Accessibility Guidelines organise accessibility around four principles: content and interfaces should be perceivable, operable, understandable and robust. These principles are often abbreviated as POUR.

Use the current W3C WCAG guidance as the technical reference rather than treating a short checklist as complete compliance advice.

Test beyond an automated score

Automated checks are useful for detecting certain missing attributes, contrast problems and structural errors. They cannot determine whether every label is meaningful, a workflow makes sense or a status change is understandable.

A practical testing sequence

  1. Navigate the main task using only the keyboard.
  2. Check visible focus and logical focus order.
  3. Zoom and resize text; inspect reflow and clipping.
  4. Review headings, landmarks, labels and alternative text.
  5. Test critical flows with a screen reader.
  6. When possible, include disabled people in usability testing.

Accessibility is part of product quality

Accessible design tends to make structure, language, states and interactions more explicit. Those improvements can help people using a small screen, dealing with glare, recovering from an injury or navigating under time pressure—not only people who identify as disabled.

If you need help reviewing an existing interface or designing an accessible product foundation, let’s discuss the product.

Frequently asked questions

Is accessibility only the developer’s responsibility?

No. Designers influence contrast, hierarchy, focus behaviour, labels, instructions and interaction patterns. Writers influence clarity. Developers implement semantics and behaviour. Accessibility is a shared product responsibility.

Does passing an automated accessibility test mean a website is accessible?

No. Automated tools can identify some technical issues, but manual review and task-based testing are needed to evaluate meaning, interaction and usability.

Should every image have descriptive alt text?

No. Meaningful images need an appropriate text alternative. Purely decorative images should usually be ignored by assistive technology rather than described.

Leave a Reply

Your email address will not be published. Required fields are marked *