Accessibility

03

Software that works for everyone

The principle is simple and the practice is exacting: the product should work for a person who cannot see it, cannot hear it, cannot use a mouse, cannot use a touchscreen, or cannot read at a glance. That is not an edge case; it is a market, and it is the law in more jurisdictions every year.

• Full keyboard navigation — every flow, every screen, every control reachable and operable without a mouse, for the people who never touch one.
• Screen-reader testing with the real tools — NVDA, JAWS, VoiceOver and TalkBack used as the users run them, not a spec sheet saying 'should be compatible'.
• Contrast and text-size compliance without ugly compromises — accessible colour is a design constraint handled at the start, not a beige desaturation applied at the end.
• Focus states you can see — the keyboard cursor is a visible, moving presence on the screen, never the faint default outline nobody designed.
• Labels and landmarks done properly — every control announces itself to assistive technology with the words a human would expect, not a codename an engineer invented.
• Nothing depends on a single sense — colour is never the only carrier of meaning; icons are never the only way to tell 'success' from 'error'.

Accessibility is not a mode the user switches on; it is the default behaviour of code that respects its users. We build that respect in, so it does not have to be requested.

04

What WCAG actually is — and what it isn't

WCAG is a set of standards, not a certificate and not a design trend. We treat it as the engineering baseline it was written to be: concrete, testable criteria that a competent team can build against — and an audit that a lazy one can game. The difference is in whether the product works for real users after the checklist is ticked.

• WCAG is testable, so we test it — the criteria (contrast ratios, focus visibility, keyboard operability, labels) are mechanical enough to check continuously, in CI, not just before an audit.
• Levels are floors, not ceilings — compliance levels are weighted by importance to real users, and the work is held to what the product genuinely needs, not the cheapest pass.
• An audit is a snapshot — a passed audit on one date proves nothing about the accessibility of next month's feature; the pipeline has to carry the standard.
• Automated checks catch a fraction — they catch missing labels and bad contrast reliably, and they miss live-region politeness and screen-reader flow entirely; both halves are needed.
• Conformance is a claim about users — the real test is 'can a person with a screen reader complete the payment?' and that is answered by people, in addition to tools.
• The standard is a moving target — WCAG evolves, and the product's accessibility posture evolves with it, reviewed on the same cadence as security.

WCAG is a floor with a load-bearing floor above it. We build to the standard, verify it with tools, and then answer the only question that matters: does it work for the person it is supposed to work for?

05

Keyboard-only: the whole product, no mouse

A significant share of assistive-technology users navigate entirely by keyboard — and so do a great many ordinary power users on laptops. The product must be completely usable with Tab, Shift-Tab, Enter and the arrow keys: every control reachable, every action triggered, nothing trapped in a focus dead-end.

• A logical tab order, always — focus moves the way the eye would: header to content to form to action, never a jump forced by a DOM accident.
• Visible focus at all times — the current position is unmistakably indicated with a designed outline, not the browser's faint default.
• No keyboard traps — a user can Tab into any control and Tab out again; modals close on Escape and return focus where they found it.
• Every function has a keyboard path — dropdowns, date pickers, sliders and drag-and-drop all have operable keyboard equivalents; no feature is mouse-only.
• Skip links for long pages — a keyboard user jumps straight to main content instead of tabbing through forty navigation items.
• Tested with the keyboard alone — every release is walked end-to-end with no mouse and no touch, because that is how a real user will walk it.

The keyboard-only walkthrough is one of the cheapest, most revealing accessibility tests we run. If a user can complete the whole journey with a keyboard, half of accessibility is already earned.

06

Screen readers: testing with the real tools

A screen reader turns the screen into speech or braille, and it can be ruthless about structure: a button with no accessible name says nothing, an unlabeled field says 'edit blank', and a page with no landmarks reads as a wall of text. The only way to know is to listen to the product the way the user does.

• Read by the tools users run — NVDA and JAWS on Windows, VoiceOver on macOS and iOS, TalkBack on Android — each with its own quirks the product must survive.
• The accessible name is the product voice — a 'Pay now' button that announces itself as 'submit button' to a screen reader is a button that lied; names are written by humans for humans.
• Landmarks give the page structure — navigation, main, complementary and banner regions let a screen-reader user skip to the part they came for.
• Live regions speak when they must — a payment result, an error or a balance update announces itself instead of silently changing under the cursor.
• Forms announce their shape — labels, hints and errors are read in the order that makes sense, and a field in a failed validation says exactly what went wrong.
• Audio is not the only test — the same structure is checked for braille output where a blind user reads with their hands instead of their ears.

We test against the real tools because the real tools are what real users run. A screen-reader pass is not a certification; it is a listening session with the person the product is for.

07

Contrast, text-size and low-vision design

Most of the world's experience of accessibility is had by people who are not blind — they are low-vision, older, or reading a phone in bright sunlight. Legibility is where accessible design earns its keep every single day, for far more users than any other factor.

• Contrast ratios as design tokens — text and UI elements meet WCAG contrast ratios as a matter of the colour system, not as per-element fixes.
• Text reflows and resizes — a user who enlarges text to 200 percent gets a functioning layout, not overlapping rectangles they cannot read.
• Never a fixed-only size — the interface is designed to grow with the user's font-size choice instead of fighting it.
• Colour is never the only signal — error borders have an icon and text; 'active' states differ by more than hue; a colour-blind user sees the same truth anyone else does.
• High-contrast mode survives — the product renders legibly under forced contrast settings instead of collapsing into indistinguishable shapes.
• Light and dark are both accessible — both themes meet the same contrast and legibility bar, not just 'dark is trendy'.

Low-vision users are the largest accessibility community there is, and legibility is its quiet workhorse. We treat contrast and text-size as core visual design, not an accessibility afterthought.

08

Touch targets and motor accessibility

Not everyone taps precisely. Older hands, tremor, low vision, gloves, a moving matatu — the touch target is where the product either forgives or fails. Generously sized, forgivingly placed controls are accessibility and good mobile design at exactly the same moment.

• Targets large enough to hit — the interactive area comfortably exceeds the recommended minimum, so a miss is rare and a wrong-option tap is rarer.
• Spacing separates — adjacent actions have enough air between targets that an accidental tap cannot trigger the neighbour's action; 'pay' and 'cancel' are never adjacent hazards.
• The undo and the confirm are reachable — a high-stakes action (sending money, paying a bill) has a confirm and, where possible, a path back, forgiving the motor-miss that confirms too fast.
• Timed actions are forgiving — a session or payment that times out gives a clear, easy way to extend or restart; time pressure is never a trap.
• Voice and assistive input coexist — actions operable by touch are also operable by the assistive technologies that replace touch.
• Motion is optional — parallax, shake and swipe gestures have plain alternatives; the critical path never requires a flourish.

Generous touch targets are the cheapest accessibility there is and the most felt. We size the targets for the hand that shakes, the thumb that misses and the palm about to be hit by a kerb.

09

Semantics, landmarks and labels done properly

Assistive technology cannot see pixels; it reads structure. The semantic skeleton of the product — what is a button, what is a heading, what is a region, what a control is called — is the interface that users of AT actually interact with. Getting it right is an engineering discipline with a vocabulary.

• Real elements before ARIA roles — a native button is a button before any markup declares it; ARIA supplements structure, it never substitutes for it.
• Headings are a table of contents — the heading hierarchy reads like an outline, so a screen-reader user can browse the page the way a sighted user scans.
• Forms have labels a human wrote — every field announces a real instruction with real words, and the announcement is tied to the field it describes.
• Error messages are linked to their fields — a failed validation tells the user — and their technology — exactly which field and what to fix, in the same breath.
• Landmarks make skimming possible — navigation, main, complementary, search and banners give a non-visual user the same 'land on the main content' leap a sighted user gets from a glance.
• Dialog and modal semantics — a popup announces itself, confines focus while open, and returns focus on close; it is never just a div that happens to float.

The semantic layer is the accessibility product. We write it the way we write a good sentence: so the receiving intelligence hears exactly what was meant.

10

Focus states that can be seen

The focus indicator is where the visual designer and the accessible engineer most often collide — and where we do not let them. A visible, designed focus state is not an ugly outline to design around; it is a feature of the interface, like a hover state, and it makes the keyboard experience feel deliberate.

• Focus is designed, not defaulted — the visible position indicator matches the product's visual language instead of relying on the browser's faint blue.
• The focus jump is logical — focus moves in a sequence a user would predict, and never vanishes into a hidden or off-screen element.
• Interactions change focus predictably — opening a menu moves focus to it; closing it returns focus where it began; the user always knows where the cursor is.
• Focus and hover agree — what hover shows visually, focus shows too, so a keyboard user receives the same guidance a mouse user gets.
• Focus states pass contrast — the indicator itself is visible enough to be found on any background, including the ones that look busy.
• Documented in the design system — the focus treatment is a component with a spec, applied everywhere instead of improvised per screen.

A hidden focus state is how keyboard users get lost; a designed one is how they navigate confidently. We make the cursor visible, predictable and on-brand — the way a hover state already is.

11

The legal and procurement case

Accessibility is a legal posture as much as a moral and commercial one. In a growing number of markets, excluding users with disabilities is not just a missed audience — it is a legal exposure, and accessibility is increasingly a condition of winning public and institutional contracts.

• Exclusion is an expensive posture — accessibility lawsuits and regulatory actions are a real, growing cost of doing business that ships inaccessible products.
• Procurement increasingly demands it — public tenders and institutional buyers routinely require demonstrated accessibility; the product that cannot show it does not get invited to the table.
• Tender submissions get a technical annex — we ship the accessibility work as evidence: standards aligned, checks run, tools used, user tests performed.
• The cost of retrofitting is the scare — fixing accessibility after launch costs many times the price of building it in; the legal risk is the same bill with the word 'lawsuit' attached.
• Reasonable accommodation is the floor, not the whole — the standard is not 'the minimum we can argue', it is 'the product works for the users it claims to serve'.
• The moral and the legal agree — we take the legal case seriously because we take the human case seriously; they happen to point the same direction.

We are not lawyers and we do not pretend to be — but the product that cannot demonstrate accessibility is a legal exposure wearing a design system. We build the evidence as we build the product.

12

The market case: widening the audience in Kenya

Accessibility widens the product for more of the world, and in Kenya the audience is specific and real: an ageing population whose parents and grandparents are increasingly online, a large community of users with low vision who read on small screens, and vast numbers of users on entry-level devices where 'design for the ideal' quietly excludes the majority.

• Elderly users are a real share — Kenya's older population is digitalising, and a product that respects large text, clear contrast and forgiving targets wins them and keeps them.
• Small screens are the majority screen — entry-level Android is the Kenyan reality; an interface that assumes a large, sharp display is an interface that fails the market basket.
• Low-data users need legible efficiency — an accessible interface that avoids redundant steps and heavy media respects both the user and the bundle they paid for.
• Local language and plain wording — clear, concrete labels serve non-native English speakers as much as they serve screen-reader users; the same discipline helps both.
• Forgiving design is trust — a user who already feels out of their depth with technology forgives a product that forgives their mistakes; that trust is a retention asset.
• Competitors ignore it — the accessible product reaches segments the mainstream competitor never designs for, and that is market share by default.

Inclusive patterns reach users competitors ignore, and in Kenya those users are not a footnote — they are a substantial, underserved share of the market. We treat accessibility as reach, because it is.

13

Accessible money UI

Money interfaces multiply the accessibility stakes. A button that cannot be reached, a balance that cannot be read, a confirmation that cannot be heard — each is not an inconvenience but a person blocked from their own money. Building accessible money UI is one of the most exacting things we do, because we live it on our own payments platform.

• The critical path is the accessible path — top-up, pay, send, confirm and check-balance are walkable by keyboard, screen reader and touch, with every step announced, labelled and reachable.
• Balances are announced, not just displayed — a screen-reader user hears their balance in the currency and format a human would say it, with no trailing metadata noise.
• Confirming and cancelling are never adjacent hazards — the money-moving button and the stop button are spatially and semantically distinct, forgiving the motor-miss with a safety margin.
• Payment results are live-region announcements — the moment an STK push succeeds or fails, the screen reader announces it; a low-vision user is not left guessing from a silent screen.
• Insufficient-balance errors say the exact amount — the message, readable and announceable, tells the user what they need, not a generic 'try again'.
• M-Pesa PIN is never the app's — the customer pays with their own phone and their own PIN on Safaricom's Daraja rails; the app's accessibility is about the journey to and from that moment, which we make navigable for every input mode.

Money is the one context where a blocked user is not merely frustrated but — briefly, and daily — financially excluded. We build the money journey so every user completes it, because being able to pay is not a convenience; it is participation.

14

Tested alongside the features

Accessibility that is tested only at audits rots between audits. Every release ships with features, so every release ships with accessibility checks alongside the features — in CI, in review and in the manual walkthrough, so it stays part of the product rather than a periodic cleanup scheduled for never.

• Automated checks in CI — the axe rules and linting gates run on every build, so a release that introduces an unlabeled control is rejected mechanically.
• Keyboard walkthroughs as a release step — a human walks the key journeys with mouse and touch disconnected; what survives is, by construction, operable.
• Screen-reader passes on real cadence — the critical journeys are listened through on each release cycle, and after any change to the affected screens.
• New components enter with their labels — a new button, dropdown or dialog arrives in the design system with its accessible name, focus behaviour and keyboard path already specified.
• Regressions are bugs with severities — a focus trap, a missing label or a broken skip link is a defect with an owner, not a 'defer to an accessibility sprint' ticket.
• The test scripts are written down — the exact steps, tools and expected announcements live in documentation, so anyone on the team can run the pass, not only the specialist.

Testing alongside the features is what makes accessibility a living property instead of a memory. The pipeline carries the standard, and the standard does not quietly expire between audits.

15

Real-user testing with assistive technology

Automation finds the mechanical failures; real users find the rest — the flow that is technically compliant and still baffling, the announcement that is technically correct and still confusing, the journey that passes an audit and still fails a person. We test with the tools, and where we can, with the people who use them.

• The storyboard follows a real task — the test is 'complete a payment', 'find your rent balance', 'read this statement', not 'navigate to page fifteen and admire it'.
• The tools, not just the books — the pass runs on NVDA, VoiceOver or TalkBack exactly as the user runs them, with the verbosity and mode a real user carries.
• Compliant-but-baffling is caught — a screen reader can announce every control and still leave a user lost in the order; ordering and grouping are tested, not just presence.
• Feedback loops into the backlog — what real users trip on becomes defects with severity and owners, the same as any other user-reported bug.
• Cognitive accessibility is considered — clear wording, predictable flow and the absence of ambushes serve users with cognitive and learning differences as much as sensory ones.
• Documented so it repeats — the script is handed to the team so the pass is repeatable beyond the specialist who wrote it.

Accessibility done only for compliance is accessibility that passes quietly and fails loudly. We test with the people and the tools, so 'it works' is a claim we have already heard a human confirm.

16

Accessibility is a discipline, not a sprinkle

There is no accessibility toggle, no accessibility mode, no 'we will make it accessible later'. A product is accessible because the discipline was in the room from the first user flow — or it is not, and the retrofit is always more expensive and always worse. We say this plainly because it saves clients from their own optimism.

• It is in the definition phase — the user journeys, the components and the contrast tokens are decided accessible before a screen is drawn.
• It is in the design system — the reusable components carry their accessible behaviour as part of their spec, so new screens inherit accessibility instead of inventing it.
• It is in the code review — the accessible name, the focus path and the semantic element are as reviewable as the data model.
• It is in the test suite — the CI gates and the manual passes hold the line release after release.
• It is in the documentation — the standard, the tools, the scripts and the decisions are written down, so it survives people changing roles.
• It is in the honest conversation — when a corner genuinely cannot be made accessible in the current architecture, we say so, explain the cost, and plan the path rather than promising a sprinkle.

A sprinkle is what a vendor offers when the discipline was never in the room. We bring the discipline into the first meeting, and the product ships with accessibility already part of what it is.

17

Documentation and governance

Accessibility dies when it lives only in the head of the person who championed it. The standard, the tools, the scripts and the decisions are written into the project so any engineer can hold the line, any reviewer can check the work, and the standard survives whoever leaves.

• The target standard is written — the WCAG level and the product-specific interpretation are recorded, so 'what are we aiming for' has a document.
• The test scripts are recorded — exact steps, tools, expected announcements and keyboard paths are in the repo, repeatable by anyone.
• The design system encodes it — components, contrast tokens and focus styles are specified centrally, so new screens inherit compliant behaviour.
• The component library enforces it — a new dialog, dropdown or form control enters the library with its accessibility contract; bad patterns are rejected at the door.
• Decisions have owners — a deviation or an exception is a logged decision with a named owner and a review date, not a silent shrug.
• Training keeps it alive — the team learns the tools and the scripts, so the discipline is distributed instead of concentrated in one specialist.

Governance is what turns a standard into a habit. The team is no longer asked to 'remember accessibility'; it is asked to follow the documented standard — which is a far more reliable question.

18

Honest limits of accessibility work

Accessibility is powerful, and it has honest boundaries. We will say what those are, because a client deserves the truth about what can and cannot be promised.

• Automation cannot replace listening — the tools catch the mechanical; the human judgment about flow, ordering and wording is ours and it is always needed.
• The canonical audit is a snapshot — the product's accessibility is a running property maintained by discipline, not a certificate acquired once.
• Some legacy corners are genuinely hard — a system built before accessibility was considered may carry pockets that cost real effort; we plan and phase rather than sprinkle.
• Assistive technology itself varies — NVDA, JAWS, VoiceOver and TalkBack disagree on details, so 'works in all of them' is a test we run, not a label we assume.
• Perception and cognition are spectrums — no interface is accessible to every possible human; we are honest about the standard we hit and the users it serves.
• The business must want it — accessibility survives when it is resourced as a standing discipline; we build the machinery, but the company must keep the pipeline fed.

We will tell you honestly what your legacy surface will cost to make accessible and what the discipline requires from your team going forward. And we will build the accessible floor so solid that 'accessibility' stops being a project and becomes a property of the product.

The toolchain

The accessibility toolchain

The audit engines, assistive tools, contrast checks, semantic disciplines and CI gates we run to make products genuinely work for every user — the machinery we apply to our own payments product.

Lifecycle

The accessibility lifecycle — from audit to a living standard

Accessibility is built in from the first flow and carried by the pipeline forever after. This is the lifecycle every product we make accessible passes through — including the money-journeys of our own payments platform.

Closing

More than development

Accessibility is a larger market, a legal posture, a discipline and a moral fact in one. When we build accessibility into a product, that includes:

Every user a keyboard or screen reader carries through the product is a user your competitor did not design for. Accessibility is market share, legal protection and human decency at exactly the same time.

We build accessibility in from the first flow and carry it in the pipeline forever — never patching it on complaints. When accessibility matters, your product gets the discipline that is part of what it is, not a sprinkle on top.