A website can look polished and still be difficult to use. A customer who cannot navigate with a keyboard, read low-contrast text, understand a form error, or zoom on a phone may be unable to complete a basic task. Accessibility is the work of reducing those barriers so people with different abilities and ways of interacting can use your site.
For a small business, accessibility is both a customer experience concern and a practical design discipline. You do not need to begin with a large redesign. Start by finding the tasks that matter most—understanding an offer, requesting an estimate, booking an appointment, or completing a purchase—and check whether people can complete them in different ways.
This guide explains the foundations, common barriers, a useful review checklist, and the limits of automated testing. It is educational guidance, not a determination of legal compliance.
What website accessibility means
Web accessibility means designing and building websites so people can perceive, understand, navigate, and interact with them. This includes people with permanent disabilities, temporary injuries, age-related changes, and situational constraints such as glare, noise, a small screen, or one hand being occupied.
The Web Content Accessibility Guidelines (WCAG) provide a shared technical framework. WCAG 2.2 organizes success criteria under four principles: content should be perceivable, operable, understandable, and robust. The criteria have A, AA, and AAA conformance levels. W3C advises using the latest WCAG version when developing or updating accessibility policies; WCAG 2.2 is the current recommendation at the time of writing. W3C’s WCAG 2.2 standard explains the criteria and conformance model.
WCAG is a useful implementation reference, but a checklist alone cannot tell you whether a real customer can successfully use your site. Accessibility depends on how content, design, code, and user tasks work together.
Why accessible design matters to a business
Accessibility can improve the experience for customers who rely on assistive technology, and it can make common tasks clearer for many other visitors too. Captions help people who cannot hear audio and people watching without sound. Clear form labels help screen-reader users and anyone returning to a form later. Keyboard support helps people who cannot use a mouse and people navigating with alternative input devices.
There is also a business risk in leaving barriers unresolved: some people may abandon a task, contact support for help, or choose another provider. The size of that effect depends on the audience and the specific barrier. Do not assume that an accessibility change will produce a particular conversion increase without measuring it.
Automated audits are valuable for finding detectable issues, but their results are not a complete measure of accessibility. WebAIM’s 2025 Million report found detectable WCAG failures on 94.8% of the one million home pages it scanned. That is a large automated sample, but it does not mean 94.8% of all pages fail every accessibility requirement: the scan covers home pages, and automated checks cannot identify every barrier or understand whether a task works in context. WebAIM Million 2025.
A practical accessibility checklist
Use this as an initial review of important pages and customer tasks. It is not a certification or substitute for a complete evaluation.
1. Check keyboard navigation
Unplug or avoid the mouse and use the keyboard to move through the page with Tab and Shift+Tab. Use Enter or Space to activate controls, and arrow keys where the interface calls for them.
- Can you reach every navigation item, link, button, form field, and dialog control?
- Is the focus indicator visible at every step?
- Does focus move in a logical reading and task order?
- Can you close menus and dialogs with a keyboard?
- When a dialog opens, does keyboard focus move into it and return to the initiating control when it closes?
- Can you avoid repeated navigation and reach the main content?
A pointer-only interaction—such as a hover menu with no keyboard equivalent—can block access to important pages. WCAG 2.2 includes a focus-visible criterion and requirements for focus not being obscured. See W3C’s Focus Visible guidance and Focus Not Obscured.
2. Make text and controls understandable
- Use a clear heading hierarchy that reflects the page structure.
- Give links descriptive text that makes sense when read on its own; avoid relying on “click here.”
- Ensure the page can be zoomed and reflowed without losing content or forcing unnecessary horizontal scrolling.
- Use sufficient contrast between text and its background. WCAG AA generally requires a contrast ratio of 4.5:1 for normal text and 3:1 for large text, subject to the criterion’s exceptions. Use the W3C contrast guidance and verify actual colors rather than judging by appearance alone.
- Do not communicate status or meaning by color alone. Pair color with text, an icon, or another visible cue.
- Make buttons and links large enough to use comfortably, especially on touch screens. WCAG 2.2’s minimum target-size criterion specifies 24 by 24 CSS pixels or sufficient spacing, with defined exceptions; larger targets are often easier to use. W3C Target Size (Minimum).
3. Review images, video, and other media
- Give informative images concise alternative text that conveys their relevant purpose.
- Use empty alternative text for decorative images so assistive technology can skip them.
- Avoid placing essential text only inside an image.
- Provide captions for prerecorded video with meaningful speech or sounds.
- Provide transcripts where they help people access audio content, and ensure media controls work from a keyboard.
- Check that charts and diagrams have their key information explained in text nearby.
Alternative text is contextual. A photo of a storefront might need a description if the location is important to the page; a decorative flourish should not create noise for a screen-reader user. The goal is equivalent information, not a literal description of every visual detail.
4. Test the forms that generate leads or sales
Forms are often where an otherwise usable page breaks down. Check your contact, quote, booking, newsletter, and checkout flows from start to finish.
- Provide a visible label for each field; a placeholder is not a lasting substitute for a label.
- Identify required fields in text, not only with color or an asterisk whose meaning is unclear.
- Explain the expected format for details such as phone numbers or dates.
- If a submission fails, identify the field and describe how to correct it in text.
- Preserve information already entered when an error occurs.
- Announce success or error messages in a way assistive technology can detect.
- Ensure CAPTCHA or spam prevention has an accessible alternative.
- Confirm that keyboard focus and screen-reader output follow the form’s visual order.
The W3C Forms Tutorial covers labels, instructions, validation, and grouping. Its labels guidance shows why programmatically associated labels matter in addition to visible presentation.
5. Check mobile and motion behavior
- Test menus, dialogs, cookie notices, and sticky elements at narrow widths and with zoom enabled.
- Check that fixed banners do not cover the currently focused control.
- Make sure functionality does not depend on a precise gesture such as dragging when a simpler alternative can be provided.
- Respect reduced-motion preferences for nonessential animation.
- Confirm that orientation changes do not hide core functionality.
A responsive layout is not automatically an accessible layout. Small controls, clipped dialogs, and focus indicators hidden behind sticky headers can remain problems on a page that technically fits the screen.
Automated tools: useful, incomplete
Automated tools can quickly detect some issues, such as missing accessible names, certain contrast failures, invalid markup patterns, or absent form labels. They are useful during development and for repeatable checks after changes.
They cannot reliably decide whether alternative text is meaningful, whether headings make sense, whether keyboard focus order is logical for the task, whether instructions are understandable, or whether a screen-reader user can complete an end-to-end workflow. A clean scan therefore means only that the tool did not find the issues it knows how to detect.
Combine several methods:
- Run an automated scan on key templates and high-value pages.
- Navigate key flows using only a keyboard.
- Zoom and reflow the page, and test it on a phone.
- Use a screen reader for representative tasks when possible.
- Ask people with relevant disabilities to evaluate important journeys when the project and resources allow.
- Record findings, severity, affected task, and retest status so fixes can be maintained.
W3C’s preliminary accessibility checks are a useful first pass, but W3C explicitly presents them as an initial review rather than a complete evaluation.
Prioritize fixes by customer impact
Small businesses often have limited development time. Rank issues by whether they block a critical task, how many users or pages they affect, and how confidently you can fix them. A useful first queue is:
| Priority | Example | Why it matters |
|---|---|---|
| Blocker | A keyboard user cannot submit the contact form | A core customer task is unavailable |
| High | Text or controls have inadequate contrast across the site | Content may be difficult to perceive on many pages |
| High | A menu or dialog traps focus or cannot be operated without a pointer | Navigation or key information becomes inaccessible |
| Medium | Images have generic or missing alternative text | Relevant information may be lost to assistive technology |
| Medium | Heading structure is inconsistent on long pages | It becomes harder to scan and navigate by section |
| Ongoing | New content or components introduce regressions | Accessibility can degrade during routine updates |
Start with a few representative templates: the home page, a service page, a contact or booking flow, and any high-traffic resource page. A shared header or form component may affect many URLs, so fixing it can improve multiple journeys at once.
A maintenance process that fits a small team
Accessibility works best as a normal part of publishing and development rather than a one-time cleanup. Before launching a page, check headings, links, image descriptions, color contrast, keyboard operation, mobile layout, and form feedback. When shared components change, retest the flows that use them.
Keep a short issue log with the page or component, the user task affected, the observed barrier, its priority, the owner, and the retest result. Pair automated scans with manual checks. If you use a design system, include accessible states and interaction behavior in component documentation so every new page does not need to solve the same problem again.
Track operational measures that help the team act: unresolved high-priority barriers, time to resolve them, regressions found before versus after release, and task completion issues reported by customers. These measures do not prove legal conformance or quantify the full experience, but they can reveal whether accessibility is becoming part of the process.
Frequently Asked Questions
Quick answers to common questions about this topic.
A plugin may add features or help detect certain issues, but it cannot reliably repair every design, content, code, and interaction barrier. Evaluate the actual user journeys and underlying page behavior.
Conclusion: make important tasks usable by more people
A practical accessibility effort begins with customer tasks, not a badge or a single scan. Make navigation operable by keyboard, give forms clear labels and useful error messages, ensure text and controls are perceivable, and test pages at mobile sizes and zoom levels. Use automated tools to find repeatable problems, then check the experience manually.
The strongest next step for most small businesses is to identify one valuable journey—such as requesting a quote—and test it from beginning to confirmation using a keyboard and a mobile device. Fix barriers that block the task, record what changed, and repeat the review as the site evolves. If you need help reviewing a website’s structure or implementing improvements, Avisul’s website development and support services can be a starting point for a conversation.
References and further reading
Standards and official guidance
- World Wide Web Consortium. (2023). Web Content Accessibility Guidelines (WCAG) 2.2. W3C Recommendation. Defines conformance levels and success criteria used throughout this guide.
- World Wide Web Consortium. (n.d.). What's New in WCAG 2.2. W3C WAI. Summarizes criteria added in WCAG 2.2.
- World Wide Web Consortium. (n.d.). Understanding Success Criterion 1.4.3: Contrast (Minimum). W3C WAI. Explains text contrast requirements and their exceptions.
- World Wide Web Consortium. (n.d.). Understanding Success Criterion 2.4.7: Focus Visible. W3C WAI. Explains the requirement for visible keyboard focus.
- World Wide Web Consortium. (n.d.). Understanding Success Criterion 2.4.11: Focus Not Obscured (Minimum). W3C WAI. Covers focus visibility when other content may overlay a control.
- World Wide Web Consortium. (n.d.). Understanding Success Criterion 2.5.8: Target Size (Minimum). W3C WAI. Describes minimum target dimensions and exceptions.
- World Wide Web Consortium. (n.d.). Forms Tutorial. W3C WAI. Practical guidance for accessible form design and implementation.
- World Wide Web Consortium. (n.d.). Labels. W3C WAI. Explains visible and programmatic form labeling.
- World Wide Web Consortium. (n.d.). Easy Checks: A First Review of Web Accessibility. W3C WAI. Offers preliminary checks and explains their limited scope.
Industry research
- WebAIM. (2025). The WebAIM Million: The 2025 Report on the Accessibility of the Top 1,000,000 Home Pages. WebAIM. Reports findings from automated scans and documents the study's scope and limitations.
Suggested internal reading
- Core Web Vitals for Small-Business Websites connects technical performance with user experience.
- Accessibility review guide provides a companion checklist for reviewing a site.
Every business and project is different. Treat this as general planning guidance, then confirm platform-specific, legal, tax, and security requirements with the appropriate provider or qualified professional.