KENYA · GUIDE 0591 · EDITION 4.2
Website accessibility audit in Kenya: Marketing and Finding Buyers
Reach a buyer who can accept the offer
Businesses and organizations improving user access.
Offer an example issue report and explain what user testing is excluded.
Begin with the problem and specification rather than promising a return on investment you cannot establish. The proposed output is: Assess a website against an agreed accessibility scope and report evidence.
Make the first message specific
Explain what you will deliver, what is excluded and what the prospect needs to confirm before a quotation. Use this scope when preparing a sample, demonstration or introduction:
Audit agreed website pages and customer tasks, specifying review methods, assistive-technology checks, and the distinction between observed barriers and a formal compliance opinion.
Ask who approves purchases, who accepts the output and how payment is arranged. These can be different people. An informal recommendation is useful for an introduction but does not replace the buyer's approval.
Use proof that matches the promise
Ask users or reviewers to complete keyboard navigation, form submission, and content-reading tasks, documenting reproducible barriers with the relevant page and context.
Keep approved examples, inspection records or handover evidence that demonstrate this result. Obtain permission before using a customer's name, photograph, premises or work. Do not invent reviews, imply an endorsement or display private contact details as marketing proof.
Follow the lead through to collection
| Stage | What to record |
|---|---|
| Contact | Source of the introduction and permission to follow up. |
| Qualified enquiry | Required specification, buying authority and timing. |
| Quotation | Scope, exclusions, price, delivery and payment stages. |
| Accepted result | Ask users or reviewers to complete keyboard navigation, form submission, and content-reading tasks, documenting reproducible barriers with the relevant page and context. |
| Repeat decision | Record tested pages, browser and tool context, task failures, supporting observations, suggested remedies, and limitations preventing the findings from implying universal website accessibility. |
Review a few representative pages and a key task.
Review what it cost to obtain and fulfil a paying order, including travel and follow-up. High enquiry counts do not compensate for a route or delivery arrangement that loses money. Keep cancellations, complaints and refusals visible when evaluating a channel.
An audit is weak when it reports generic warnings without showing which customer task is blocked or how a developer can reproduce it.
Expand outreach only when the promised scope can be delivered reliably. Use permission-based follow-up and an achievable response time instead of bulk unsolicited messages.
A scope-led outreach draft
The supplied draft below is ready to adapt, not a message already sent:
Hi [owner], I can review five pages and your enquiry journey for practical keyboard, form and readability barriers. You will receive reproducible issues and acceptance checks, with untested areas explicit. Please share the pages and any staging access so we can agree a realistic review scope.
Replace claims with proof of this offer
| Sales claim to substantiate | Evidence before repeating the promise |
|---|---|
| Required result | Automated scan output is evidence to investigate, not proof of complete compliance or accessibility. |
| Input suitability | Use fictional form data and avoid unapproved real submissions. |
| Failure to address honestly | Automated report says pass but keyboard fails |
Remove placeholders and replace assumed prices with an approved scope and actual cost estimate. Do not advertise technical certification, current stock, guaranteed income or results you cannot substantiate. Record enquiries, accepted quotes, declined quotes, delivered orders and collected balances separately; a sent message is not a sale.