A team is ready to launch a new website. The design is sleek, the animations are smooth and the copy is sharp. Then a user who navigates with a keyboard tries to reach the main menu and gets stuck in a carousel. Another user with low vision cannot read the light gray text on a white background. A screen reader user hears “button, button, button” with no explanation of what any of them do. The site looks finished, but many people cannot use it.

Accessibility problems are easier and cheaper to fix before launch than after. This checklist walks through the most important areas to review, from visual design and keyboard use to forms, media, mobile and testing, so you can launch with confidence.

Why Accessibility Matters

Accessibility means making products usable by people with a wide range of abilities, devices and situations. That includes people with visual, hearing, motor and cognitive disabilities, as well as people using small screens, slow connections, bright sunlight or a single hand.

Benefits of reviewing accessibility before launch

• Wider audience: more people can use and buy from your product.
• Better usability for everyone: clear structure, readable text and logical flows help all users.
• Lower legal and reputational risk: many regions have accessibility laws and expectations, so check what applies to you.
• Better SEO and performance: semantic structure, descriptive text and clean code often help search engines too.
• Lower cost: fixing issues early is much cheaper than rebuilding later.

Understanding the Standards

Most teams use the Web Content Accessibility Guidelines (WCAG) as the main reference. WCAG organizes requirements around four principles, often summarized as POUR.

WCAG has conformance levels (A, AA and AAA), and many organizations target Level AA. Standards and legal requirements change and differ by region, so confirm which version and level apply to your product with qualified specialists.

How to Use This Checklist

• Review in layers: design, content, code and testing.
• Test with real tools: use a keyboard, a screen reader and zoom.
• Combine automated and manual checks: automated tools catch only a portion of issues.
• Include people with disabilities: their feedback is the most valuable.
• Record and prioritize issues: label them critical, important or minor.

1. Visual Design and Color

2. Keyboard Accessibility

Many users cannot use a mouse, so every action must work with a keyboard.

• All interactive elements are reachable: links, buttons, menus, forms and custom controls.
• Logical tab order: focus moves in a sensible, predictable sequence.
• Visible focus indicator: users always know where they are.
• No keyboard traps: users can move in and out of modals, menus and widgets.
• Skip links: a way to jump past repeated navigation to the main content.
• Custom components behave like native ones: correct keys for menus, tabs, dialogs and sliders.
• Shortcuts do not conflict: avoid single-key shortcuts that interfere with assistive technology, or allow them to be turned off.

3. Screen Reader and Semantic Structure

Screen reader users depend on code that describes content accurately.

Use native HTML elements wherever possible, since they come with built-in accessibility. Add ARIA attributes carefully, only when needed, because incorrect ARIA can make things worse.

4. Images, Icons and Graphics

• Meaningful alt text: describes the purpose or content of informative images.
• Decorative images are hidden from assistive tools: use empty alt text where appropriate.
• Icons have labels: icon-only buttons have accessible names.
• Complex images have descriptions: charts and diagrams include a text alternative or summary.
• Text in images is avoided: use real text whenever possible.
• Logos have appropriate alt text: usually the organization’s name.

5. Forms and Inputs

Forms are where accessibility problems often cause the most harm.

6. Video, Audio and Motion

7. Content and Language

• Plain language: short sentences, familiar words and clear structure.
• Descriptive headings and labels: make scanning easy.
• Consistent terminology and navigation: reduces cognitive load.
• Abbreviations explained: spell out unusual terms on first use.
• Link purpose is clear: from the link text or its context.
• Avoid vague instructions: do not rely on “see the green button” or “on the right.”
• Reading level suits the audience: consider simplified summaries for complex content.

8. Navigation and Wayfinding

• Consistent navigation: appears in the same place across pages.
• Multiple ways to find content: menus, search and sitemaps where appropriate.
• Clear current location: active states and breadcrumbs help orientation.
• Predictable behavior: links and controls do what users expect.
• Meaningful page titles and headings: help users confirm they are in the right place.
• Helpful 404 and error pages: guide users back to useful content.

9. Mobile and Touch Accessibility

10. Components and Design Systems

Reusable components multiply accessibility, for better or worse.

• Build accessibility into components: states, focus styles, labels and keyboard behavior.
• Document usage: include guidance on contrast, content and behavior.
• Test components in isolation and in context.
• Avoid copying inaccessible patterns: review carousels, modals, tooltips, accordions and custom dropdowns carefully.
• Maintain a pattern library: so fixes propagate everywhere.

11. Testing Methods

No single test finds every problem, so combine methods.

A structured UX audit can combine expert review with usability findings to identify accessibility and usability issues across the whole experience before launch.

12. Documentation and Accessibility Statement

• Accessibility statement: describe your commitment, known limitations and contact methods.
• Feedback channel: make it easy for users to report problems.
• Response process: know who handles reports and how quickly.
• Internal guidelines: document standards for designers, developers and content writers.
• Training: help teams understand accessibility basics.

Common Accessibility Mistakes

Prioritizing Fixes Before Launch

A collaborative design thinking workshop can help teams align on accessibility priorities and build shared responsibility across design, development and content.

Learning from Real Users

Checklists catch known issues, but real people reveal surprises. UX research that includes participants with diverse abilities shows how people actually use your product, which guides better fixes than guesswork.

Final Pre-Launch Accessibility Checklist

• Does text and key UI meet contrast requirements?
• Is color never the only way to convey meaning?
• Can every function be used with a keyboard, with visible focus?
• Are headings, landmarks and links meaningful for screen reader users?
• Do all images, icons and graphics have appropriate text alternatives?
• Are forms labeled, with clear instructions and helpful errors?
• Do videos have captions, transcripts and, where needed, audio descriptions?
• Is motion controllable and respectful of user preferences?
• Does the experience work on mobile with touch, zoom and screen readers?
• Are components documented and tested for accessibility?
• Have you tested with automated tools, manual checks and real users?
• Do you have an accessibility statement and a way for users to report issues?

Getting Started

You do not need to fix everything at once. Run keyboard and screen reader checks on your most important journeys, fix critical issues first and build accessibility into your design and development process going forward. If you want expert help reviewing your product and turning research into inclusive, polished experiences, a specialist team offering UI/UX design services can help you move faster with less risk.

Final Thoughts

Accessibility is not a final polish step. It is part of building products that work for the people who use them. Review visual design, keyboard access, structure, forms, media, mobile experience and content, test with a mix of tools and real people, and keep improving after launch. Teams that treat accessibility as a continuous practice build products that are more usable, more trusted and open to more people.

FAQs

What should an accessibility checklist include?

It should cover visual design and contrast, keyboard access, screen reader support, semantic structure, images and alt text, forms, media captions, motion, mobile use, content clarity and testing with real users.

Which accessibility standard should I follow?

Most teams follow WCAG, often targeting Level AA. Legal requirements vary by region and industry, so confirm what applies to you with qualified specialists.

Can automated tools test accessibility completely?

No. Automated tools catch only a portion of issues, so combine them with manual checks, keyboard and screen reader testing and feedback from people with disabilities.

When should I start thinking about accessibility?

At the very beginning, during research and design. Building accessibility in from the start is far cheaper and more effective than fixing issues after launch.