What Should Be Defined When Requesting an Accessibility Proposal From a Website Company?

How does accessibility become a measurable proposal scope?

Accessibility work should be defined as auditable and deliverable work packages rather than as a general design improvement. When the request for proposal separately identifies the current site condition, target pages, shared components, content types, third-party tools, and testing method, vendors can price a more comparable scope. This separation also makes it easier to see which work package is affected by later scope changes and to distinguish additional requests from the original proposal.

Separate the work packages before pricing

One vendor may price only technical fixes while another includes design and content revisions in the same line item. The request should therefore distinguish audit, design, development, content, testing, and maintenance. It should also identify the accessibility standard or internal acceptance target and explain how delivery will be validated rather than relying on the standard name alone.

• Current-state accessibility audit
• Page and component inventory
• Design and interaction remediation
• Front-end development work
• Content and document updates
• Manual and tool-assisted testing

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

How should the initial accessibility audit be included?

The initial audit may be included in the overall price or defined as a separate discovery service; what matters is making that choice explicit before proposals are compared. If the size of the existing site, template variety, or technical debt is not yet known, requesting an audit deliverable before committing to a fixed remediation scope can help define the later work packages more realistically.

Put the audit output and boundaries in writing

The audit proposal should state how many pages or templates will be sampled, how shared components will be reviewed, which manual tests will be performed, and how findings will be classified. To structure the broader proposal process, the questions to ask when requesting a web design proposal can also place accessibility-specific requirements within a wider purchasing framework.

• Whether the audit is separate or included
• Number of sample pages to review
• Shared components to be checked
• Scope of manual testing
• Finding prioritization method
• Audit report delivery format

Which pages and components should be included in pricing?

Pricing should include not only individual page URLs but also templates and components that repeat across the site. In addition to templates such as the home page, content page, or product page, interactive elements such as menus, search, modal dialogs, forms, filters, tabs, accordions, and error messages can materially affect the accessibility workload.

Complete the URL list with a component inventory

Hundreds of URLs may be generated from only a few templates, while a small number of URLs may contain many different interactions. For that reason, proposal scope should not be reduced to page count; unique templates, components, and user flows should be counted together. If a new-site project has a design system or component library, the proposal should identify which elements will be revised against accessibility criteria. This inventory also reveals whether a repeated issue can be fixed in one root component instead of being priced separately across many pages.

• Unique page templates
• Global menu and navigation
• Forms and validation messages
• Modals, tabs, and accordions
• Search and filter components
• File and document links

How should design remediation be separated in the proposal?

Design remediation should be separated from development work and should show which screens and components require redesign. Decisions involving color contrast, focus visibility, form labels, error feedback, motion controls, and interaction states can make development scope more predictable when they are resolved before coding begins.

Treat design delivery as more than visual revision

Accessible design is not limited to changing a desktop screenshot. Keyboard focus, error states, empty states, validation messages, and behavior at different screen sizes should also be represented in the design deliverables. If the vendor uses a design system, normal, focused, selected, disabled, and error states should be defined for each relevant component so the development team receives a consistent implementation reference.

• Color and contrast decisions
• Focus and interaction states
• Form label and error patterns
• Controls for moving content
• Responsive usage scenarios
• Component state design

How should development and content work be separated?

Front-end development and content remediation should be listed separately because ownership, expertise, and workload differ. Semantic HTML, keyboard interaction, focus management, and dynamic component behavior may belong to the development scope, while alternative text, link clarity, heading structure, and document updates may be owned by a content team.

Clarify proposal scope with a responsibility matrix

The vendor should state which content it will update directly, which items will receive guidance only, and what inputs are expected from the client team. The framework explaining what a website price quote should include can also make the boundary of accessibility development within the broader website project more visible by separating design, development, and support line items.

• Semantic HTML revisions
• Keyboard interaction behavior
• Focus management and component logic
• Alternative text and content revisions
• Heading and link structure
• File and document improvements

Who should own third-party forms and embedded tools?

Responsibility for third-party forms, chat widgets, maps, booking tools, payment elements, or embedded content should be explicitly assigned during the proposal stage. A website company may be able to change its own code but may not be able to modify a closed third-party component, so issue identification, vendor communication, alternative solutions, and out-of-scope acceptance conditions should be defined separately.

Separate the area of control from external dependency

For each third-party tool, the proposal should identify the technical owner, the action to be taken when an accessibility issue is found, and the alternative user flow to be provided if remediation is not possible. External components used in critical transactions should not simply be excluded as “client-owned”; at minimum, the risk and feasible options should be documented.

• Third-party tool inventory
• Technical ownership information
• Limits of modification
• Provider notification process
• Alternative user flow
• Out-of-scope acceptance condition

How should accessibility improvements be tested and delivered?

Accessibility improvements should not be delivered solely on the basis of an automated scan. Automated checks, keyboard-use testing, focus-order review, form behavior, and appropriate assistive-technology checks should be considered together. The proposal should describe the test method, sampled pages, browser or device coverage, and any remaining findings accepted at delivery. It should also distinguish whether testing consists only of the developer’s own check or includes a second verification round.

Make delivery a verification record, not an error list

The final delivery package should include the list of completed changes, retest results, closed findings, and issues that remain unresolved. It should also explain whether an open finding remains because of a technical constraint, content responsibility, or third-party dependency. This allows the client to make acceptance decisions based on verification steps and documented remaining work rather than on a simple statement that the site was “fixed.”

• Automated check results
• Complete keyboard-use testing
• Focus order and visibility review
• Form and error-message testing
• Assistive-technology verification
• Record of remaining findings

Which criteria should determine page remediation priority?

Prioritization should not be based only on the most visited pages. Traffic, transaction importance, user complaints, critical conversion steps, and the reach of repeated components should be considered together. A fix to a shared menu or form component can affect many pages, so some component-level improvements may deserve higher priority than a single high-traffic page.

Evaluate business impact and access barriers together

It is important that the vendor can prioritize findings by user impact rather than simply by error count. When assessing the provider’s technical approach, the criteria for evaluating a web design company’s technical competence can help test its ability to diagnose root causes, implement component-level solutions, and manage regression risk in accessibility work.

• Traffic and usage intensity
• Transaction and conversion criticality
• User feedback and reported barriers
• Impact of repeated components
• Severity of the usage barrier
• Technical dependency and regression risk

How should maintenance support cover new content?

Maintenance support should be defined not merely as fixing recurring defects but as a process that preserves accessibility quality for new pages, content, and components. Without checkpoints for content editors, designers, and developers, new additions made after the initial project can reproduce the same barriers that were previously removed.

Define the scope and ownership of ongoing checks

The maintenance proposal should state the scope of periodic reviews, who will test new components, which checklists will be provided to content teams, and how major changes will be revalidated. When comparing technical proposals, the approach to comparing website development companies’ technical proposals can also help separate maintenance and support responsibilities from the initial development scope.

• Scope of periodic reassessment
• Acceptance checks for new components
• Content editor checklists
• Design system update rules
• Revalidation after critical changes
• Finding tracking and closure process

How should different accessibility proposals be compared?

Different proposals should first be compared on whether they cover the same work packages, not on total price alone. When the initial audit, page and component inventory, design-development boundary, third-party responsibilities, testing method, remaining-finding record, and maintenance approach are converted into one common checklist, it becomes easier to see which scope differences explain the price differences.

Make the decision through delivery criteria

The proposal should define not only what will be done but also the conditions under which the work will be considered complete. If it clearly answers whether the initial audit is separate or included, which pages and components are priced, who owns third-party tools, how improvements will be tested and delivered, and how maintenance for new content will continue, vendors can be compared more reliably. Any unresolved points should be clarified before contract signature. Sending the same checklist to every candidate also exposes missing scope earlier, keeps proposal revisions controlled, and allows the purchasing team to compare the actual work to be delivered rather than only the total amount.

• Compare scope on the same basis
• Separate audit from implementation
• Document responsibilities clearly
• Define testing and acceptance methods
• Record remaining work
• Specify the maintenance model separately