How to Test Custom Software Accessibility Before a Healthcare Pilot

A working intake demo can still leave a patient unable to correct a rejected field. Accessibility testing checks if people with disabilities can understand and use a digital product.

We would start with the healthcare task that must work independently. A clinician's familiarity with that task helps define the test, but it cannot substitute for observing the people who will use the product.

We assume you have a named pilot practice, a validated problem and access to representative users. We'll cover the workflow checks, evidence records, participant evaluation and repair decisions needed before that pilot begins.

Run Accessibility Testing on Complete Healthcare Pilot Workflows

We would run accessibility testing on complete tasks in the intended pilot build, combining automated checks, manual operation and observed use. A successful page scan cannot establish that a patient can finish an intake form or a staff member can process its result.

1. Fix the Workflow, Role and Build in the Test Scope

We would ask the practice and engineering team to agree on the task's start, finish and permitted roles before testing. Write the release identifier beside that scope. Include the configuration and connected components that affect the journey.

For a web pilot, our proposed scope would include the following checks when those functions exist. These are suggested tests, not results from a client engagement.

Workflow	Proposed test	Evidence to retain
Patient sign-in and intake	Sign in, enter information, correct an error and submit	Entry route, error state, correction and final confirmation
Appointment change	Select a replacement slot, confirm it and review the saved choice	Original selection, changed selection and confirmation
Staff intake review	Open the submission under the intended staff role and complete the handoff	Role, available actions and resulting work status

We would include password recovery, third-party sign-in and embedded scheduling controls if the task depends on them. Starting after login can hide the barrier that prevents someone from reaching the product at all.

Use an isolated test environment and approved test records. We would keep real patient details out of screenshots and recordings. Confirm that a test submission cannot trigger a real appointment, message or downstream clinical action.

Record the agreed Web Content Accessibility Guidelines (WCAG) version and level, supported environments and evaluation scope. We would ask a qualified accessibility reviewer to assess applicable criteria beyond this pilot checklist.

Our founder UAT guide explains how to define acceptance around real journeys. For accessibility testing, we would add the input method and assistive technology to each journey's conditions.

2. Run Automated Checks on Interactive States

We would use accessibility testing automation to find detectable problems in each relevant state. That means inspecting the opened dialog, rejected form and completed submission, rather than scanning only the initial screen.

W3C's evaluation-tool guidance explains that tools assist evaluation but cannot determine accessibility by themselves. We would retain the tool and version, scan scope and original findings, then review findings before assigning an outcome.

The NCDIT testing checklist names axe, WAVE and Lighthouse as examples. We would select a tool that can inspect the application's authenticated and interactive states.

For a hypothetical intake form, deliberately submit an invalid required field in the test environment. Capture the resulting state, run the scan there and inspect the error association. Repeat after correcting the field and submitting successfully.

We would keep a finding separate from its disposition. A reviewer can explain a false positive, but deleting the finding removes the evidence of that judgment. A clean scan also leaves the manual checks outstanding.

3. Complete the Task Through a Keyboard Interface

Our manual accessibility testing checklist would require completion through a keyboard interface without reaching for the mouse. We would test keyboard navigation from entry to confirmation, including reverse navigation and returning from dialogs.

W3C's keyboard criterion requires keyboard operation of functionality, with a specific exception for functions dependent on movement paths. We would evaluate the task outcome, not assume every control must behave identically.

For a scheduling workflow, our checks would include:

• Reach the date selector and identify the focused control.
• Select an available date and appointment time using supported keyboard commands.
• Open and dismiss the confirmation dialog without losing the task.
• Return to the intended control and correct the selection.
• Complete the change and verify the saved appointment details.

We would record the exact step where progress stops. “Calendar inaccessible” gives an engineer less to reproduce than a named control, starting state, key sequence and observed focus behavior.

The A11Y Project checklist covers visible focus, logical order and keyboard traps. We would apply those checks to the actual dialog and its return path, including controls supplied by another vendor.

4. Verify Screen Reader Output and Enlarged Views

We would conduct screen reader testing with a tester who understands the chosen tool and interaction mode. Simply turning speech on does not establish that a label, error or status announcement communicates the right information.

For accessibility testing with NVDA, record the Windows, browser and NVDA versions alongside the result. NV Access documents its screen reader's support for Windows and common web browsers. Choose other combinations from the pilot's actual supported environments.

On the intake form, we would listen for the field's name, required state and associated error. After correction, verify the submission outcome without relying on the visual success banner.

W3C's status-message guidance addresses changes that assistive technology should convey without moving focus. We would test the announcement in context, including the waiting and failure states the application actually provides.

We would also check enlarged content through the complete task. Under WCAG's reflow criterion, vertically scrolling content must work at a width equivalent to 320 CSS pixels, subject to defined exceptions.

For the pilot, we would inspect the form, dialog and confirmation at that width. Check that instructions, error text and the submission control remain available. A table's permitted two-dimensional layout does not excuse unrelated controls disappearing.

5. Record the Outcome That the Workflow Actually Produced

We would verify the task's saved result as well as its visible or spoken confirmation. In a hypothetical appointment-change test, the selected slot, confirmation and staff view should agree on the intended change.

This is a proposed acceptance test, not a claim about a particular scheduling product. We would have the practice define the expected business outcome before the engineer demonstrates it.

For each observation, retain the starting state, actions, expected result, actual result and evidence location. Include the role, environment and build. A screenshot alone cannot reproduce a keyboard sequence or the words a screen reader announced.

Our PRD guide for a working demo provides related planning context. We would make the workflow's state changes and permissions explicit before treating a demonstration as acceptance evidence.

Pro tip: We would save the starting state with the failure. A recording that begins after the dialog opens can conceal the step that caused focus to disappear.

Keep Custom Software Development Evidence Tied to the Pilot Build

We would approve accessibility testing evidence only after matching it to the expected checks for the current pilot build. A folder of successful screenshots does not show which required combinations have no result.

1. Match Each Required Check to Its Evidence

Our proposed accessibility testing report template starts with an expected-scope table. Each row names the workflow and state, user role, test method and environment. The scope also identifies the build being considered for the pilot.

We would create these expected rows before running tests. That preserves the denominator because a missing keyboard result stays visible even when the scanner produces many successful findings.

For each expected row, record the tested build, tester, test time, expected outcome, actual outcome, artifact location and linked defect. Keep the browser and assistive technology versions inside the environment description.

The matching rule is precise. The workflow, state, role, method and environment must agree. The evidence must also name the current build. A patient-role result cannot stand in for a staff-role check.

We would record the reviewer and review time separately from the tester. That gives the pilot decision an owner without pretending the reviewer personally performed every interaction.

2. Reject Stale, Missing and Conflicting Results

We would use the following decision table for each expected check. These are our recommended record-handling rules, not WCAG-defined result labels.

Evidence condition	Review state	Required next action
No matching evidence	Not run	Perform the required check
Matching evidence exists only for an older build	Stale	Retest the current build
A current result reports a barrier	Fail	Repair and retain the defect history
A required identity field or artifact is missing	Incomplete	Recover the evidence or repeat the test
Current records conflict without a documented resolution	Unresolved	Have a reviewer reconcile them
Current evidence is complete, passes and has no unresolved conflicting result	Pass	Retain it for the scoped pilot decision

Consider a hypothetical intake workflow that passed its keyboard test before an error-message change. We would mark its old-build evidence stale when reviewing the new build, even if the old recording still looks convincing.

A new passing retest can resolve the earlier failure, but it must identify the defect and superseded result. We would not let the most recently uploaded screenshot silently overwrite contradictory evidence.

We would record an excluded test as excluded, with a reason and accountable reviewer. It cannot increase the pass count. If the excluded check is necessary for a critical pilot task, the task remains unapproved.

Pro tip: We would compare the expected rows with the evidence register before reviewing pass totals. That catches an entirely absent test which a defects-only report cannot display.

Watch Disabled Participants Complete the Actual Pilot Tasks

We would include disabled participants in accessibility testing to understand how the intended work operates in practice. Usability testing adds evidence about task use that a standards review alone may miss, as W3C explains.

• Match Participants to the Intended Work

We would recruit around the pilot's functional access needs and actual roles. A patient completing intake and a staff member reviewing submissions may need different sessions and environments.

Section508.gov's usability guidance recommends defining goals, selecting representative tasks and making study materials accessible. We would use those research practices without assuming federal procurement rules apply to every private healthcare product.

Arrange accessible consent and instructions, and let participants use familiar assistive technology where practical. We would fix obvious blocking problems with an expert reviewer before asking participants to spend their time encountering them.

• Record Assistance Without Turning It Into Success

We would observe the participant attempting the task without coaching them through the interface. If the moderator explains an unlabeled button, record the assistance and the underlying barrier.

For a hypothetical intake session, distinguish independent completion from completion after the moderator reads an error aloud. Those outcomes should not become the same green checkmark.

We would record barriers, task outcomes and assistance alongside timing. A slower successful interaction is different from a fast interaction that submits the wrong information. The participant's explanation can reveal what the stopwatch misses.

No small study represents every disabled person or environment. We would state the participants and conditions covered, preserve remaining gaps and avoid treating positive feedback as a conformance certificate.

Repair Access Barriers Before Approving the Pilot Scope

We would delay a critical pilot workflow when accessibility testing finds an unresolved barrier to completing it. The decision should name the affected task, repair owner and evidence needed for retest.

• Make the Release Decision Against the Agreed Scope

We would ask the practice lead and engineering owner to review failures, missing checks and stale records together. Approval names the build and supported scope; it should not silently extend to untested roles or environments.

A narrowed pilot may change the expected scope, but removing a necessary patient journey from the spreadsheet does not repair it. We would document the actual operating change and evaluate its consequences before proceeding.

W3C's conformance requirements cover full pages and complete processes. We would describe this checklist's result as scoped pilot evidence, reserving broader conformance claims for an evaluation that supports them.

• Choose the Smallest Repair That Restores the Workflow

We would investigate the source of the barrier before commissioning replacement software. An existing platform, integration or configuration change may address the problem with less disruption.

Repair option	When we would investigate it	Evidence needed before the pilot
Configuration or content correction	The existing product supports the required behavior	Retest of the configured workflow
Vendor component correction	The barrier sits in a supplied widget or service	Current vendor fix plus testing in the integrated product
Custom component or workflow work	The required behavior cannot be delivered through the available product	Explicit scope, ownership and evidence from the resulting build

Our proposal-comparison guide helps frame the vendor discussion. We would put remediation, retesting and responsibility for third-party components into the agreed scope.

When a custom build is justified, we would make accessibility testing part of the delivery agreement for healthcare product work.

Our Apex Dental Partners case study documents reporting, payroll and operations work, illustrating the range of staff workflows a healthcare product can contain.

Recheck the Pilot Build Before Inviting Participants

We would begin with a named practice, the workflows its participants need and a testable release. Run accessibility testing across the agreed methods, keep missing evidence visible and repeat affected checks after repairs.

Before inviting participants, confirm that the reviewed build is the one they will receive. In custom software development, that connection keeps a useful test from becoming an outdated assurance. We can help define the product and delivery work around those decisions at Better Software.

Frequently Asked Questions

Can AI do accessibility testing?

We would use AI to draft test cases and explain errors. We would then check each claim against the product and its agreed criteria. For accessibility testing, an AI reply remains a suggestion until a qualified reviewer directly verifies it.

Where can I find a detailed checklist for WCAG 2.2 compliance testing?

We would use W3C’s Quick Reference. It links each criterion to techniques and explanations. Select the version and level your evaluation needs. We would save that choice with the written test scope so reviewers know which requirements guided the work.

What are the typical costs associated with professional accessibility audits?

We would ask for a quote based on named workflows and test environments. List manual checks, user research, reporting and retests as separate work. We would confirm which fixes the price includes before comparing quotes. We have no verified market average.

Is WCAG legally required?

We would check the rules applying to the organization. HHS identifies WCAG 2.1 AA requirements for its funding recipients and extended specific deadlines on May 7, 2026. We would confirm scope and timing with qualified counsel rather than apply that rule to every healthcare business.

What is the latest WCAG standard?

We checked W3C on October 31, 2026, and WCAG 2.2 remains the latest published version. WCAG 3 is still a draft. We would also check the version named in the organization’s contract or applicable rule, since the newest standard and required baseline can differ.