November 13, 2026 · Faith Forge Labs Editorial Team
Accessibility Questions to Include in a Website Project
Make accessibility part of the agreed work from the beginning. Ask how important tasks will be tested, which barriers will be fixed and what evidence the team will provide.
“Make it accessible” is a useful intention, but it leaves important questions unanswered. Which tasks will be checked? Who will test them? What happens when a problem is found? A website project needs those decisions before the final review.
You do not need to know every technical criterion to ask for a clear scope and useful evidence. Start with what visitors need to do and the ways they may interact with the site.
Put essential tasks in the brief
List the journeys that matter: finding service information, completing an enquiry, downloading a document or managing a booking. Include the steps before and after submission, not just the first screen.
For a hypothetical enquiry journey, ask whether a visitor can reach each field without a mouse, understand the instructions, correct an error and recognise that the form has been submitted. A visually tidy form can still make one of those steps difficult.
Agree the accessibility target and the pages, components and documents included in the work. If a third-party booking tool is part of the journey, name it in the scope rather than assuming another supplier has already checked it.
Ask what the testing will cover
- Keyboard navigation, visible focus and usable controls.
- Text enlargement and narrow-screen layouts without lost content.
- Meaningful headings, links and image alternatives.
- Clear field labels, instructions and error recovery.
- Appropriate testing with assistive technology.
Ask who performs the checks, which representative tasks they follow and how findings are recorded. Automated tools can help identify some problems, but their output should not be the entire assessment.
The W3C's Easy Checks offers an introductory review and explicitly explains its limits: passing a few basic checks does not establish comprehensive accessibility. Use that distinction when comparing a quick scan with a broader evaluation.
Include the content your team supplies
Accessibility can be affected by content added after development. A vague button label, an image containing important text or an inaccessible download can interrupt an otherwise usable page.
Assign responsibility for the words, images, documents and video included at launch. Ask for editing guidance so staff understand how to maintain headings, descriptive links and appropriate alternatives when they make changes. The W3C forms tutorial is useful background for discussing understandable labels, instructions and feedback.
Agree how findings affect launch
Request a report that identifies the affected task, the barrier and the proposed correction. Decide who verifies fixes and which unresolved issues prevent an important task from being completed.
Where users still need help, provide a clear support route and make its limitations visible. A support phone number does not make the inaccessible part of a website disappear; it is one part of serving people while the underlying work is addressed.
Keep the test scope and remaining findings with the handover records. Plan further checks after substantial layout, content or third-party changes. For a new build or redesign, include accessibility in the initial discussion so its tasks, evidence and ownership can be agreed with the rest of the project.