A bank, a telecoms operator or a government service can pass an accessibility audit on its app and still fail the person using it. The audit covered the product. It did not cover the contract they were sent afterwards, the handbook they were given when they joined, or the form they had to complete to ask for an adjustment.
That is the line most accessibility programmes stop at, and it is worth asking why.
Where the scope usually ends
Accessibility work tends to be commissioned by whoever owns the digital product. That is a reasonable place to start — it is where the standards are clearest, where the testing tools point, and where a failure is most visible. It is also where the budget sits.
The result is that the customer-facing surface gets assessed and the rest of the organisation does not. Recruitment materials, employee handbooks, leave policies and internal forms are produced by different teams, held in different systems, and answer to nobody who was in the room when the audit was scoped. They are usually documents rather than interfaces, which puts them outside what a web audit is set up to look at.
So an organisation can be genuinely good at digital accessibility for its customers and still be closed to a disabled employee from the first week.
What an integrated scope looks like
Our engagement with Zain Kuwait, announced on Global Accessibility Awareness Day in May 2026, was scoped across that line deliberately. It covers three areas in one programme of work:
- Digital services — the website and the native iOS and Android applications.
- Communications — social media channels and customer-facing digital content.
- Employee policies — recruitment materials, contracts, employee handbooks and leave policies.
The third of those is the one that makes the scope unusual. It is also the one that changes what the first two are worth.
Why the employee side is harder
Documents are not easier than interfaces; they are harder, and they are harder in ways that do not show up on a dashboard. A PDF contract with no tags has no headings, no reading order and no table structure, so a screen reader gets a wall of text in whatever sequence the layout happened to place it. A scanned handbook is an image of words, which is to say it is not words at all. A form built in a document editor and circulated as a file cannot be completed by someone who does not use a mouse.
None of that is caught by testing a website. It needs a different standard — PDF/UA alongside WCAG — and a different kind of review, closer to publishing than to engineering.
It also needs a different conversation inside the organisation, because the people who own those documents are rarely the people who own the app.
The two languages are one problem, not two
In the Gulf this compounds. A service that works in English and fails in Arabic has not been made accessible; it has been made accessible to half its users. Right-to-left interaction is not a mirrored layout — it changes reading order, focus order, the direction of progress and the way assistive technology announces a control.
The Zain engagement is assessed in Arabic and English throughout, including evaluation with assistive technology in both. An employee handbook in Arabic has the same structural requirements as one in English and a different set of failure modes, and only testing it in the language it will be read in finds them.
What to take from this
If you are scoping accessibility work, the useful question is not which products to include. It is which moments of a person’s relationship with your organisation you are willing to leave out.
A customer moves between an app, a message and a statement. An applicant moves between a careers page, a form and a contract. An employee moves between an intranet, a policy and a request. Accessibility is experienced along those paths, not inside any one of the systems that make them up — so a scope drawn around a single system is drawn around the wrong thing.
The Zain engagement is in progress and we are not claiming results from it. What we can say now is that the scope was drawn in the right place, and that drawing it there is a decision the organisation had to make before any testing began.
If you are weighing the same decision, our accessibility audit, document accessibility and policy review services are the three that meet at this line, and Arabic A11y is what makes them work in both languages.
Put any of this to work on your own service
This writing comes out of audits, design reviews and accessibility programmes we have run. Tell us what you are building, and we will tell you where it stands and what it would take.
Discuss your programme