Website Accessibility for Small Business

A small-business website is often the first place someone checks opening hours, compares services, reads a menu, books an appointment, completes a form, or decides whether to visit. If that information cannot be perceived, understood, or operated by a person with a disability, the website has placed a barrier in front of a customer who was already trying to engage.

Accessibility is the practice of removing those barriers. It includes readable contrast, meaningful structure, keyboard operation, useful alternative text, clear forms, captions, zoom-friendly layouts, and predictable interactions. These improvements also help people using a phone in bright light, navigating with an injured hand, reading in a second language, dealing with a slow connection, or trying to complete a task while distracted.

This guide translates the Web Content Accessibility Guidelines, or WCAG 2.2, into practical work for a small-business website. It explains what to check, where automated tools help, where human testing remains necessary, and how to improve the pages that matter most without treating accessibility as a one-time badge.

Treat accessibility as customer access

Accessibility discussions can become abstract because they involve standards, success criteria, assistive technology, and legal frameworks. The practical starting point is simpler: can people use the website to complete the same important tasks?

A blind customer using a screen reader may need headings and controls that are correctly named in the code. A customer with low vision may enlarge the page and require strong contrast. Someone with a motor disability may use a keyboard, switch, voice input, or alternative pointing device. A Deaf customer needs captions for information delivered through speech. A person with a cognitive disability may benefit from clear instructions, consistent navigation, and errors that explain how to recover.

These are ordinary customers, applicants, suppliers, residents, patients, guests, donors, and community members. Accessibility work protects their ability to learn, decide, communicate, and transact independently.

The legal context varies, but the access problem is concrete

In the United States, the Department of Justice’s current web accessibility guidance says businesses open to the public must provide equal access to the goods and services they offer, including those offered through websites. The guidance also notes that businesses have flexibility in how they meet the ADA’s general nondiscrimination and effective-communication requirements, while pointing to WCAG and Section 508 as useful technical references.

Requirements vary by jurisdiction, organization, sector, contract, and website function. WCAG is a technical standard, not a substitute for legal advice about a particular business. Even where the legal analysis is uncertain, an inaccessible booking form or unreadable service page remains a customer problem worth fixing.

Understand WCAG 2.2 without getting lost in it

The World Wide Web Consortium published WCAG 2.2 as a W3C Recommendation. It organizes accessibility under four principles: content and interfaces should be perceivable, operable, understandable, and robust. People often use the acronym POUR to remember them.

Perceivable: people can receive the information through available senses or alternatives, such as text alternatives for images and captions for audio.
Operable: people can navigate and activate the interface, including without a mouse.
Understandable: content, labels, instructions, navigation, and errors behave clearly and predictably.
Robust: the code communicates structure and control states reliably to browsers and assistive technologies.

WCAG success criteria are grouped into Level A, AA, and AAA. Many organizations use Level AA as a practical target, but the correct requirement depends on the context. Level AAA is not simply a “perfect website” setting, and meeting a conformance level does not remove the need to observe real users and real tasks.

WCAG 2.2 added practical interaction criteria

WCAG 2.2 introduced criteria that address issues such as keyboard focus being hidden, dragging alternatives, minimum target size, consistent help, redundant entry, and accessible authentication. The W3C’s summary of what is new in WCAG 2.2 explains each addition with the user problem it addresses.

Do not begin by memorizing every criterion. Start with the customer journeys and recurring components on the actual site, then use WCAG to test and improve them systematically.

Start with important pages and customer tasks

A small website can still contain many combinations of templates, widgets, forms, menus, media, downloads, and third-party tools. Build a simple inventory before testing. Include the homepage, service or product pages, contact page, booking or checkout, account area, search, blog templates, location pages, privacy information, and any document customers must download.

Then list the tasks that matter most: find a phone number, understand a service, compare options, read opening hours, submit an enquiry, book, pay, register, apply, download instructions, or request support. Rank them by customer importance and business frequency.

Test representative templates, not only URLs

Ten articles built from one template may share the same strengths and failures. A single modal, menu, form builder, cookie banner, or scheduling widget may appear across the site. Group pages by component and template so one fix can improve many experiences.

Include different content states. Test a form before submission, with missing fields, with invalid data, after a successful submission, and after a server error. Test the menu closed and open. Test a carousel before and after it moves. Test search with no results as well as useful results.

Connect accessibility to broader website quality

Clear headings, useful links, descriptive images, readable content, stable mobile layouts, and working forms support visitors as well as search systems. Our guide to preparing a business website for AI search explains why an accessible, well-structured website is also easier for machines to interpret as a reliable public source.

Make colour, contrast, and text readable

Low-contrast text often enters a design through muted brand colours, light grey metadata, text placed over photography, transparent overlays, disabled-looking buttons, or placeholder text used as a label. Check every state, not just the main paragraph style.

WCAG’s Level AA minimum text-contrast criterion requires at least 4.5:1 for normal text and 3:1 for large-scale text, subject to defined exceptions. Treat the ratios as thresholds; a calculated 4.49:1 does not round up to a pass.

Meaningful control boundaries, icons, charts, and other required visual information may fall under non-text contrast, which uses a 3:1 threshold against adjacent colours for covered components and graphics. The detailed criterion matters because not every decorative border or shape has the same requirement.

Do not rely on colour alone

If required fields are identified only with red text, some people will miss the distinction. Add words, symbols with accessible names, or other visible cues. Links inside body copy should not depend on a subtle colour shift alone; underlining is a clear and familiar signal.

Charts need labels, patterns, or direct values in addition to colour. Success and error notices should state what happened. A green outline without a confirmation message and a red outline without an explanation ask the user to interpret appearance rather than information.

Typography is more than font size

Use a readable body size, comfortable line height, and a line length that does not force the eye across an overly wide page. Avoid long passages in all capitals, heavily condensed fonts, or thin weights on bright backgrounds. Let users enlarge text without clipping labels, hiding controls, or overlapping content.

Support keyboard navigation and visible focus

Every interactive element should work without a mouse: navigation, buttons, links, form fields, disclosures, tabs, carousels, dialogs, media controls, and embedded widgets. A keyboard user commonly presses Tab to move forward, Shift+Tab to move backward, Enter to activate links or buttons, Space for controls, and Escape to close temporary interfaces where expected.

Start at the address bar and move through the page. The focus order should follow the visual and logical reading order. Focus should not jump into invisible content, become trapped inside a widget, or skip a control that a mouse user can reach.

Make focus visible and keep it unobscured

A focus indicator shows which control will respond to the next action. Do not remove the browser outline without providing a strong replacement. Test it over every button, card, menu, and background colour.

WCAG 2.2 added Focus Not Obscured at Level AA. Sticky headers, chat launchers, cookie banners, and fixed contact buttons should not completely hide the control that currently has focus. This is especially relevant to modern small-business sites that place persistent elements around the viewport.

Use native controls before custom imitations

A real button carries keyboard behavior and an accessible role. A styled generic container with a click handler does not automatically provide those features. Native HTML links, buttons, inputs, selects, headings, and landmarks are usually the most dependable starting point.

ARIA can communicate states and relationships for complex widgets, but it does not repair an incorrect interaction model by itself. Test what the control is called, whether its state is announced, how it opens and closes, and where focus moves.

Use headings, landmarks, and descriptive links

Visual size alone does not create structure. Use a meaningful page title and heading elements that reflect the sections and subsections. The W3C’s heading guidance recommends properly nested headings so people can understand and navigate the document structure.

A practical content page usually has one main heading for the page topic, followed by second-level headings for major sections and third-level headings within them. Do not choose a heading level because of its default font size; change the visual style with CSS while preserving the logical hierarchy.

Name links by their destination or action

“Read our accessibility checklist” is more useful than “click here.” Descriptive link text helps someone scanning visually, navigating a screen-reader link list, or using voice control. Repeated links named “learn more” become ambiguous when they lead to different places.

Make the purpose of icon-only links and buttons available as an accessible name. A magnifying-glass icon may need the name “Search.” A social logo may need the platform and destination. Avoid placing several conflicting names on the same control.

Use landmarks and a skip link

Semantic regions such as header, navigation, main, aside, and footer help assistive-technology users move around the page. A visible-on-focus “Skip to content” link lets keyboard users bypass repeated navigation. Keep landmark names distinct when a page contains more than one navigation region.

Write useful alternative text

Alternative text communicates the purpose of an image when the image cannot be seen. The right description depends on context. A photograph illustrating a story may need the relevant people and activity. A chart needs the conclusion and access to its underlying values. A button image needs the action. A decorative flourish should usually have empty alternative text so it does not add noise.

Do not begin every description with “image of,” because assistive technology already identifies an image. Do not repeat a nearby caption word for word. Do not fill the attribute with search keywords. Describe what the reader needs from that image in that location.

Some images need more than one sentence

A complex diagram, map, menu, infographic, or chart may need a short alternative text plus a longer explanation in the page. If the image contains instructions or data, provide those instructions or data as real text. The W3C’s accessibility principles explain that text alternatives can be presented through speech, enlarged text, braille, and other forms.

Keep essential words out of images where possible. Real text adapts to zoom, contrast settings, translations, reflow, and user styles. Logos are a special case, but promotional graphics still need the important offer, dates, terms, and action in the surrounding page.

Build forms people can complete and correct

Forms often sit at the end of a customer journey, so a small accessibility failure can block the entire outcome. Every field needs a persistent, understandable label. Placeholder text can show an example, but it disappears during typing and should not replace the label.

The W3C forms tutorial recommends associating labels with controls in the code. That relationship helps screen readers, voice input, and people who benefit from a larger clickable label area.

Explain requirements before the user fails

Mark required fields in text and code. State date, password, file, and phone-number formats before submission. Group related choices with a meaningful question. Preserve entered values when possible after an error so the user does not have to start again.

Make errors specific and recoverable

“Invalid input” does not tell someone what to do. Name the field, describe the problem, and explain the correction. The W3C guidance on form notifications recommends clear overall feedback and errors associated with the corresponding controls.

Move focus or announce the error summary appropriately after submission. Do not rely only on a red border. Confirm success clearly and explain what happens next. If a server or integration fails, preserve the customer’s work and provide another contact route.

Review privacy alongside accessibility

Ask only for information the business needs, explain its purpose, and make the relevant notice easy to find and understand. Accessibility should not require a person to disclose more personal information than other users. Waldok’s website Privacy Policy shows how collection, purpose, retention, sharing, and choices can be stated directly.

Support zoom, reflow, touch, and mobile use

Responsive design is not automatically accessible. A page can rearrange at smaller widths while still clipping enlarged text, hiding a focused control, locking orientation, or placing touch targets too close together.

WCAG’s Level AA reflow criterion is designed to support content at a width equivalent to a 320 CSS-pixel viewport, which corresponds to a 1280-pixel-wide page viewed at 400 percent zoom. Most content should reflow without requiring two-dimensional scrolling, with defined exceptions for content such as some maps, data tables, or diagrams.

Test enlarged text, not only device presets

Zoom to 200 and 400 percent on desktop. Increase text size at the operating-system or browser level. Check navigation, cookie notices, forms, cards, tables, dialogs, and floating buttons. Look for clipped labels, overlapping content, off-screen controls, and horizontal scrolling caused by ordinary paragraphs.

Give controls enough space

WCAG 2.2’s Level AA Target Size (Minimum) criterion uses a 24 by 24 CSS-pixel minimum or sufficient spacing, with several exceptions. Larger targets may be easier for people with tremors, limited dexterity, large fingers, or an unstable mobile environment.

Measure the actual interactive area, not only the visible icon. Pay particular attention to menu buttons, carousel arrows, close controls, pagination, social icons, date pickers, and consent controls.

Provide accessible audio, video, and documents

Prerecorded video with meaningful speech needs accurate synchronized captions. Captions include spoken words and relevant non-speech audio, not merely a rough transcript pasted into the description. Review automatically generated captions for names, technical terms, timing, punctuation, and omitted sounds.

The W3C’s audio and video accessibility guidance also covers transcripts, audio descriptions, sign language, and accessible media players. The correct combination depends on what information the media contains.

Do not hide essential information inside a PDF

Menus, price lists, application instructions, policies, brochures, and reports are often uploaded as PDFs. A scanned image of a page may contain no usable text structure. A visually designed PDF may still lack headings, reading order, table headers, document language, bookmarks, and useful link names.

Provide important current information as accessible HTML when practical. If a document remains necessary, include it in the accessibility review and identify an owner for future updates. Replacing an inaccessible PDF with another inaccessible PDF every quarter preserves the barrier.

Combine automated and manual testing

Automated tools can find missing alternative attributes, duplicate IDs, certain label problems, some heading issues, and colour combinations that fail known thresholds. They can run quickly across many pages and help prevent regressions.

They cannot reliably decide whether alternative text is useful, whether the heading structure matches the meaning, whether instructions are understandable, whether focus order feels logical, or whether a customer can complete a complex task. The Department of Justice explicitly cautions that a clean automated report does not necessarily mean everything is accessible.

Run a repeatable manual review

Navigate every interactive element with the keyboard and watch the focus indicator.
Check that menus, dialogs, disclosures, and widgets open, close, and return focus logically.
Review the page outline, title, headings, landmarks, lists, and table structure.
Inspect image alternatives in their actual context.
Submit forms with valid, missing, and incorrect information.
Zoom and reflow the page at several widths.
Test high contrast, forced colours, reduced motion, and text-spacing changes where relevant.
Listen to key pages with a screen reader and confirm controls have useful names and states.
Complete the highest-value customer tasks from beginning to end.

Include people with disabilities

Standards-based testing is necessary, but user research can reveal friction that a checklist misses. Recruit appropriately, compensate participants, protect their privacy, and test specific tasks. Do not ask one person to represent every disability or assistive-technology combination.

The W3C’s Easy Checks provide a useful first review, while a formal conformance evaluation requires broader sampling, methods, and expertise.

Prioritize fixes by customer impact

Start with barriers that block important tasks or affect every page. A keyboard-inaccessible menu, unreadable text, unlabeled booking fields, missing error feedback, or a checkout dialog that traps focus deserves attention before polishing decorative alternative text on an old article.

A practical priority model considers severity, reach, task importance, frequency, and effort. Fix shared components at the source so improvements reach all pages. Record temporary workarounds and assign an owner and deadline for the durable repair.

Use an accessibility issue format

For each problem, record the page or component, steps to reproduce, affected users, relevant WCAG criterion, evidence, expected behavior, severity, owner, fix, and retest result. Include screenshots or short recordings when they help the developer understand the behavior, but preserve sensitive information.

Integrate accessibility into the wider delivery process rather than running a final audit after design and development decisions are fixed. Waldok’s delivery process follows the same general pattern of discovery, defined boundaries, validation, deployment, documentation, and ongoing improvement.

Keep new content accessible

A launch audit cannot protect a website from future changes. New images arrive without alternative text. Editors paste heading-sized bold paragraphs. A campaign introduces low-contrast colours. A new form omits labels. A plugin update changes keyboard behavior. Accessibility needs ownership inside routine publishing and maintenance.

Create editor guardrails

Provide approved heading styles, colour combinations, button patterns, content blocks, form components, and media procedures. Add fields for alternative text and captions where content enters the system. Limit arbitrary colour and typography choices when they create predictable risk.

Give editors a short checklist for every publication: correct heading level, descriptive links, appropriate image alternative, readable tables, captions or transcript, meaningful document title, and a working mobile preview. Keep it close to the publishing interface rather than buried in a policy.

Monitor changes and feedback

Include accessibility checks in design review, code review, content approval, release testing, and periodic audits. Retest shared components after theme, plugin, framework, or third-party changes. Keep a public way for someone to report an accessibility problem, and make sure the report reaches a person who can act.

Security and accessibility can reinforce one another when implemented carefully. Dependable updates, limited administrative access, change records, and controlled components help teams maintain both. Our small-business website security checklist explains the post-launch work around accounts, updates, vendors, backups, monitoring, and recovery, while Waldok’s security approach describes the underlying value of explicit ownership and boundaries.

A practical 30-day improvement plan

Week 1: inventory and baseline

List templates, components, third-party widgets, documents, and important customer tasks. Run automated scans on representative pages. Complete the W3C Easy Checks and a keyboard review. Record the current issues without treating the first tool score as a verdict.

Week 2: remove major barriers

Fix global navigation, keyboard access, visible focus, severe contrast failures, page titles, main headings, form labels, and errors on the most important task. Correct shared templates and components before editing individual pages.

Week 3: improve content and media

Review heading structure, link names, images, tables, video, audio, and priority documents. Replace image-only information with real text. Caption important recordings and publish accessible HTML alternatives for essential downloads where practical.

Week 4: validate and establish ownership

Repeat keyboard, zoom, reflow, form, automated, and screen-reader checks. Test complete customer journeys. Record remaining issues, owners, severity, and dates. Add publishing guardrails, feedback handling, and a recurring review schedule.

Accessibility work may require design, content, development, policy, and legal input. If you need help mapping the technical work into an accountable project, start a conversation with Waldok.

Common questions

Does passing an automated accessibility scan mean the website is accessible?

No. Automated testing catches only issues that software can detect reliably. Manual keyboard, zoom, structure, form, and assistive-technology testing remain necessary, along with evaluation of real customer tasks.

What contrast ratios should a small-business website use?

WCAG Level AA requires at least 4.5:1 for normal text and 3:1 for large-scale text, subject to the criterion’s definitions and exceptions. Covered user-interface components and meaningful graphics may require 3:1 against adjacent colours.

Does every image need a written description?

Every image needs an appropriate text-alternative decision. Informative and functional images need useful alternatives. Decorative images generally use empty alternative text so assistive technology can ignore them. Complex images may need an explanation in the surrounding content.

Can an accessibility overlay fix the website automatically?

An automated layer cannot reliably correct every problem in content, structure, keyboard behavior, forms, documents, third-party tools, and task design. Test the underlying site and fix barriers at their source.

Should a small business target WCAG 2.2 Level AA?

Level AA is a common practical target for modern web work, but legal and contractual requirements depend on the organization, location, sector, and service. Establish the applicable requirement, then combine conformance work with testing of real users and tasks.

Is accessibility finished after launch?

No. Content, design, code, integrations, documents, and platform behavior change. Assign owners, provide editor guardrails, include accessibility in release checks, and retest important customer journeys regularly.

Research references

An accessible website gives more people a fair opportunity to understand the business and complete the task they came to do. Start with the highest-value journey, remove its barriers, correct shared components, and make accessibility part of every future update.