How to build accessible web applications: a practical frontend tutorial

Accessibility is not a feature it's a fundamental quality of a web application. Building accessible applications from the start costs less than retrofitting accessibility later, and it improves the experience for all users, not just those with disabilities. Accessibility is good engineering.

Start with semantic HTML. Use button for buttons, a for links, nav for navigation, main for main content, and h1-h6 for headings in hierarchical order. Semantic HTML provides built-in keyboard navigation, screen reader support, and SEO benefits. A page with good semantic HTML is already partially accessible before you write any ARIA.

Use ARIA attributes only when semantic HTML is insufficient. ARIA modifies how an element is exposed to assistive technology, but it doesn't change the element's behavior. The first rule of ARIA is: don't use ARIA if you can use a native HTML element that has the semantics and behavior you need. Overusing ARIA creates more problems than it solves.

Ensure keyboard accessibility for all interactive elements. Every interactive control should be reachable and operable with the keyboard alone. Use tabindex thoughtfully: tabindex="0" makes an element focusable, tabindex="-1" removes it from the tab order but allows programmatic focus. Avoid positive tabindex values. Test your application using only the keyboard to find gaps.

Provide sufficient color contrast. Text should have a contrast ratio of at least 4.5:1 against its background. Large text (14pt bold or 18pt regular) needs at least 3:1. Tools like the WebAIM Contrast Checker help validate your color choices. Good contrast benefits all users, especially in bright environments or on low-quality displays.

Design for screen readers by providing descriptive alt text for images, labeling form inputs properly, and using ARIA live regions for dynamic content updates. Test with an actual screen reader like VoiceOver, NVDA, or JAWS automated tools catch only a fraction of accessibility issues. There is no substitute for testing with real assistive technology.

Create a focus-visible indicator that works with your design. Users who navigate with the keyboard need to see where focus is at all times. Never set outline: none without providing an alternative focus indicator. A visible focus ring is essential for keyboard users and benefits users with cognitive disabilities.

Test accessibility as part of your development workflow. Use axe-core or Lighthouse for automated checks during development. Include keyboard and screen reader testing in your QA process. Accessibility bugs should be treated with the same priority as functional bugs. Accessibility is not optional it's a requirement for reaching all users.

-

Rizwan Saleem | https://rizwansaleem.co