Making a Kirksville Business Website More Accessible

A green accessibility scanner score does not prove that a customer can use the website.

The better test is whether a person can complete the site's real tasks: understand the services, navigate, fill out a form, read the content and reach the business without getting blocked by the interface.

WCAG 2.2 provides the technical foundation, but practical testing still matters.

Start with the customer journeys

Choose the site's most important tasks.

For a small business, that may be:

• finding a service;
• reading pricing or process information;
• opening navigation;
• completing a contact or quote form;
• requesting an appointment;
• finding a phone number;
• using a payment page.

Test those first.

An inaccessible decorative component matters less than a contact form the customer cannot submit.

Use semantic HTML before adding ARIA

Native HTML elements already carry useful meaning.

Use:

• real headings;
• real buttons;
• links for navigation;
• labels associated with form inputs;
• lists for lists;
• tables only for tabular information;
• landmarks such as nav, main and footer where appropriate.

ARIA can help when native HTML cannot express the interaction.

It should not be used to imitate controls that HTML already provides correctly.

Test the site with a keyboard

Disconnect the mouse or ignore the trackpad.

Can you:

• open and close menus?
• reach every interactive control?
• see where focus currently is?
• activate buttons and links?
• complete forms?
• dismiss dialogs?
• return to the page without becoming trapped?

Visible focus is essential.

Do not remove focus indicators simply because they look unattractive.

Keep focus visible and unobscured

WCAG 2.2 added additional attention to focus visibility and whether focused controls become hidden behind sticky headers or overlays.

A keyboard user should be able to see the control that currently has focus.

Test this with fixed navigation, cookie notices, chat widgets and other persistent interface elements.

Check contrast and color dependence

Text and controls need enough contrast to remain readable.

Do not rely on color alone to communicate meaning.

For example, a form field with an error should not become understandable only because its border turns red.

Pair color with text, icons or other clear indicators.

Write useful text alternatives

Images that communicate meaning need useful alternative text.

Decorative images generally should not create noise for screen-reader users.

The purpose of alt text is not to describe every pixel.

It is to provide the equivalent information needed in the page context.

Make forms understandable

Forms are one of the most common failure points.

Use:

• persistent labels;
• clear required-field indicators;
• instructions before the user needs them;
• useful validation;
• error messages associated with the field;
• confirmation after submission.

Placeholder text is not a label.

Do not make users guess why a submission failed.

Support zoom and reflow

Customers may zoom text or use narrow screens.

The page should remain usable without forcing excessive horizontal scrolling for ordinary content.

Responsive design, sensible line length and flexible layouts help.

Do not lock text into tiny fixed containers simply to preserve a desktop composition.

Test target size and touch interaction

Controls that are easy to click with a mouse may be frustrating on a phone.

Check:

• menu buttons;
• close icons;
• form controls;
• pagination;
• small text links;
• adjacent action buttons.

WCAG 2.2 added a minimum target-size criterion at Level AA, but the practical principle is broader: touch controls should be easy to operate without precision tapping.

Do not forget third-party widgets

Appointment tools, payment widgets, chat systems, maps and embedded forms are still part of the customer experience.

A business cannot fix every vendor's code, but it can choose better tools or provide an accessible alternative path.

Do not assume “the vendor made it” ends the problem.

Use automated tools as a first pass

Automated testing can catch issues such as:

• missing labels;
• missing alternative text;
• contrast problems;
• duplicate IDs;
• some landmark and heading problems.

It cannot reliably determine whether:

• the alt text is useful;
• the heading structure makes sense;
• keyboard order is logical;
• instructions are understandable;
• the complete workflow works for a real user.

Use scanners to find candidates, then test manually.

Do not treat WCAG as a legal conclusion

WCAG is a technical accessibility standard.

Whether a particular site satisfies a specific legal obligation depends on jurisdiction, facts and applicable law.

Do not turn an accessibility audit into a legal guarantee.

Re-test after changes

Accessibility can regress when the site changes.

A new plugin, form, menu or redesign can introduce issues that did not exist before.

Keep a small manual test routine for the most important customer journeys and run it after meaningful changes.

The objective is simple:

a customer should be able to understand and use the business website without the interface becoming the barrier.

For accessible appointment workflows, see Adding Online Appointment Requests to a Kirksville Business Website.