How to Evaluate Accessibility Tests When Choosing a Custom Web Design Company?

How can an accessible custom web design claim be verified?

An accessibility claim should be verified through the vendor’s testing method, issue records, and remediation process for specific user flows rather than through broad statements in a sales presentation. The key criterion is whether the claim can be turned into repeatable evidence. Ask candidates to demonstrate behaviors such as keyboard navigation, focus order, form feedback, and menu interaction on a site they have built. This allows the buying team to assess not only visual quality but also whether design decisions have been translated into accessible interaction in the working product.

What evidence should replace general claims?

Portfolio review is stronger when it is paired with a small technical audit that reveals how the company works. When assessing a web design company’s technical competence, accessibility should be a distinct evaluation category. Ask which standards or checklists the team references, how automated tool results are supplemented with manual testing, and how identified issues are prioritized. A single score or badge is less useful than a clear explanation of what was tested, what failed, and how the team verified the correction.

• Ask for real user flows that were tested.
• Watch a live keyboard and focus demonstration.
• Review how accessibility findings are recorded.
• Ask how manual and automated checks differ.
• Clarify who owns each remediation task.

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.- Tim Berners-Lee

Which critical user flows should accessibility testing cover?

Accessibility testing should prioritize the organization’s most important user flows instead of scanning every page superficially. The scope should prove that a user can complete a real task from beginning to end. On a corporate site, that may include reaching a quote form, reviewing service information, and locating contact details. Systems with accounts or transactions may also need login, registration, search, filtering, and task-completion flows. The vendor should be able to explain why each flow was selected and which accessibility risks are being checked within it.

How should user flows be prioritized?

Before asking candidates how many pages they test, ask which steps they test to make sure a specific user goal can be completed. Primary navigation, mobile menus, search, form submission, validation messages, and in-content links can be treated as separate tasks. A high-traffic page with limited business impact should not automatically receive the same weight as a quote, application, or support flow. Prioritizing around user goals makes the test scope easier to compare across vendors and more relevant to the commercial purpose of the website.

• Include primary navigation and mobile menus.
• Add quote, application, or contact forms.
• Test search and filtering behavior.
• Cover login and account tasks when relevant.
• Test error and success states separately.

How should keyboard use and visible focus be tested in a demo?

Keyboard use can and should be demonstrated directly during vendor evaluation. The basic test is whether a critical flow can be completed in a logical order without using a mouse. Ask the company to navigate menus, links, expandable controls, and forms with Tab, Shift+Tab, Enter, Space, and arrow keys where appropriate. The focus indicator should remain visible, the sequence should make sense, and opening a component should not move focus to an unexpected location. This demonstration reveals both implementation quality and whether the design process considered interactive states from the beginning.

What behaviors should the buying team watch?

Check whether visible focus has been hidden for aesthetic reasons, whether focus moves into a modal or menu when it opens, and whether it returns to a logical trigger when the component closes. If mobile and desktop components behave differently, ask for both versions to be demonstrated. It is also useful to test at least one content page and one form flow, not only the homepage. The company should explain whether these checks happen during design review, after development, or at both stages, because the timing affects who can correct the issue efficiently.

• Run the flow with the mouse completely unused.
• Confirm focus is visible at every step.
• Check whether tab order matches content logic.
• Test dropdown and modal behavior.
• Verify that focus returns to the correct control.

How should form accessibility and error messages be evaluated?

Form accessibility is evaluated by more than whether the fields look correct on screen. Labels must be understandable, keyboard order must be logical, required inputs must be explained, and users must know what to do after an error occurs. A strong demo deliberately creates an error and shows how feedback behaves. For example, the vendor can submit an empty required field, an invalid email address, or a missing selection and then show how the error message is associated with the relevant control, how it becomes noticeable, and how the user can recover. Meaning should not depend on color alone.

Which form details should be included in the proposal?

Ask candidates to explain design states and development behavior separately. Normal, focus, error, success, disabled, and loading states can be defined in the design system, while the live product must verify label relationships, keyboard access, error announcements, and post-submission feedback. If the form connects to a third-party CRM, payment system, membership platform, or marketing tool, the boundary of accessibility responsibility should also be documented. That distinction reduces disputes later about whether an inaccessible behavior belongs to the custom interface or to an external integration.

• Confirm that labels are clear and persistent.
• Require errors to be communicated beyond color.
• Test the relationship between errors and fields.
• Review confirmation feedback after submission.
• Document third-party form responsibilities separately.

How should design and development responsibilities be separated?

Design and development responsibilities should be separated clearly enough that accessibility does not disappear between teams. The design team should own states and interaction intent, while the development team should own working behavior and technical implementation. Contrast, typography, component states, visible focus, information hierarchy, and error designs can be defined in design deliverables. Semantic structure, keyboard interaction, focus management, and dynamic content behavior must be verified in live code. Even when one company provides both services, showing these responsibilities as separate work items makes the proposal easier to evaluate.

How do interface deliverables connect to the working product?

Make it clear before contracting that a design file alone does not equal an accessible product. When reviewing which services belong in a web interface design engagement, check whether the vendor delivers a component library, interaction states, and developer guidance. Then ask how the development team will test those definitions in code. A visible focus state may exist in a design file but never be implemented, while a developer may add technically accessible behavior that is not documented in the design system and therefore becomes difficult to maintain.

• Document who defines design states.
• Assign ownership for semantics and keyboard behavior.
• Include component-library delivery in the scope.
• Make live implementation verification a separate stage.
• Define the acceptance point between design and code.

How should test findings and acceptance criteria be delivered?

Accessibility findings should be delivered as reproducible records rather than as a statement that an accessibility check was completed. Each finding should identify the affected screen or component, reproduction steps, expected behavior, priority, and remediation status. Screenshots may help, but they are not sufficient for issues such as keyboard sequence, lost focus, or dynamic announcements, which require procedural detail. If acceptance criteria are agreed before testing begins, the project can be approved against a shared verification list instead of relying on subjective interpretation at the end.

How does report format improve proposal comparison?

Ask candidates for a sample issue record or an anonymized report template to compare the maturity of their process. When comparing website proposals, evaluate not only whether testing exists but also how findings are delivered and who is responsible for retesting. Statuses such as open, fixed, and retested make the handoff between design, development, and client approval more visible. If user testing is offered as a separate service, the proposal should also define the participant profile, scenarios, facilitation method, and deliverables rather than using the phrase as a generic add-on.

• Require reproduction steps for every finding.
• Include expected behavior and priority.
• Use a record structure that tracks remediation status.
• Assign explicit responsibility for retesting.
• Document acceptance criteria before implementation ends.

How should remediation be defined in proposals and contracts?

Whether remediation work is included in the contract should be stated explicitly; otherwise testing and implementation can become two separate purchases. The proposal should define which findings count as corrections within the project scope, which require additional development, and who owns retesting. A new feature request should not be treated the same as an implementation that fails an accessibility acceptance criterion agreed at the start. This distinction reduces budget disputes and shows whether the vendor has a real process for closing findings rather than simply reporting them.

Which contract terms reduce ambiguity?

A contract should go beyond a general sentence promising an accessible design. When reviewing what a web design company contract should include, document the flows to be tested, reporting format, responsible team, remediation cycle, retest process, and acceptance method together. Any limitations caused by third-party plugins or external services should be identified in advance. It can also be useful to define how accessibility will be maintained when new content or components are added after launch, especially when an ongoing maintenance arrangement is part of the engagement.

• Define which remediation tasks are included.
• Separate additional development from defect correction.
• Name the owner of retesting and closure.
• Document third-party component limitations.
• Clarify accessibility ownership during maintenance.

How can candidates be compared with one short test scenario?

A practical way to compare candidates is to give every company the same critical user flow and ask for a short accessibility assessment. A shared scenario makes process differences visible and creates a comparison basis independent of sales language. For example, choose a contact or quote form on your current site. Ask the user to reach it from the menu using only the keyboard, leave a required field empty, identify the error message, correct the field, and complete the form. Then ask each candidate what it would test, how it would record the finding, and which team would be responsible for remediation.

Which outputs should be considered in the final selection?

Evaluate the test scenario, reporting format, and contract scope alongside portfolio quality, visual design, and technical capability. An accessible interface proposal should include more than screen design; it should define development verification, critical-flow testing, issue management, and user testing when relevant. Instead of choosing only the lowest-priced or apparently broadest proposal, compare which providers define responsibilities most clearly and can evaluate your sample flow in measurable terms. This turns accessibility from a broad expertise claim into an actionable quality-control and acceptance process that the buying team can verify.

• Give every candidate the same user flow.
• Request a short live or recorded test demonstration.
• Compare how findings will be delivered.
• Review remediation and retesting together.
• Use acceptance criteria in the final proposal decision.