ADA Website Accessibility Checklist for Small Businesses: What Should You Fix First?

Small businesses should fix accessibility barriers that prevent people from navigating, completing forms, making purchases, or contacting the company before addressing lower-impact issues. Start with keyboard access, visible focus, accessible names, form labels and error messages, then correct contrast, alternative text, headings, media, and documents. Automated testing can identify some problems, but manual review is required to prioritize repairs responsibly.

By Sebastian Pincetti, Partner, Digital Marketing Specialist, and AI Developer at SRP Communication & Brand Design. Published October 2, 2026. Last updated October 11, 2026.

Your next step: get started with SRP's free online Website Accessibility Audit for an automated home-page baseline. Then contact SRP if you need help interpreting the report or planning manual testing.

This checklist is built for business owners, CEOs, managers, and marketing decision-makers at companies with approximately 5 to 250 employees.

What Should a Small Business Fix First?

A small business should fix barriers that block essential customer journeys first. Severity depends on the page, the task, and the user impact. For example, a missing label on a newsletter field matters, but an unlabeled payment field or an inaccessible appointment form usually deserves faster attention.

Barriers like these are common. Detected WCAG 2 failures appeared on 95.9 percent of one million home pages, according to WebAIM (2026). In our own data, low color contrast affected 67 percent of the sites we scanned, according to SRP (237 scans, May to September 2026).

So use the following order as a practical starting point, then adjust it to the risks and services of your website.

• Critical task blockers. Repair anything that prevents a person from navigating, purchasing, booking, applying, signing in, submitting a form, or contacting the business.
• Keyboard and focus failures. Make every interactive control reachable and operable without a mouse. Ensure focus is visible and moves in a logical order.
• Forms, names, instructions, and errors. Give controls meaningful accessible names, connect labels to fields, explain required formats, and make validation errors understandable.
• Visual and content barriers. Correct insufficient contrast, information conveyed only by color, missing alternative text, unreadable zoom behavior, and content that does not reflow.
• Structure, media, and documents. Repair headings, page titles, landmarks, captions, transcripts, and important downloadable documents.
• Repeated template defects. Fix shared navigation, headers, footers, forms, and components before isolated page-level problems so one repair improves many pages.

Priority 1: Can Visitors Complete Essential Tasks?

Visitors must be able to complete essential tasks such as finding a service, submitting a form, booking an appointment, making a purchase, or contacting the company. Test the most important journeys before spending time on minor isolated defects.

• Navigation. Confirm that menus, dropdowns, dialogs, account controls, and skip links work with a keyboard and do not trap focus.
• Forms. Test labels, instructions, required fields, error identification, error recovery, and confirmation messages.
• Transactions. Review carts, checkout steps, calendars, payment fields, and time limits from beginning to end.
• Contact options. Make phone numbers, email links, location information, and contact forms easy to find and use.

Priority 2: Can the Website Be Used Without a Mouse?

A website can be used without a mouse when every important control is reachable and operable through a keyboard interface. Keyboard users also need a focus order that preserves meaning and a visible indication of which element has focus, according to W3C (2026).

• Use the Tab and Shift+Tab keys. Move through the page and confirm that focus follows a logical sequence.
• Use Enter, Space, and arrow keys. Operate links, buttons, menus, accordions, tabs, carousels, and form controls.
• Look for keyboard traps. Confirm that focus can enter and leave every component without forcing the user to refresh or close the page.
• Keep focus visible. Do not remove the browser's focus outline unless it is replaced with an equally clear indicator.
• Check what happens after an action. When a dialog opens or an error appears, move focus to a useful location and return it appropriately when the interaction ends.

Priority 3: Are Forms and Controls Properly Identified?

Forms and controls are properly identified when their purpose, name, state, and instructions are available visually and programmatically. Placeholder text alone is not a reliable substitute for a persistent label.

• Label every field. Associate visible labels with text fields, checkboxes, radio buttons, dropdowns, and other inputs.
• Name icon-only controls. Provide an accessible name for search, menu, close, play, account, and social-media buttons.
• Explain requirements before submission. Identify required fields, expected formats, and time limits before users encounter an error.
• Describe errors clearly. State what went wrong, identify the affected field, and explain how to correct it.
• Announce dynamic feedback. Ensure screen readers receive important status messages such as successful submission, loading, or validation results.

Priority 4: Can People Perceive the Content?

People can perceive the content when text, images, audio, video, and instructions have alternatives that match their purpose. Visual presentation must also remain readable when users zoom or change text settings.

• Check text contrast. WCAG 2.2 Level AA generally requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text, according to W3C (2026). Defined exceptions apply.
• Do not rely on color alone. Add text, icons, patterns, or another cue when color communicates status, errors, or required information.
• Write useful alternative text. Describe the purpose of informative and functional images. Use empty alternative text for decorative images when appropriate.
• Support zoom and reflow. Test enlarged text and narrow viewport widths without losing information, controls, or functionality.
• Provide media alternatives. Add accurate captions for prerecorded video with audio and transcripts or audio descriptions when the content requires them.

Priority 5: Is the Page Structure Clear?

The page structure is clear when headings, landmarks, lists, links, and page titles communicate how information is organized. Visual size alone does not create a meaningful heading hierarchy.

• Use one descriptive page topic. Write a clear page title and a primary heading that reflect the page's purpose.
• Organize headings logically. Use H1, H2, and H3 elements to represent sections and subsections, not simply to change font size.
• Use semantic elements. Mark lists, tables, navigation, main content, and forms with the appropriate HTML structure.
• Write descriptive links. Replace vague phrases such as 'click here' when the destination can be identified more clearly.
• Declare the page language. Identify the primary language in the page code and mark changes of language when needed.

What Can Automated Accessibility Testing Detect?

Automated accessibility testing can detect selected code-based failures consistently. Depending on the tool and page, checks may include missing alternative-text attributes, certain contrast failures, unlabeled controls, empty headings, invalid ARIA use, duplicate identifiers, and missing page-language attributes.

However, evaluation tools cannot determine accessibility by themselves, according to W3C (2024). Tools can assist with testing, but human judgment is required. Some results may also be false or misleading.

What Requires Manual Accessibility Testing?

Manual accessibility testing requires a person to evaluate meaning, sequence, interaction, and task completion. A reviewer should test representative templates and critical journeys, not only the home page.

• Keyboard behavior and focus order. Confirm that real interactions work from beginning to end.
• Screen-reader output. Check reading order, control names, states, instructions, status messages, and dynamic changes.
• Alternative-text quality. Decide whether the text communicates the image's purpose in its actual context.
• Content clarity. Review instructions, labels, link purpose, error messages, and understandable language.
• Mobile and responsive behavior. Test orientation, reflow, zoom, touch targets, and components at different viewport sizes.
• Documents and media. Review PDFs, captions, transcripts, audio descriptions, charts, maps, and other complex content.

Does Completing This Checklist Make a Website ADA Compliant?

Completing this checklist does not make a website ADA compliant. A checklist can help a business identify and prioritize common barriers, but it cannot evaluate every page, user journey, applicable legal requirement, or factual circumstance.

Businesses open to the public and state and local governments must make what they provide online accessible to people with disabilities, according to U.S. Department of Justice guidance (2026). The detailed Title II web rule for state and local governments adopts WCAG 2.1 Level AA. Its compliance dates fall in April 2027 or April 2028.

However, private businesses should not be treated as the same legal category. The Department's current Title III guidance does not prescribe one detailed technical standard for every business website.

So use qualified legal counsel for advice about a specific organization's obligations. Use accessibility specialists for technical evaluation, remediation, and verification.

How Can a Small Business Organize the Work?

A small business can organize the work in four steps over about 30 days, separating urgent blockers, repeated template problems, and longer-term improvements. Assign an owner, document the affected pages or components, and retest every repair.

1. Step 1, days 1 to 5, establish the baseline: List critical customer journeys, run an automated scan, and test the home page, navigation, contact form, and one important transaction with a keyboard.
2. Step 2, days 6 to 15, repair blockers: Fix keyboard traps, invisible focus, inaccessible forms, controls without names, and problems that prevent task completion.
3. Step 3, days 16 to 25, repair shared components: Correct templates, navigation, headings, contrast, and repeated form or component defects.
4. Step 4, days 26 to 30, verify and document: Retest the changes, record remaining limitations, assign future work, and add accessibility checks to content and development workflows.

How Should Accessibility Repairs Be Verified?

Accessibility repairs should be verified with the same method that exposed the problem and with an additional functional check when appropriate. Rerun automated rules, repeat keyboard and screen-reader tasks, and confirm that the repair did not create a new barrier elsewhere.

For example, keep a simple remediation record with the issue, affected page or component, severity, responsible person, repair date, testing method, result, and any remaining limitation. Documentation supports maintenance and makes future regression testing more efficient.

How Can You Check Your Website?

You can check your public home page with SRP's free online Website Accessibility Audit. The read-only scan reviews selected automated indicators and sends a prioritized report by email. Unlike an overlay widget that adds a layer on top of the page, the report points to the code that needs to be fixed. However, use the result as a baseline, not as a compliance certificate or a substitute for full-site manual testing.

For a detailed explanation of what automation can and cannot determine, read What Is a Website Accessibility Audit and What Can Automated Testing Find?.

Your next step: run the free audit on your home page, then contact SRP to plan manual testing of your most important customer journeys.

Frequently Asked Questions

What Is the First Accessibility Problem a Small Business Should Fix?

The first accessibility problem a small business should fix is any barrier that prevents a visitor from completing an essential task. Keyboard traps, inaccessible navigation, unlabeled transaction fields, and unusable contact or appointment forms commonly deserve urgent attention.

Should Every Accessibility Issue Have the Same Priority?

Every accessibility issue should not have the same priority. Evaluate severity, frequency, affected users, the importance of the task, and whether the defect appears in a shared component across many pages.

Can a Free Accessibility Scanner Test an Entire Website?

A free accessibility scanner may test one page or a limited set of public pages, depending on the tool. SRP's free audit scans the submitted public home page. A broader evaluation must include representative templates, critical journeys, documents, media, and authenticated content when relevant.

How Often Should a Small Business Review Accessibility?

A small business should review accessibility after major redesigns, new templates, important form or checkout changes, and significant content releases. Automated regression tests can run more frequently, while manual testing should be repeated after material interaction changes and on a planned schedule.

Should a Business Install an Accessibility Overlay?

A business should not treat an accessibility overlay as a substitute for repairing the underlying website. Evaluate any proposed product carefully, document what it changes, test the actual user experience, and continue correcting problems in the site's content, design, and code.

Methodology and Limitations

SRP's prioritization framework groups accessibility work by functional impact, critical customer journeys, repeated components, and verification needs. The checklist draws on WCAG 2.2 guidance, W3C evaluation resources, and current U.S. Department of Justice web-accessibility guidance.

The checklist is an educational planning tool. It does not evaluate every WCAG success criterion, determine legal compliance, replace a representative accessibility evaluation, or predict how every person with a disability will experience a website. Requirements and enforcement can vary by organization, jurisdiction, contract, and factual circumstances.

About the Author

Primary Sources

• World Wide Web Consortium. Web Content Accessibility Guidelines 2.2. Accessed October 2026.
• World Wide Web Consortium. How to Meet WCAG 2.2 Quick Reference. Accessed October 2026.
• World Wide Web Consortium. Selecting Web Accessibility Evaluation Tools. Accessed October 2026.
• World Wide Web Consortium. Easy Checks: A First Review of Web Accessibility. Accessed October 2026.
• World Wide Web Consortium. Involving Users in Evaluating Web Accessibility. Accessed October 2026.
• U.S. Department of Justice. Guidance on Web Accessibility and the ADA. Accessed October 2026.
• WebAIM. The WebAIM Million 2026. Accessed October 2026.
• U.S. Department of Justice. New Rule on the Accessibility of Web Content and Mobile Apps Provided by State and Local Governments. Accessed October 2026.