How should we build accessible components for our redesign?

Accessible components should use native browser elements and clear structure as their starting point, because browsers already support many inclusive interactions. A native `select` element, for example, can be reached with a keyboard without rebuilding that behaviour from scratch. Custom controls may be needed for a redesign, but they create a higher bar: the component must still work by keyboard and be recognised by screen readers.

Treat semantic HTML, keyboard accessibility, contrast and clear input behaviour as component requirements, not polish for later. A design system becomes more useful when its defaults make the accessible choice the easy choice, while still leaving room for the visual ideas that give a brand its character.

Accessible UX improves when designers and developers shape components together from the earliest design choices through to implementation. Early collaboration catches practical barriers before they become expensive custom fixes, from low-contrast text to controls that work with touch but not a keyboard.

Review each important component in the contexts people actually use. A website may be opened on a phone in bright sunlight, over a slow connection, with a keyboard instead of a mouse, or through a browser that reads page content aloud. Consider different devices, input methods, connectivity and browser behaviour as part of the redesign brief. Inclusion is easier to build when technical constraints inform the design, and design intent stays involved through development.

Accessibility overlays and automated remediation cannot make an inaccessible component genuinely accessible when the underlying HTML and interaction design remain broken. A widget may create the appearance of a fix while leaving screen-reader compatibility, keyboard accessibility and structural barriers unresolved.

Automation and AI still have a useful role. AI code assistants can help teams create accessible patterns, and image analysis can help generate more meaningful alt text. The opportunity is to use those tools for the repeatable baseline, then keep human judgement focused on whether the experience works for people with different needs. A fully customised dropdown, for example, needs deliberate support for mouse, keyboard and voice users rather than a quick layer added at the end.

We believe accessible components are a design and development responsibility from the first sketch onwards. The strongest redesigns do not treat inclusion as a final compliance task or a widget to install. They bring technical thinking into creative decisions early, then carry design intent through implementation.

We have put that approach into practice by involving developers from the beginning of work on This is IBM, helping shape choices around colour contrast, device behaviour and different input methods before execution created unnecessary barriers. That collaboration gives teams more clarity about what is possible, practical and inclusive. For us, accessible UX is not a constraint on good creative work. It is part of making digital experiences clearer, more useful and more human.