انتقل إلى المحتوى

Planning accessibility in the Middle East and North Africa

نقطة بداية عملية للمؤسسات التي تقدّم خدمات عبر لغات وفرق وأسواق متعددة.

Filed under: رؤى, أخبار

A boy wearing headphones uses a tablet at a table, with another child working beside him.
Assistive technology, in everyday use rather than in a lab.

Most accessibility plans start with a list of pages. That is the wrong unit. Nobody uses a page — they apply for something, pay for something, or try to find out why a payment failed, and the barrier is rarely in one place.

Across the Middle East and North Africa that gap widens, because the same journey usually runs in two languages and across systems owned by different teams. Here is how to scope the first assessment so it produces a decision rather than a backlog.

Start with the journeys, not the pages

Pick a small number of journeys that matter, and follow each one all the way through. A journey is finished when the person has what they came for, which is usually later than the website thinks.

For each one, include everything the person has to get through:

  • The pages and screens, on every platform the service runs on.
  • The documents they are sent, and the ones they have to send back.
  • The messages — email, SMS, in-app — that tell them what happened.
  • The support channel they reach for when it goes wrong.

Scope drawn this way covers customers, employees and applicants rather than the public website alone, and it finds the gaps between teams that an inventory of pages cannot.

Treat the two languages as one service

A service that works in English and fails in Arabic has not been made accessible. Assess both versions, and assess them the way people use them: language switching, right-to-left interaction, labels, and the reading order of documents, with the assistive technology your users actually have.

Test with representative content. A form filled with placeholder text behaves differently from one holding a real name, a real address, or a mix of Arabic and Latin script in the same field — which is where a surprising number of failures live.

Terminology matters too. Public communications in the UAE and Egypt use “people of determination”; international standards and legal texts use “persons with disabilities”. Use the term your audience uses, and keep the official wording where you are quoting a standard.

Name who owns what

Most accessibility programmes stall on ownership rather than on technique. Settle it in writing before the assessment starts:

  • What suppliers must meet, and what evidence they must produce.
  • Who owns design, content, development and verification.
  • How findings get prioritised, and who decides.
  • When progress is reviewed as services, policies and teams change.

Set the standards at the same time. Choose the applicable WCAG and PDF/UA targets alongside regional requirements — for UAE services that means the National Digital Accessibility Policy and the UAE Design System, and international procurement may also want Section 508 or EN 301 549 evidence. See how these standards and frameworks fit together.

A worked example: applying for a service

Take a public application offered in Arabic and English. The website explains who is eligible, a form collects the details, a PDF lists the supporting documents, and an email confirms what happens next. Four systems, probably three teams, one person trying to get something done.

Start by writing down what success looks like, in plain words: the person understands the requirements, completes the form, and knows what happens next. Then work backwards to everything that has to function for that to be true.

Now agree coverage in each language. How does someone find the form? How are instructions and errors communicated? Can the supporting document be read by a screen reader? Is the confirmation understood by someone who receives it on a phone?

Make the first phase end in a decision

A first assessment has done its job when the organisation can choose what to do next. Before it starts, agree who receives the findings, how priorities get set, and which team can actually make the changes. Where a supplier owns part of the service, put that dependency in the plan rather than discovering it later.

Afterwards, re-check the journey and record what has been verified — not what has been reported as fixed. Patterns that recur are the useful output: they tell you what to put into training, design guidance and procurement, so the second assessment finds less than the first.

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