Structure and navigation
Use semantic HTML to express headings, lists, regions, buttons, links, and tables. A visual style alone does not communicate structure to assistive technology.
- Give each page a descriptive title and a clear main heading.
- Nest section headings logically and identify navigation and main content.
- Provide a working skip link for repeated navigation.
- Keep reading order meaningful when layout styles change.
- Use link text that describes its destination or purpose.
- Make repeated navigation and help consistent.
Official guidance: Page structure tutorial
Images, graphics, and tables
Describe an image according to its purpose in context. For a linked icon, communicate the action; for a chart, communicate the important information and provide accessible data or a fuller explanation.
- Use an empty text alternative for purely decorative HTML images.
- Keep essential words as real text rather than embedding them in graphics.
- Give data tables meaningful headers and associate them with data cells.
- Describe complex diagrams in nearby text where a short alternative is insufficient.
- Do not rely on position, shape, or color alone to explain an action.
Official guidance: Images tutorial
Contrast, zoom, and reflow
Ordinary text generally needs a contrast ratio of at least 4.5:1; qualifying large text needs 3:1. Large text means at least 18 points, or 14 points when bold. Exceptions include logos and certain incidental or inactive text. Meaningful graphics and control boundaries have their own non-text contrast requirements.
Support text resizing and user spacing preferences without losing information or controls. For typical vertically scrolling content, test reflow at a width equivalent to 320 CSS pixels. Two-dimensional content such as complex tables may qualify for an exception; the surrounding page should still adapt.
Official guidance: Text contrast
Official guidance: Reflow
Keyboard, touch, and speech
- Test all functionality with the keyboard, including menus, dialogs, media players, and uploads.
- Keep focus visible and move it intentionally when opening or closing dialogs.
- Ensure users can leave every component without a keyboard trap.
- Provide alternatives to complex gestures and dragging where required.
- Make visible control labels part of their accessible names so speech users can identify them.
- Allow enough target size or spacing for accurate pointer use.
Forms and authentication
Associate each field with a clear label. Group related controls, explain required formats before entry, and identify errors in text with useful correction instructions.
- Preserve entered information after validation errors where possible.
- Announce success, loading, and error states appropriately.
- Allow review and correction of important submissions.
- Support password managers and paste.
- Offer accessible authentication and recovery methods.
- Warn users about session timeouts and allow extension where required.
Official guidance: Forms tutorial
Dynamic content and third parties
Prefer native controls. When custom controls are necessary, expose their name, role, state, and value and implement their expected keyboard behavior. ARIA does not automatically add interaction or keyboard support.
Test live search, filters, modal dialogs, consent banners, shopping carts, payment tools, and embedded support tools. A third-party component can block the complete task even when the surrounding page works.
Clear content and controlled motion
Use plain language, descriptive headings, manageable steps, and predictable behavior. Explain unfamiliar terms and let people recover from mistakes. Some of these practices improve access beyond minimum AA requirements.
Let people pause, stop, or hide applicable moving content. Avoid unsafe flashing and distracting autoplay. Respect reduced-motion preferences as a design practice.
Before you publish
- Complete the main task using only a keyboard.
- Inspect heading structure, labels, alternatives, and errors.
- Check zoom, narrow layouts, contrast, and user text spacing.
- Test with representative screen readers and browsers.
- Ask disabled participants to evaluate realistic tasks.