Accessibility Is a Design Requirement, Not a Checkbox

Accessibility Is a Design Requirement, Not a Checkbox

Accessibility is often scheduled as a review near the end, which guarantees the worst possible outcome: findings that require reworking components already built and shipped. In practice almost every accessibility decision is made during design, and the ones made then cost close to nothing.

Contrast and colour

Text that does not stand out from its background is unreadable for a substantial share of visitors, and the fix is a token change if it is caught at the design stage. Colour alone cannot carry meaning: status, error and selection all need a second signal, which is a design decision about shape or text, not a code fix.

Focus and keyboard order

Every interactive element needs a visible focus state, and the order of tabbing should follow the order of the page. These are properties of the component set: build them once, and every screen inherits them. Add them later and each screen becomes its own investigation.

Structure and language

Real headings in a real hierarchy, labels tied to inputs rather than placeholders standing in for them, buttons that say what they do, error messages that name the field and the fix. This is writing and markup, decided during design, and it is what makes an interface usable with a screen reader or with the keyboard alone.

Motion, resize and zoom

Respect reduced-motion preferences, do not trap content in fixed sizes, and confirm the layout survives two hundred percent text size. Again: properties of the layout system, not patches.

What it buys you

Beyond inclusion, better outcomes for everyone using the product on a small screen, in bright light, one-handed, or in a hurry. It also intersects with performance and with search visibility.

How we build it

Component-level checks are part of testing at Black Origin IT, which is the cheapest point at which they can be verified.

Rethinking an interface? Tell us about your project and we will build the accessibility in.