How Should Accessibility Deliverables Be Audited When Choosing an Accessible Corporate Web Design Company?

Why Should Accessibility Deliverables Be Measured in Selection?

Accessibility deliverables should be measured through test methods, acceptance criteria, and retest records rather than a provider's statement of intent. A claim that a company “builds accessible websites” does not prove that keyboard use, focus visibility, form feedback, or content structure has actually been verified. The foundation of provider comparison is defining before the proposal which evidence will be required to accept accessibility work.

Ask for verifiable deliverables instead of general promises

The proposal should list test scope, tested templates, methods used, issue severity levels, remediation ownership, and the retest process as separate deliverables. Reviewing how accessibility tests are evaluated when choosing a custom web design company can help distinguish providers that submit only tool output from those that validate real usage scenarios. The accessibility acceptance process should be handled separately from visual design approval.

• Test scope should be clearly defined in the proposal and contract.
• Acceptance criteria should be tied to measurable user tasks.
• Identified issues should be classified by severity.
• A remediation retest deliverable should be required.
• The organization should assign a final pre-launch acceptance owner.

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

Which Page Templates and Components Should Be in Test Scope?

The provider should test not only the homepage but all critical page templates and interactive components that represent real user tasks. If the corporate website includes content pages, listings, search, contact forms, career applications, document downloads, login areas, or private portals, each relevant template should be explicitly included in scope. Test scope should be defined by functional and component variety rather than by page count alone.

A component inventory reveals the hidden portion of proposal scope

Menus, modal dialogs, tabs, accordions, filters, date pickers, cookie components, and embedded third-party tools each create different risks. For that reason, guidance on what should be defined when requesting an accessibility proposal from a website company helps show why a component inventory should accompany the page list. Instead of vague language such as “sample pages will be tested,” the proposal should identify which templates and components are included.

• Primary navigation and mobile menus should be tested with separate scenarios.
• Forms, error states, and success messages should be included.
• Search, filtering, and sorting interactions should be evaluated.
• Dynamic components such as modals, tabs, and accordions should be tested.
• The scope of video, documents, and embedded content should be stated.
• Third-party tools should appear in a separate component inventory.

How Should Automated Scanning and Manual Testing Work Together?

Automated accessibility scanning provides a fast starting point, but it should not be used as the sole acceptance test. Tools can detect certain code and markup issues, while questions such as whether focus order is logical, an error message is understandable, or a task can be completed using only a keyboard require human evaluation. A reliable delivery process should combine automated checks, expert review, and task-based manual testing.

Manual tests should be written as a separate method and deliverable

It is useful to ask candidate firms which scanning tools they use, but the more important question is which scenarios they test manually. Tasks can include navigating menus, completing forms, correcting errors, opening and closing modals, and moving through content. For every scenario, the provider should report the expected result, identified issue, remediation status, and retest outcome. This shifts evaluation away from an automated score and toward verifiable user behavior.

• Automated scanning should run repeatedly during development.
• End-to-end task completion with a keyboard should be tested separately.
• Focus order and focus visibility should be verified manually.
• Form error messages should be reviewed for content and behavior.
• Dynamic components should be checked for opening, closing, and focus return.
• Retest results should be linked to the original finding.

What Are Acceptance Criteria for Keyboard Focus Forms and Images?

Acceptance criteria should be written around user tasks rather than an abstract definition of “accessible.” Verifiable outcomes can include being able to use all essential functions with a keyboard, keeping focus indicators visible, associating form errors with the relevant fields, and providing appropriate alternatives for meaningful images. An acceptance scenario should be specific enough that another tester can repeat the same steps and verify the same result.

Each criterion should define the expected result and failure condition

Instead of writing “keyboard compatible,” the requirement can describe a complete task such as navigating from the menu to a contact form, completing the fields, understanding an error, and submitting the form. The same approach can be applied to heading hierarchy, link text, image descriptions, and content order. The content management system should also allow editors to create accessible headings, links, and image descriptions as part of the delivery criteria.

• All essential controls should be reachable with a keyboard.
• Focus order should follow the visual and functional flow.
• The focus indicator should remain visible during interaction.
• A form error should be clearly associated with its relevant field.
• Meaningful images should have an appropriate text alternative.
• The content heading structure should reflect page logic.

Who Should Own Remediation in Accessible Interface Development?

The proposal should define who will fix identified accessibility issues and within what process. Problems caused by design, front-end development, content, and third-party components may not belong to the same team. The provider should be responsible not only for delivering a report but also for fixing defects within the scope it developed and retesting those fixes.

Issue classification makes the remediation schedule manageable

Each finding can be assigned a severity level, affected template or component, responsible team, target remediation date, and retest status. When source code, maintenance, and post-launch services are purchased together, auditing code ownership, accessibility, and post-launch SLA provides a complementary framework for defining remediation responsibility in the contract. Issues created by the organization's content team should follow a separate workflow.

• Each finding should have one accountable team.
• Remediation priority for critical issues should be defined contractually.
• The remediation scope for provider-built components should be explicit.
• Content-related issues should be routed separately to internal editors.
• Third-party issues should receive an alternative solution or risk record.
• Closed findings should be verified through an independent retest.

How Should Accessibility Training for Content Editors Be Delivered?

Training for content editors is a core deliverable for preventing accessibility from deteriorating after launch. Even when the technical team builds an accessible template, editors can reintroduce barriers by using incorrect heading levels, vague link text, missing image descriptions, or inaccessible documents. Training should use practical tasks in the organization's actual content management system rather than functioning as a general awareness presentation.

Training outputs should connect directly to daily publishing work

The proposal should specify which editor tasks will be taught rather than focusing only on training duration. Examples include creating a new page, preserving heading structure, writing link text, adding image descriptions, uploading tables or documents, and using a pre-publication checklist. A short editor guide, content checklist, and repeat-training model can help make accessibility an operational responsibility rather than knowledge held only by developers.

• Training should be delivered in the organization's actual CMS.
• Heading structure and link text should be explained with examples.
• Responsibility for writing image descriptions should be clarified.
• Rules for documents and media uploads should be covered separately.
• A pre-publication editor checklist should be delivered.
• A repeat-training method should be defined for new team members.

What Is Accessibility Ownership for Third-Party Components?

If third-party components are excluded from accessibility scope, that exclusion should be explicit; if they are included, the provider's ability to intervene should be defined. Cookie management, maps, chat, video players, application systems, or embedded forms may use codebases outside the main website. The contract should document components that cannot be fully controlled through risk, alternatives, and ownership boundaries rather than making them invisible.

Provider selection and integration choices affect accessibility

Even if the web design company cannot change a third-party tool's source code, it may be able to recommend an alternative product, change the integration method, or provide an accessible fallback flow. During proposal review, a general exception such as “third parties are not our responsibility” should be replaced by a clear explanation of which component is excluded, why it is excluded, and what options remain available to the organization. This prevents access barriers from becoming a surprise at the end of the project.

• Each third-party component should appear separately in the inventory.
• Testable areas and intervention limits should be identified.
• An alternative product should be considered for critical issues.
• An accessible fallback user flow should be designed when necessary.
• The contract should state whether vendor updates require retesting.
• Acceptance exceptions should be explicitly approved by the organization.

How Should a Post-Launch Accessibility Maintenance Plan Be Built?

Post-launch accessibility ownership should be planned around the fact that the website will continue to change. New campaign pages, CMS updates, third-party integrations, and interface revisions can invalidate previously passed tests. The maintenance plan should therefore include recurring checks, change-triggered testing, and clear ownership instead of offering support only after a problem appears. Accessibility is not a one-time deliverable; it is a quality process tied to change management.

The maintenance contract should define triggers and retest scope

It may not be necessary to manually test the entire site every month; a risk-based model can be used instead. A new component, design system update, CMS version change, form-flow change, or third-party tool replacement can trigger retesting. Periodic automated scans and scheduled sample manual checks can also be planned. The agreement should state who receives the report, which findings are fixed within maintenance, and which work is treated as new development.

• Change-triggered retesting events should be defined.
• The recurring automated scan interval should be stated in the proposal.
• The scope and frequency of sample manual tests should be explained.
• Maintenance fixes should be separated from new development.
• New content should pass an editor accessibility check.
• An internal owner should be assigned for accessibility reports.

How Should Accessible Corporate Web Design Proposals Be Compared?

When comparing accessible corporate web design company proposals, do not evaluate price alone. Review test scope, manual testing methods, remediation ownership, retest deliverables, editor training, and the post-launch maintenance model together. The same phrase, “accessibility testing included,” can represent very different levels of work and responsibility across providers. A comparable proposal is one in which every provider responds to the same acceptance scenarios and the same required delivery evidence.

Standardizing the request makes provider differences visible

Comparison becomes easier when all candidates respond to the same page templates, component inventory, and acceptance scenarios. When evaluating the cost dimension, reviewing how website pricing proposals that include accessibility testing are compared can help separate testing and remediation scope from the broader budget. In the final selection, the provider should demonstrate not only that it can identify issues, but also that it can close them, retest them, and define ongoing maintenance responsibilities.

• The same test scope should be sent to every candidate provider.
• Manual testing should appear explicitly as a proposal line item.
• Issue classification and remediation schedules should be compared.
• The retest and acceptance report format should be requested.
• Editor training and maintenance ownership should be separate items.
• Third-party component exceptions should be disclosed before contracting.