Accessibility for Developers: Building Inclusive Code
Developers are the architects of accessibility at the implementation level. While designers set the visual and interaction foundations, it is the code that ultimately determines whether a website works with keyboard navigation, communicates properly with screen readers, and maintains accessibility across browsers and devices.
The good news is that most accessibility best practices align with general best practices for clean, semantic, standards-compliant code. Writing accessible code is not about adding complexity — it is about writing code correctly in the first place.
Semantic HTML First
The single most impactful thing you can do for accessibility is to use semantic HTML elements correctly. HTML5 provides a rich vocabulary of elements that carry inherent meaning and accessibility features. A <button> element is automatically focusable, activatable with keyboard, and announced as a button by screen readers. A <div> with an onclick handler has none of these features without significant additional work.
Use <nav> for navigation regions, <main> for the primary content, <header> and <footer> for their respective sections, <section> and <article> for content areas, <h1> through <h6> for headings in correct hierarchical order, <ul> and <ol> for lists, <table> with <th> for tabular data, <label> with for attributes for form controls, and native <button> and <a> elements for interactive controls.
These elements create an accessibility tree that assistive technologies use to present your content to users. When you use them correctly, much of accessibility is handled automatically.
Heading Structure
Headings create the structural outline of your page. Screen reader users frequently navigate by headings to understand content organization and find specific sections. Each page should have exactly one <h1>, and headings should follow a logical hierarchy without skipping levels — an <h3> should not follow an <h1> without an <h2> in between.
Never use heading elements for visual styling. If you need large bold text that is not a heading, use CSS on a different element. Conversely, if content functions as a heading, mark it up as one regardless of its visual presentation.
Keyboard Accessibility
All functionality must be operable through a keyboard interface alone. This means every interactive element — links, buttons, form controls, menus, modals, sliders, tabs — must be reachable via the Tab key (or Shift+Tab for reverse), activatable with Enter or Space, and escapable where appropriate.
Never create keyboard traps where users can tab into an element but cannot tab out of it. Modal dialogs should trap focus within the dialog while open and return focus to the triggering element when closed, but pressing Escape should always dismiss the dialog.
Ensure focus order follows a logical sequence that matches the visual layout. The DOM order should generally match the visual presentation. Avoid using positive tabindex values, which override natural focus order and create confusion. Use tabindex="0" to make non-interactive elements focusable when necessary, and tabindex="-1" for elements that should be focusable only programmatically.
Page Language
Set the default language of every page using the lang attribute on the <html> element. This tells screen readers which pronunciation rules to use. If the language changes within the content — for example, a French phrase within an English page — mark the change with a lang attribute on the containing element.
Form Accessibility
Forms are where users provide input, and they are a frequent source of accessibility failures. Every form control must have a programmatically associated label, typically using the <label> element with a for attribute matching the control's id. Group related controls using <fieldset> and <legend>.
When input errors are detected, identify the field in error and describe the error in text. Provide suggestions for correction where possible. For fields that accept specific formats, provide clear instructions about the expected format. Use the autocomplete attribute to enable browser autofill for common fields like name, email, address, and phone number.
Status messages that do not receive focus — such as "item added to cart" or "3 results found" — must be announced to screen reader users through ARIA live regions or status roles.
Alternative Text
Every non-decorative image must have meaningful alternative text that describes its content or function. For informative images, describe what the image conveys. For functional images (such as a logo that links to the homepage), describe the function. For decorative images that add no information, use an empty alt attribute (alt="") so screen readers skip them entirely.
Complex images like charts, graphs, or diagrams may need longer descriptions provided through a caption, adjacent text, or linked detailed description.
WAI-ARIA
The Accessible Rich Internet Applications specification provides additional semantics for situations where native HTML is insufficient. ARIA allows you to communicate roles, states, and properties to assistive technologies for custom widgets and dynamic content.
However, ARIA should be used judiciously. The first rule of ARIA is: if you can use a native HTML element that has the semantics and behavior you need, do so. ARIA does not add functionality — it only adds semantics. A <div role="button"> still needs JavaScript for keyboard handling, whereas a native <button> handles it automatically.
Use ARIA landmark roles (or their HTML5 equivalents) to define page regions. Use aria-label and aria-labelledby to provide accessible names where visible text is insufficient. Use aria-expanded, aria-selected, aria-checked, and other state attributes to communicate the current state of interactive widgets. Use aria-live regions to announce dynamic content updates.
Responsive Design and Reflow
Content must be presentable without loss of information at 320 CSS pixels width without requiring horizontal scrolling. This ensures that users who zoom to 400% on a standard desktop display can still access all content. Design your layouts to reflow content into a single column at narrow widths rather than requiring scrolling in two dimensions.
Skip Links
Provide a mechanism for keyboard users to bypass repeated blocks of content, such as navigation menus, and jump directly to the main content. The most common implementation is a "Skip to main content" link that is the first focusable element on the page and becomes visible when focused.
Developer's Testing Checklist
Before deploying any feature, verify: all functionality works with keyboard alone; focus order is logical; focus is visible on all interactive elements; all images have appropriate alt text; all form controls have labels; page language is set; heading hierarchy is correct; ARIA is used correctly and only when necessary; content reflows at 320px width; and dynamic content updates are announced to screen readers.
In this section
Is your website accessible?
Scan your website for free and get your WCAG compliance score in minutes.
Scan your site free