Accessibility starts with real constraints: Arabic screen readers, low vision, one free hand. Practical WCAG 2.2 steps for digital teams in Saudi Arabia.
A woman renews a document on her phone while holding her child with the other arm. A retired officer zooms the screen to 200 percent because the text is too small. A blind employee moves through a government portal with a screen reader, listening to Arabic headings one at a time. None of them matches the usual picture of "the user", and all of them are using your service today.
Accessibility in design means building digital products that people can perceive, understand, operate and rely on, whatever their abilities or circumstances. It is often handled as a checklist at the end of a project. It does its real work when it enters the design at the first sketch, because the constraints it brings usually produce a clearer product for everyone, not only for one group.
Who Accessibility Is Really For
In Saudi Arabia's 2022 census, 1.8 percent of the population reported a disability, according to the General Authority for Statistics. That is a sizeable group on its own, but it is not everyone who benefits from accessible design.
Limitations are not always permanent. Microsoft's Inclusive Design toolkit separates three kinds: permanent, such as loss of sight; temporary, such as a broken wrist after an accident; and situational, such as harsh sunlight on a screen, a loud majlis or a weak signal on a desert road. A solution designed for the first case usually helps the other two.
Age matters too. Eyesight weakens and fine motor control declines over time, so many people need larger text, wider buttons and more time to finish a form without ever thinking of themselves as disabled. A service that ignores those needs loses them quietly. Most of them do not complain; they ask a son or daughter for help, or they go to the branch.
A solution designed for a permanent limitation usually serves people living with a temporary or situational one too.
A good experience works with a screen reader, with low vision and with one free hand.
What Changes in an Arabic Interface
Most accessibility guidance was written in English for interfaces read from left to right. An Arabic interface raises issues those guides rarely cover:
Language and direction in the code. If the page is not declared as Arabic and right to left, a screen reader may read it with an English voice or in the wrong order.
Mixed text. Numbers and English brand names inside an Arabic sentence can flip punctuation on screen, so a full stop or bracket appears in the wrong place.
Type size and line height. Arabic usually needs a slightly larger size than Latin to look equal, and more line height so dots and diacritics do not collide.
Letter spacing. Adding space between letters breaks the joins in Arabic words and makes them harder to read, so it stays at its default.
Alt text and error messages. Write them in clear Arabic from the start rather than machine-translating an English version, because a screen reader will speak them exactly as written.
Automated tools will not catch most of this. In 2017 the UK Government Digital Service built a page with 142 deliberate accessibility barriers and ran it through 13 automated checkers. The best tool found 40 percent of them and the weakest 13 percent, according to the published audit.
Run your core journey in Arabic with VoiceOver on iOS and TalkBack on Android, and listen to what a user actually hears.
Practices That Hold Up in Delivery
The common global reference is the Web Content Accessibility Guidelines. Version 2.2 became a W3C Recommendation in October 2023 (WCAG 2.2), and most organizations target the AA level. These are among the criteria with the most effect on digital services:
Contrast of at least 4.5 to 1 between body text and its background, so people with low vision can read it in bright light.
Touch targets of at least 24 by 24 CSS pixels, new in version 2.2, which prevents mis-taps on a phone.
A sticky header that never hides the element a keyboard user has just moved to.
Sign-in that does not rely on memory or puzzles, and allows paste, password managers and one-time-code autofill.
No asking for the same information twice in one journey.
Colour never carrying meaning alone: a field with an error is marked with text and an icon, not only red.
The guidelines are a floor, not a guarantee. What changes outcomes is testing with people who have disabilities, which is part of how we run our UX Lab. Pick one high-traffic journey, such as renewing a document or booking an appointment. Fix what trips participants up, then move the lessons into your design system so every new service inherits them.
