Accessibility (a11y) for Web

Accessibility means the site can be used by people with disabilities – visual, motor, hearing or cognitive. Good a11y improves the experience for everyone: clearer structure, better keyboard navigation, readable text.

Core practices

Semantic HTML: use <header>, <nav>, <main>, <button>, <label> instead of divs and spans for everything. That way screen readers and browsers understand roles.
Alt text for images: describe content for those who can’t see the image. Decorative images: alt="" or role="presentation".
Contrast: text must have sufficient contrast against the background (WCAG recommends at least 4.5:1 for normal text).
Keyboard navigation: all interactive elements should be reachable with Tab and have a visible focus style. Don’t remove outline without an alternative.
Forms: associate label with input (for/id), show errors clearly and suggest correction.

Tools

Lighthouse (in DevTools) has an accessibility audit. axe DevTools or WAVE help with detailed analysis. Test with a real screen reader (NVDA, VoiceOver) or at least keyboard-only navigation.

Want an accessible, semantically correct site? Contact us.

Frequently asked questions

Why care about accessibility?

Millions rely on screen readers, keyboard or zoom. An accessible site is better for everyone and in many countries is a legal requirement for public and commercial sites.

What are the main steps?

Semantic HTML (header, nav, main, button, label), alt text for images, sufficient contrast, focus on Tab, test with keyboard and screen reader (or tools like axe).

What is ARIA?

ARIA (Accessible Rich Internet Applications) are attributes that add role and state information for assistive tech. Use them when semantic HTML isn’t enough, not as a replacement.