How Should You Evaluate Accessibility Testing When Choosing a Website Company?

How should an accessibility claim be verified in vendor interviews?

A company’s accessibility capability should be verified through a demonstrable testing process rather than broad promises. During the interview, ask which standard or project criteria are targeted, at what stages checks are performed, how findings are recorded, and who closes remediation items. Saying “we build accessible websites” is not enough; the prospective team should be able to explain how accessibility is tracked from design decisions through development and content entry.

Core evidence to request in the first meeting

A capable accessible web design company can usually show sample checklists, anonymized finding records, or delivery formats while respecting confidentiality. It is especially useful to understand how the team prevents recurring problems in shared components. This lets the buyer evaluate not only a final result, but also how an issue was discovered and how the process was improved so the same problem is less likely to appear again.

• A sample accessibility audit output or finding classification
• How before-and-after remediation records are maintained
• Testing roles and the involvement of an accessibility specialist
• Control and verification documents delivered to the client

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

What examples prove a company’s accessibility experience?

Experience should be measured not by the number of websites described as accessible, but by whether the vendor can explain problems encountered and how they were resolved. The company should be able to discuss checks involving form fields, navigation menus, modal dialogs, tables, media, or keyboard focus. It should also explain how findings discovered during the project are routed to design, front-end, back-end, or content teams.

Move from portfolio appearance to process evidence

A portfolio is useful, but it does not prove technical capability by itself. Consistent with assessing a web design company’s technical competence, buyers can request an accessibility case example that shows the problem, intervention, and verification chain. A strong example goes beyond saying a page was “made compliant” and explains why a specific interaction was problematic and how the fix was tested again.

• Test scenarios used on projects with comparable scope
• Typical access barriers found in critical components
• How remediation decisions are reflected in the design system
• How retesting and issue closure are documented

How should automated and manual accessibility tests be combined?

Automated and manual accessibility tests are not alternatives; they are complementary layers of the same quality plan. Automated tools can quickly flag certain code and structural issues, but questions such as whether keyboard order is logical, screen reader announcements make sense, or a task can actually be completed require human evaluation. A proposal should therefore show clearly where each testing method is used.

Define testing layers with separate responsibilities

For corporate website quality control, automated scans, developer checks, and scenario-based manual tests can be organized as a sequence. When automation coverage and human evaluation are defined separately, it becomes easier to understand what the resulting report actually proves. The vendor should also explain which findings come from tools, which come from specialist review, and how conflicting results are resolved.

• Code-level automated scanning and repeatable checks
• Completing core tasks using only the keyboard
• Screen reader navigation and meaningful announcement checks
• Mobile layout, zoom, and reflow scenarios

What questions should be asked about the accessibility test plan?

A test-plan discussion should go beyond asking, “Which tool do you use?” Ask the vendor how pages and components are selected for testing, how critical user tasks are identified, which device and assistive-technology combinations are covered, how finding severity is defined, and under what conditions retesting occurs. These questions separate a real service scope from a generic promise to perform a final check.

Make the testing approach visible before the proposal is signed

To structure vendor interviews, the questions to ask when requesting a web design proposal can be expanded specifically for accessibility. If user testing is included, also ask about participant profiles, task scenarios, recording methods, and how findings are converted into project actions. The objective is to understand whether testing is a one-time pre-launch activity or a quality loop repeated throughout development.

• The list of pages, templates, and components in test scope
• How keyboard and screen reader scenarios are executed
• How findings are prioritized and assigned to responsible teams
• When retesting occurs after remediation

Is remediation of accessibility issues included in the price?

Whether remediation is included should be stated clearly in the proposal and contract. Some scopes cover audit and reporting only, while others include development fixes and retesting. For that reason, the phrase “accessibility testing included” is not specific enough; buyers should clarify which classes of issues are expected to be resolved within the existing development scope and which situations would be treated as additional work.

Match remediation scope to delivery criteria

Cost interpretation becomes clearer when the proposal defines the remediation cycle, responsible team, and re-verification method for accessibility findings. Buyers can also ask how accessibility criteria fit into the same quality plan as the technical features expected in a professional website. If testing services and remediation services are separate scopes, that separation should be visible in proposal line items so competing offers can be compared accurately.

• The testing and documentation included in the audit scope
• How issue remediation relates to the existing development scope
• New content or component changes that may count as additional work
• Where retesting and issue closure fit within the proposal

How should design and development teams manage shared components?

An accessible web development team should not leave accessibility entirely to a specialist at the end of the project; it should treat it as a shared responsibility within the design system, interface components, and coding rules. When accessibility decisions are defined centrally for reusable elements such as buttons, form fields, dropdowns, modals, tabs, error messages, and navigation, the risk of repeating the same problems across pages is reduced.

Ask how the component lifecycle is controlled

Ask prospective vendors what accessibility checks a new component must pass, how design states are communicated to developers, and how validated examples are preserved in the code library. Content teams should also participate in areas such as heading hierarchy, meaningful links, alternative text, and form instructions. This operating model shifts the accessibility specialist from being a last-minute issue hunter to a quality advisor embedded in the system.

• Accessible states and interaction rules in the design system
• Keyboard and focus behavior checks in developer components
• Editorial accessibility rules for content teams
• Approval and reuse procedures for new components

How should accessibility acceptance criteria be written into a contract?

Acceptance criteria should be defined with testable conditions rather than an open-ended sentence such as “an accessible website will be delivered.” The targeted accessibility standard or internal criteria set, included templates, critical tasks, test methods, unacceptable issue types, and retesting process can be documented in the contract appendix or technical specification. This makes delivery evaluation depend on agreed evidence rather than personal interpretation.

Connect contract language to the testing plan

When reviewing what a contract with a web design company should include, accessibility makes scope, change management, responsibility, and acceptance particularly important. The acceptance criterion should, where appropriate, be tied to an agreed target such as WCAG 2.2 AA, project-specific exceptions, and the pages or components that will be tested. Any exception should include its rationale and the next action.

• The targeted standard or internal accessibility criteria
• In-scope page templates and critical user tasks
• Acceptance, remediation, and retesting conditions for findings
• How exceptions are approved and documented

Who checks accessibility of new pages after launch?

Responsibility for reviewing new pages and content after launch should be assigned explicitly. Even if the website is accessible at initial delivery, later campaign pages, forms, images, third-party components, or content updates can introduce new barriers. The organization should therefore define which checks belong to the internal content team, agency, or maintenance provider and which changes trigger renewed testing.

Plan maintenance together with content governance

A post-launch quality plan can also be evaluated when determining what should be included in corporate website services. Checklists for CMS editors, technical approval for new components, and recurring review procedures can be defined. Sustainable accessibility is protected less by a single handoff report than by a responsibility chain that activates whenever changes are made.

• A checklist for editors when publishing new content
• A developer approval process for new templates and components
• Reassessment of third-party tools and plugins
• Ownership of finding records and closure during maintenance

What accessibility evidence should be requested at delivery?

Delivery evidence should show not only that the project was “tested,” but what was evaluated and what the results were. The organization can request a list of tested pages and components, methods used, issues found, closed items, accepted exceptions, and retest results. These records make it easier to understand past decisions during maintenance and to evaluate new changes against the same criteria.

Use the report as a decision and maintenance tool

A useful handoff package is more than a long issue table; it explains how a finding affected a user task and what action closed it. Context such as screenshots, component names, or test scenarios can be added. Any open item should also state why it remains open, who owns it, and how it will be addressed in a later release. This turns corporate website quality control into a process that can be transferred and continued.

• A concise summary of test scope and methods used
• Findings recorded by status, priority, and owner
• Closure evidence for items that were retested
• Exceptions and issues requiring post-launch follow-up

How should the accessible website company selection be finalized?

Choosing an accessible website company should be finalized not on portfolio aesthetics alone, but on how clearly each candidate defines testing scope, specialist roles, remediation responsibility, acceptance criteria, and post-launch control. Asking every vendor the same question set, recording answers in a common comparison framework, and resolving vague promises before the contract is signed creates a stronger basis for procurement.

Base the final decision on testable commitments

In the final proposal review, price should not be the only deciding factor; buyers should read together which tests will actually be performed, who will fix findings, and what evidence will be delivered. A well-defined scope gives the client and provider a shared understanding of accessibility and reduces surprises at handoff. The most valuable outcome of vendor selection is therefore making the accessibility claim measurable through the contract, test plan, and delivery documents.

• Use the same testing and delivery questions for every candidate
• Compare automated and manual testing scope separately
• Confirm remediation and retesting responsibilities in writing
• Assign post-launch content and maintenance duties to named owners