How to evaluate a web design tender (or RFP)

Why evaluation matters

Tenders and RFP responses often look similar on the surface. The difference is in how they will deliver: who does the work, how they test quality, and whether they can back up what they claim [1]Source 1 .

This guide helps you ask the right questions and spot red flags, especially around accessibility and delivery.

For more on hiring and process, see what to ask before you hire a web designer and we build accessible sites: show me your process.

What to ask about the team and process

• Who actually does the work? Names and roles. Will you work with the people who wrote the proposal, or a different team?
• How do they communicate and report? How often, in what format (e.g. written updates, calls), and who is your main contact?
• What is their change and scope process? How do they handle new requests or scope creep? What is in scope and what is not?
• How do they hand over? What do you get at the end (code, content, docs, training)? Who owns the code and assets?

For more on contracts and ownership, see website project contracts and website ownership and intellectual property.

What to ask about accessibility

If the response says “we do accessibility” or “WCAG compliant,” dig deeper [2]Source 2 .

• How do they test? Do they test with keyboard only? With a screen reader (e.g. NVDA, VoiceOver)? Do they use automated tools plus manual testing?
• Who tests? Is it the same people who build, or someone independent? Do they involve disabled users?
• What do they deliver? An accessibility statement? A report? Remediation of issues? Ask for a sample or a previous deliverable (redacted if needed).
• What standard do they work to? WCAG 2.2 Level AA is the usual target for public sector and many charities [3]Source 3 . Do they reference it and can they explain how they meet it?

Red flag: “We use an overlay” or “We add a widget for accessibility.” Overlays do not fix underlying issues and are not a substitute for built-in accessibility.

For more on what to look for, see accessibility claim checklist and what accessibility means.

What to ask about performance and quality

• How do they measure performance? Core Web Vitals, page weight, load time? Do they set budgets and test before launch?
• How do they handle content and SEO? Do they advise on structure, titles, and meta descriptions? Or is that out of scope?
• What is their testing and QA process? Do they test on real devices and browsers? Do they have a staging or test environment?

Red flags

• Vague on who does the work: No names, or “our team” without roles. You cannot evaluate a team you cannot see.
• Accessibility as an add-on or overlay: Accessibility should be part of the build, not a bolt-on or a widget.
• No evidence of past work: No case studies, no references, no sample deliverables. Ask for at least one and follow it up.
• Unrealistic timelines or price: If it sounds too good to be true, ask how they will deliver. What is excluded?
• No contract or unclear ownership: You need a clear contract that covers scope, ownership, and what happens if things go wrong.

Summary

Ask who does the work, how they communicate, and how they hand over. For accessibility, ask how they test, who tests, what they deliver, and what standard they work to; avoid anyone who relies on overlays. Ask about performance, SEO, and QA; watch for vague answers, no evidence, or unrealistic promises.