Website accessibility checklist for service businesses

An accessible website lets people with disabilities read your content, fill in your forms and book your services, whether they use a screen reader, a keyboard instead of a mouse, magnification or captions. For a service business, the website is often where a client first decides whether to contact you, so barriers there turn away real clients.

Most sites have work to do. WebAIM's 2026 Million report, which tests the home pages of the top one million websites each year, found detectable WCAG failures on 95.9% of home pages, with an average of 56.1 errors per page. Those are only the errors software can detect; manual testing usually finds more.

There is legal pressure too. The U.S. Department of Justice's guidance on web accessibility states its position that the ADA applies to the goods and services businesses open to the public offer on the web, and points to WCAG as a helpful technical standard. Law firm Seyfarth Shaw counted 3,117 website accessibility lawsuits filed in federal court in 2025, up from 2,452 in 2024, and noted that state court filings are not included in that count. This article is practical guidance, not legal advice.

Aim for WCAG 2.2 Level AA. The Web Content Accessibility Guidelines are published by the W3C, and Level AA is the level most commonly referenced in guidance, policies and settlements. WCAG is organized around four principles: content must be perceivable, operable, understandable and reliable with assistive technology.

You do not need to memorize the standard. The checklist below covers the issues that show up most often on service business websites and maps to WCAG AA requirements.

Start with the six error types WebAIM finds most often. Fixing these alone removes most automatically detected problems on a typical site.

After the six common errors, check how your content reads and looks. Service business sites often use light gray text on white, text over hero photos and brand colors that look good but fail contrast.

Alt text should say what the image communicates, not what file it is. A photo of a treatment room on a med spa site might read: private treatment room with reclining chair. A team headshot can use the person's name and role. A purely decorative pattern gets empty alt text so screen readers skip it.

• Body text and links meet contrast ratios, including text on photos and colored buttons
• Links are distinguishable by more than color alone (underline or another visual cue)
• Text can be zoomed to 200% without content being cut off or overlapping
• Headings follow a logical order (one H1, then H2s and H3s) and describe the section
• Link text makes sense on its own: Book a consultation, not Click here
• Text in images is avoided; when used (such as a menu or price list image), the same information appears as real text
• PDFs you link to, such as intake packets or menus, are tagged and readable, or have an accessible web version

Forms and booking tools are the most important part of a service business site to get right, because they are where inquiries and revenue come from. Many sites use third-party booking, scheduling, chat and payment widgets. You are still responsible for choosing ones that work, so test them like the rest of your site.

Ask your booking, chat or payment provider for its accessibility conformance report (often called a VPAT or ACR). If a widget cannot be used with a keyboard, offer an accessible alternative such as a phone number and email link next to it, and raise the issue with the vendor.

• Every field has a visible, connected label; required fields are marked in text, not only with color or an asterisk
• Error messages explain what went wrong and how to fix it, next to the field
• The form can be completed and submitted using only a keyboard
• Date pickers and time slot selectors work with a keyboard and announce the selected value
• CAPTCHA has an accessible alternative, or use a less intrusive spam check
• Confirmation messages are announced to screen readers, not only shown visually
• Time limits on booking holds can be extended
• Payment fields are labeled and work with autofill

People who use a keyboard or switch device need to reach every link and control in a logical order and see where they are. Menus, sliders and pop-ups are common trouble spots because they are often built with custom code.

WebAIM's 2026 report also flagged that pages using ARIA (code meant to improve accessibility) averaged more errors than pages without it, 59.1 versus 42. WebAIM notes this does not prove ARIA caused the errors, but it is a reminder that added code needs testing. Native HTML buttons, links and form fields are usually the safest choice.

• A skip to main content link is the first thing keyboard users reach
• Every interactive element shows a visible focus outline
• Tab order follows the visual order of the page
• Drop-down and mobile menus open, close and can be used with a keyboard
• Pop-ups and chat windows can be closed with a keyboard and the Escape key, and return focus sensibly
• Carousels can be paused, and nothing flashes more than three times per second
• Pages have unique, descriptive titles

If your site uses video, such as a clinic tour, a testimonial or an explainer, add accurate captions and make sure the player controls work with a keyboard. Auto-generated captions are a starting point, but review them for names, services and technical terms that software often gets wrong.

Background videos that play automatically should have a visible pause control. Audio content such as podcasts needs a transcript.

• Captions on every video with speech
• Transcripts for audio-only content
• Player controls reachable and labeled
• No audio that plays automatically for more than a few seconds without a way to stop it
• Important visual information in a video is also described in the narration or the page text

Test in three passes: an automated scan, a keyboard test and a short screen reader check. Automated tools are fast and free but catch only some issues, so the manual passes matter.

Monvell builds service business websites to WCAG AA from the start and tests forms and booking flows before launch, so accessibility is part of the build rather than a later fix.

• Automated scan: run WAVE (from WebAIM), axe DevTools or Google Lighthouse on your home page, a service page, the contact page and the booking flow
• Contrast: check brand colors with the WebAIM Contrast Checker
• Keyboard test: unplug the mouse, use Tab, Shift+Tab, Enter and Space to book an appointment and submit a form
• Screen reader check: use VoiceOver on Mac or iPhone, or the free NVDA on Windows, to read a service page and complete the contact form
• Zoom test: zoom the browser to 200% and confirm nothing is cut off
• Mobile check: test the booking flow on a phone with the screen reader turned on

Overlay widgets, the toolbars that add an accessibility icon to a site, do not fix the underlying code problems on their own. They can adjust contrast or text size for some users, but missing labels, broken keyboard access and inaccessible booking widgets still need to be fixed in the site itself. Treat an overlay as optional at most, and put the budget toward fixing the issues on this checklist.

An accessibility statement is a short page that says what standard your site aims to meet, what you have done and how visitors can report a problem. It shows good faith and gives people a direct path to help when something does not work. Link it from your site footer.

• The standard you are working toward, such as WCAG 2.2 Level AA
• A plain description of the steps you take, such as testing new pages and reviewing third-party tools
• Any known issues and the alternative available, such as booking by phone or email while a widget is being fixed
• An email address and a phone option for reporting barriers or requesting help
• Your target time to respond to a report
• The date the statement was last reviewed

Accessibility slips every time new content goes up, so make it part of how your team publishes. Add alt text and heading checks to your content checklist, rescan key pages after any redesign or new widget, and add an accessibility statement with a way for visitors to report problems.

When someone reports a barrier, respond quickly, offer an alternative way to get the service right away, and fix the issue. Keep a record of what was reported and when it was resolved.