KENYA · GUIDE 0591 · EDITION 4.2
Website accessibility audit in Kenya: Operations and Quality Checks
Deliver the agreed result consistently
Audit agreed website pages and customer tasks, specifying review methods, assistive-technology checks, and the distinction between observed barriers and a formal compliance opinion.
The operating sequence for this offer is:
- Agree the accessibility reference, representative pages and key tasks, then document what manual checks and user testing are included or excluded.
- Test keyboard and relevant page interactions alongside automated tools, capture reproducible evidence and separate observed failures from recommendations needing further investigation.
- Deliver page-specific issues and retest steps with scope limitations, avoiding blanket legal-compliance or certification claims from a limited review.
Put acceptance into the job record
Findings have page references and evidence; an audit is not a blanket compliance certificate.
Ask users or reviewers to complete keyboard navigation, form submission, and content-reading tasks, documenting reproducible barriers with the relevant page and context.
Inspect at the point where a correction is still possible, then again at handover. Record rejected or incomplete output separately from accepted output. A completed task is not automatically an accepted task, and an invoice does not establish that the customer received the right result.
Measure real capacity
Time preparation, the main operation, transport, cleaning, approvals and correction as applicable. The slowest stage determines how much you can promise. Where two orders need the same person, space or equipment at the same time, resolve the conflict before confirming both deadlines. An additional enquiry should not erase a commitment already made.
| Operating checkpoint | Evidence for this business |
|---|---|
| Before starting | Audit agreed website pages and customer tasks, specifying review methods, assistive-technology checks, and the distinction between observed barriers and a formal compliance opinion. |
| During delivery | Test keyboard and relevant page interactions alongside automated tools, capture reproducible evidence and separate observed failures from recommendations needing further investigation. |
| At acceptance | Ask users or reviewers to complete keyboard navigation, form submission, and content-reading tasks, documenting reproducible barriers with the relevant page and context. |
| At the pilot review | Record tested pages, browser and tool context, task failures, supporting observations, suggested remedies, and limitations preventing the findings from implying universal website accessibility. |
Keep a correction and escalation rule
When inputs, access, specifications or customer instructions change, pause the affected work and confirm the effect on time and cost. Do not quietly lower the acceptance standard to avoid a delayed delivery. Keep rework caused by your error distinct from a customer-requested change of scope and agree the remedy clearly.
An audit is weak when it reports generic warnings without showing which customer task is blocked or how a developer can reproduce it.
Retain the minimum records needed to investigate a complaint without disclosing unrelated personal information. Use measured delivery and actual acceptance as the basis for expanding capacity, rather than the maximum theoretical output of a tool or production line.
Operating control points for this exact offer
| Sequence | Work method | Release checkpoint |
|---|---|---|
| 1 | Record five URLs, page states, browser/version, viewport and the enquiry task. | A default home page alone does not cover error messages, menus or form confirmation. |
| 2 | Navigate menu, links and form without mouse; observe order, focus visibility and traps. | Document exact keys/steps and affected control rather than reporting a vague inaccessible label. |
| 3 | Check page titles/headings, form labels/instructions and image purpose/text alternatives. | Decorative and informative images receive different treatment; filenames are not meaningful descriptions. |
| 4 | Review zoom/reflow and text contrast using appropriate tools and manual inspection. | Colour is not the sole way to communicate an error; record tested settings and limitations. |
| 5 | Separate reproducible barriers from untested areas and give developer-ready steps plus retest criteria. | Automated scan output is evidence to investigate, not proof of complete compliance or accessibility. |
Do not substitute a tick for an observation: record the count, measurement, approved sample or evidence reference used at each checkpoint. Mark unresolved work as held and identify who can approve the recheck.
Diagnose a failure before repeating it
| Observed symptom to investigate | Check the cause | Proposed response |
|---|---|---|
| Automated report says pass but keyboard fails | Reproduce the task manually and inspect focus/control behaviour. | Report the user barrier despite the automated score. |
| Form error only red border | Check labels/error text and non-colour cues. | Recommend explicit associated error instructions and retest. |
| Issue cannot be reproduced | Compare page state/browser/settings. | Clarify evidence or mark unresolved rather than claiming a confirmed defect. |
These are diagnostic prompts, not proof of the cause in a real incident. Separate suspect output, record any correction and repeat the relevant acceptance check. Link rejected units, rework time, replacement materials, customer credits and collection delays to the actual job result.