A website accessibility brief turns a broad request for an inclusive website into work that can be estimated, reviewed and maintained. For a Kenyan business commissioning a new site, the brief should identify the important customer tasks, the scope of evaluation and the evidence expected at handover.
Discuss this early with your website development team. Accessibility should be considered while the navigation, content and components are being designed. Leaving the whole discussion until the final screenshot review makes it harder to distinguish a content correction from a component that needs substantial work.
This guide is a procurement and project-planning worksheet. It is not a legal assessment, a complete technical audit or a certificate that a website conforms to a particular standard.
Start with the tasks people need to complete
List the important journeys before listing individual pages. A visitor may need to understand a service, compare an option, download a document or contact the business. A customer with an account may have a longer journey involving sign-in and reviewing a request. Describe the intended outcome in ordinary language.
For each journey, record the entry page, actions, information needed and final state. This prevents the review from concentrating on the homepage while a more important interaction remains outside the discussion. Include the mobile version and any external component that forms part of the journey.
Ask whose experience is represented in the review. Staff familiar with the site may know where a hidden menu opens or what an unexplained icon means. A first-time visitor does not have that knowledge. Where practical, plan feedback from people who use different interaction methods and relevant assistive technologies.
Do not use an imagined audience to dismiss a barrier. A business cannot tell how every visitor reads or operates a device from the services it sells. The useful decision is which journeys the project must support and how the team will examine them.
Agree the evaluation scope in writing
Ask the developer to name the proposed accessibility target and evaluation approach. If a specific standard or conformance level is part of your requirement, put it in the scope and ask the evaluator to explain what evidence they will provide. Avoid accepting the phrase “fully accessible” without a defined meaning.
W3C's Easy Checks resource explicitly distinguishes a preliminary review from a comprehensive assessment. A page can appear to pass those introductory checks and still contain significant barriers. Use an initial review to identify questions, then commission the depth of evaluation your project needs.
Identify the page types and interactive states included. A service page, a search panel, an account screen and an enquiry form may use different components. The proposal should explain how representative coverage is chosen and which unusual journeys require separate attention.
Record exclusions and dependencies. If an external booking widget or downloadable document is outside the developer's control, name its owner and the review decision. An exclusion should be visible to the business rather than hidden inside a general statement about third-party services.
Build a representative sample before approval
Choose sample content that exposes real layout and interaction demands. Include a long organisation name, a detailed service description, an image with meaningful information and a form with several states. Empty templates and short placeholder text can conceal problems that appear only after business content is added.
Ask the team to review both reusable components and complete journeys. A navigation control may be used across the entire site, while an unusual quotation calculator may appear once. The testing plan should reflect those differences instead of treating every page as an isolated picture.
Include documents and media in the inventory. If an important instruction is available only through a PDF or video, decide how its accessibility will be evaluated and who supplies the necessary source material. The website team's responsibility and the document supplier's responsibility should fit together.
Keep sample selection small enough to review properly but broad enough to expose different behaviour. Agree how findings from that sample will be checked elsewhere. Fixing one card or one form is not sufficient if the same pattern appears in several other places.
Ask for demonstrations with clear outcomes
Prepare a review session around tasks rather than asking the developer to click through a finished design quickly. Tell them what a visitor should achieve, and request an explanation of the interaction methods and assistive-technology checks included in their evaluation.
For example, an illustrative task might be to find a service, open its enquiry route and understand what information is required without submitting a live lead. Record where the reviewer cannot identify the next action. Ask the developer to explain the proposed correction and how it will be retested.
Agree safe environments for interactions that create records. A quotation request or booking can trigger CRM workflows and reporting. Use controlled test arrangements for those steps, with fictional information and agreed exclusions. Accessibility evaluation should not accidentally create customer follow-ups or advertising events.
Keep the evidence connected to the specific build and page state. A screenshot may illustrate a problem, but a task description explains how it arose. Record the browser, device or assistive technology relevant to the finding when the evaluator needs that context for reproduction.
Separate content responsibilities from development work
Name the people who approve headings, link wording, image descriptions and media alternatives. These decisions involve business meaning as well as implementation. A developer cannot reliably describe an unfamiliar project photograph without information about what it shows and why it is on the page.
Use the website image content brief to keep image purpose, captions and approvals organised. Ask the implementation team how those approved decisions will be represented in the finished page. Do not assume an upload form's default values are suitable for every image.
Review link wording in its actual context. The editor should understand where the destination leads and what information the visitor needs before choosing it. Repeated generic labels can be a sign that the content has not been reviewed as navigation, even if the design looks tidy.
Document who supplies missing material. If a video needs additional editorial work or a PDF needs a separate review, assign an owner and status. Do not mark the overall content complete while essential supporting assets remain unresolved in a messaging thread.
Make corrections traceable and test them again
Use an issue register with the affected journey, observed barrier, expected outcome, owner and retest result. Ask the evaluator to distinguish severity and scope so that the business can understand which findings stop an essential task and which require a different priority.
Group shared-component issues carefully. A correction to the main menu may affect many pages, while a correction to one document may not. Record the affected locations and request confirmation that the team has reviewed related uses after changing a common component.
Do not close an issue only because a new screenshot looks better. Repeat the interaction that produced the finding and record the result. Where the original issue involved an assistive technology, have the appropriate evaluator confirm the correction using the agreed method.
Keep unresolved limitations visible at acceptance. The business should know whether an item is fixed, awaiting an external supplier or excluded from the current release. A clear limitation is more useful than a broad compliance claim that the evidence does not support.
Include accessibility in everyday editing
Plan training around the updates staff will actually make. An editor replacing a service image, adding a heading or publishing a document needs guidance relevant to that task. Ask for examples using the site's own content tools instead of relying only on a generic presentation.
Agree which changes require developer review. A new interactive widget, a redesigned navigation or a different external form may introduce behaviour outside routine content editing. Staff should know when to request help before publishing a component that has not been evaluated.
Add the issue register, responsibilities and evaluation evidence to the website handover record. Keep credentials separate. The handover should help a future supplier understand the existing target and outstanding limitations without recreating the entire project history.
Schedule reassessment around meaningful changes as well as the support arrangement. A site can change after launch through new content, external tools and redesigned journeys. The aim is an ongoing process with accountable owners, not a badge added once and forgotten.
Frequently asked questions
Does a good mobile layout prove accessibility?
No. Screen-size adaptation is one part of a website experience. Ask for evaluation of the intended journeys and interaction methods under a defined scope rather than treating a phone screenshot as proof of comprehensive accessibility.
Is an automated score enough to approve the website?
Use it as one source of evidence within the agreed evaluation process. Ask what was examined manually, which journeys were tested and which limitations remain. A single number should not replace a clear account of the work performed.
Should our external forms be included?
List them whenever they form part of an important customer journey. Agree who evaluates them and who can request corrections from the supplier. The enquiry form acceptance guide covers routing and controlled submission checks as a separate concern.
What should we send when requesting development?
Share the important journeys, content types, external tools and any stated evaluation requirements. Get a free quote and ask for accessibility planning, evaluation evidence, corrections and editor training to be described in the proposed scope.
