A visitor opens your contact form, fills in the required fields, and tries to choose a service. The dropdown works with a mouse, but it will not open from the keyboard. There is no error message. There is no way to finish the request.
Your latest accessibility scan might still show a good score.
Website accessibility testing needs more than an automated scan because software can check certain rules without establishing whether a person can complete a task. Keyboard navigation, screen reader output, form recovery, and the meaning of content all need human review. A scan is useful evidence about the pages and states it checked. It is not proof that the website is accessible.
For a business website, start with the things visitors came to do: understand your services, find contact information, request a quote, book an appointment, or sign in. Follow those tasks from beginning to end, including the steps where something goes wrong.
What an automated accessibility scan can find
Automated accessibility tools can flag problems such as missing form labels, images without an alt attribute, invalid accessibility attributes, and some color contrast failures. They can find repeated mistakes across a large site and give developers a useful starting point.
The results depend on the tool, its rules, and what it can reach. A scan of the home page says little about an appointment form on another page. A crawler may never reach an account area, open a mobile menu, trigger a validation error, or inspect a confirmation message after submission. A scripted test can exercise those states, but someone has to define and maintain the steps.
Even on a page the tool checks, some questions remain open. An image can have alternative text that says almost nothing. A button can have an accessible name that describes the wrong action. A heading can be marked up correctly while giving visitors no useful idea of what follows.
Read the findings alongside the test scope. Ask which pages, interactions, account roles, and error states were included, and which findings still need a person to decide whether they are a problem. Treat a clean report as the result of those checks, rather than a certificate for the whole site.
Keyboard testing: can a visitor finish the job?
Put the mouse aside and try your most important task. Use Tab and Shift+Tab to move through controls, Enter or Space to activate them where appropriate, and arrow keys in controls that use them. Watch where keyboard focus goes. Focus is the current position for keyboard interaction, usually shown with an outline or another visible indicator.
A useful first pass asks whether you can reach and operate the navigation, open and close menus, complete forms, correct a mistake, and submit successfully. You should be able to tell where you are throughout the process. A sticky header or cookie banner should not hide the control you are trying to use.
Dialogs need particular attention. When a modal dialog opens, focus should move into it and stay within it while the background is unavailable. After it closes, focus should return to a sensible place, usually the control that opened it. Keeping focus inside an active modal is intentional. Leaving someone stuck in a menu or widget with no working exit is a keyboard trap.
Consider a hypothetical service business with a request form. The form passes basic label checks, but its custom date picker only responds to mouse clicks. Someone who navigates by keyboard cannot select the required appointment date. The business loses the inquiry even though the form's individual fields looked acceptable to the scanner.
These interaction details belong in business website development from the start. They are easier to get right while choosing and building components than after the same broken control appears on twenty pages.
Screen reader testing: do the words and controls make sense?
A screen reader presents information through speech or braille. It can let someone navigate by headings, links, form fields, and other page structure instead of reading every word in sequence. That makes the quality of the underlying HTML and control names especially important.
Listen to the task, not just the page. Can someone find the right section, identify each field, understand a button's action, and tell whether a menu is expanded? Does the reading order preserve the meaning of the content? If a form reveals a new field, is its purpose clear when the person reaches it?
Changes after an action deserve their own checks. Search results may update without a page reload. A document upload may finish. A form may display a success message. Those updates need to be available to assistive technology without forcing someone to hunt around the page for an explanation.
In the service business example, imagine that the request is submitted successfully and a green confirmation appears above the form. If a screen reader user gets no indication that anything changed, they may submit again or leave believing the request failed. A visible message and a successful database write do not establish that the visitor received confirmation.
Use testers who understand the screen reader and browser combinations selected for the review. An unfamiliar user pressing a few keys can mistake their own difficulty for a website defect, or miss a real problem. Testing with people with disabilities can also reveal obstacles that the development team did not anticipate. That input complements a structured accessibility evaluation.
Forms need testing when something goes wrong
Opening an empty form is only the beginning. Submit it with a missing required field, an invalid email address, or a file the site cannot accept. Then try to recover using the keyboard and a screen reader.
An error should identify the affected field and explain the problem in text. A red border by itself is insufficient. Instructions should help the visitor correct the entry, and the error needs to be associated with the relevant control. Check how the person discovers the error, how they get back to the field, and whether valid information remains in place.
Test the next attempt too. A form that announces the first error but stays silent after a second failed submission still creates a problem. So does one that clears a long message whenever another field needs correction.
If visitors sign in, include password managers, pasting credentials and verification codes, and account recovery in the review. Security controls and spam protection can create barriers too. Test the actual challenge and recovery path a visitor may encounter, rather than assuming that an accessible-looking sign-in page makes the whole process usable.
For a client portal, that scope extends to invitations, document uploads, approvals, and session expiry. A visitor who gets through the login screen still needs to complete the work inside.
Zoom, layout, and content can expose different barriers
Enlarge the text and use browser zoom. Check whether navigation, instructions, form fields, and buttons remain available as the layout changes. A page that looks tidy on a phone can still fail when someone enlarges text on a desktop browser.
For ordinary reading content, people should not have to scroll sideways and vertically to follow each line. Data tables and maps can need a two-dimensional layout, so their evaluation requires more care. Watch for clipped labels, overlapping text, fixed-height boxes, and banners that consume most of the usable screen.
Review meaning as well as layout. Alternative text should serve the image's purpose in that context. A photograph used only as decoration may need empty alternative text. A chart used to explain a price increase needs the relevant information available in text, not merely an alt description saying "bar chart."
The same judgment applies to headings, link wording, captions, and instructions. Automatically generated video captions can contain a wrong product name or reverse the meaning of a sentence. A link labeled "click here" may offer little help when encountered away from the surrounding paragraph. A scanner can flag some patterns, but a person needs to decide whether the content communicates what matters.
Clear structure and descriptive links also support a useful content strategy. They help readers move between a service, an explanation, and the next step. Our guide to business website costs explains why content, accessibility, and testing need an explicit place in the project scope.
Third-party widgets and downloads are part of the journey
Your page may work well until a visitor opens an embedded booking tool, payment window, map, chat widget, or document viewer. Those components still affect whether the person can finish the task. Test the configured version on your site, including keyboard behavior, labels, errors, and focus when entering or leaving it.
An accessibility statement from the vendor can help you ask better questions. It does not replace testing the integration visitors actually use. Keep track of issues the vendor must fix, and agree on a usable interim route when a critical action is blocked.
Downloads need a separate review. A website scan does not establish that an attached PDF has a sensible reading order, tagged headings, useful links, or accessible form fields. If a visitor must read a document or complete it to receive a service, include that document in the scope. Consider whether the information or form would work better as an accessible web page.
This matters when deciding whether to improve or replace an existing WordPress website. Changing the theme will not necessarily repair a booking plugin, an embedded form, or years of inaccessible downloads.
What should a website accessibility review include?
Define the review before comparing scores or proposals. If the agreed target is WCAG 2.2 Level AA, write that down. WCAG stands for Web Content Accessibility Guidelines. The version and level give the team specific criteria to evaluate; an unexplained "accessibility compliant" label does not.
For a focused first review, ask for:
A sample can uncover problems and guide repairs. It does not justify claiming that every page and complete process conforms. Be clear about whether the engagement is a limited review, a remediation project, or a broader conformance evaluation. Even a broader evaluation needs a documented scope and method.
Prioritize barriers that prevent essential tasks, then look for shared causes. One inaccessible navigation component can affect the entire site. Fixing its source is usually more useful than closing the same finding separately on each page. Our QA and test automation service helps connect test scope and findings to practical release decisions.
Keep accessibility checks in the release process
Retest the affected task after a repair. If a developer changes a form control, confirm that it works with the keyboard, communicates correctly to the screen reader, and still behaves properly when enlarged. Rerunning the original scan alone may not answer those questions.
Add repeatable automated checks for problems the tools can reliably detect. Use automated regression testing to protect important workflows as the website changes, while keeping manual review for behavior and meaning that need judgment.
New content, plugins, design changes, and vendor updates can introduce fresh barriers. Give someone responsibility for checking those changes and responding to accessibility feedback. That work belongs in ongoing application support and maintenance, alongside the other tasks that keep the website useful after launch.
If you are unsure where to start, choose one task your business needs visitors to complete. Try it without a mouse, review it with a competent screen reader tester, and record every point where progress becomes unclear or impossible. That gives you a concrete starting scope.
Honor Tech builds business websites and web applications with attention to accessibility, testing, and ongoing support. Tell us which website or workflow needs attention, and we can scope the review and development work around it.