Arabic interfaces can look correct and still be difficult to use. A mirrored layout does not fix mixed Arabic and English text, keyboard order, form errors, zoom, captions, or screen-reader labels.
That matters to teams serving the UAE and Qatar because both markets now point public digital services towards modern accessibility standards. The UAE's National Digital Accessibility Policy, issued on 18 March 2024, covers government, semi-government and private providers of public services. Qatar's Mada Digital Accessibility Portal recommends WCAG 2.2 at levels A and AA for websites and web applications.
This guide turns those standards into engineering work for Arabic products. It is practical information, not legal advice.
Start with two separate problems
Arabic support and accessibility overlap, but they are not the same job.
Internationalisation handles language, script and direction. Accessibility handles whether people can perceive, understand and operate the product with different devices and abilities. A page can have perfect right-to-left alignment and still fail keyboard navigation. It can also pass an automated accessibility scan while rendering an account number in the wrong visual order.
Use WCAG 2.2 as the testable accessibility baseline. W3C published the current Recommendation on 12 December 2024 and advises teams updating accessibility policies to use the latest version. Then add Arabic-specific checks from W3C's Arabic and Persian Layout Requirements, which remains a draft note rather than a formal Recommendation.
The policy context differs by country. The UAE policy has a broad public-service scope and asks providers to improve websites, mobile applications, software and digital interfaces. The TDRA summary also describes obligations for federal entities, awareness and staff training. Qatar's Mada standards repository is more implementation-oriented: it maps WCAG 2.2 A and AA to websites, mobile applications, electronic documents and media. A product operating in both markets should keep one WCAG-based engineering baseline, then maintain a country matrix for contractual, sector and procurement requirements.
Put direction in the document, not the theme
Set language and direction on the root element. Do not depend on a CSS class attached after the page has loaded.
<html lang="ar" dir="rtl">
W3C's guidance on structural right-to-left markup recommends dir="rtl" on the html element for an RTL document. It also says not to use CSS to establish the base direction. Direction is semantic information that user agents and assistive technology need before presentation rules are applied.
Use dir="auto" for user-generated fields when you do not know which script will appear first:
<label for="merchant-note">ملاحظة التاجر</label>
<textarea id="merchant-note" dir="auto" name="merchantNote"></textarea>
Do not flip the whole DOM order to make the screen look mirrored. Keep the reading and focus order meaningful, then use layout rules to place components. A keyboard user should move through the page in the same logical sequence as a screen-reader user, even if cards appear from right to left.
Replace physical CSS with logical properties
Hard-coded left and right values create a second maintenance problem when the interface switches language. CSS logical properties describe spacing and position relative to the writing direction.
.notice {
padding-inline: 1rem;
border-inline-start: 4px solid var(--accent);
margin-block: 1rem;
}
.action-icon {
inset-inline-end: 0.75rem;
}
MDN's logical properties guide explains how inline-start and inline-end map to the active writing direction. This is safer than maintaining separate RTL overrides for every component.
Some assets should mirror, while others should not. Back arrows and progress direction usually follow the interface direction. Company logos, media controls, charts, clocks and many real-world symbols usually keep their original orientation. Put that choice in the component contract rather than applying transform: scaleX(-1) to an entire container.
Isolate account numbers, prices and identifiers
Arabic products routinely mix RTL words with LTR fragments: IBANs, card suffixes, phone numbers, email addresses, URLs, dates and English product names. Neutral characters such as slashes, parentheses and hyphens can move to surprising positions under the Unicode Bidirectional Algorithm.
Use <bdi> around dynamic fragments whose direction is unknown or independent of the surrounding sentence:
<p>
المستفيد: <bdi>{{ beneficiaryName }}</bdi>
• الحساب: <bdi dir="ltr">AE07 0331 2345 6789 0123 456</bdi>
</p>
The bdi element isolates its contents so they do not change the direction of nearby text, and nearby text does not change their direction. W3C's inline bidirectional markup guide recommends tightly wrapping opposite-direction phrases and nesting markup to match the text structure.
Never validate financial identifiers by visual appearance. Normalise permitted whitespace, validate the machine value, and render a separate display value. Copy actions should copy the canonical value. Test the result in Arabic and English with realistic punctuation around it.
A translated label is only the start. Each input needs a programmatic name, a visible focus state and error text connected with aria-describedby. Do not use placeholder text as the label.
<label for="amount">المبلغ</label>
<input
id="amount"
name="amount"
inputmode="decimal"
aria-describedby="amount-hint amount-error"
aria-invalid="true"
/>
<p id="amount-hint">أدخل المبلغ بالدرهم الإماراتي</p>
<p id="amount-error" role="alert">المبلغ يتجاوز الحد اليومي</p>
Keep the field's machine format separate from its presentation. Arabic users may enter Arabic-Indic digits, Western digits, or a mixture. Decide which forms you accept, document the conversion, and test decimal separators against the backend parser. Do not silently turn a value into a different amount.
When submission fails, move focus to a short error summary and provide links to the affected fields. Announce new errors without trapping focus. The same flow must work at 200% zoom and at narrow widths without hiding the submit button behind a sticky footer.
Test the transaction path, not a component gallery
Automated tools catch missing labels, invalid ARIA and some contrast problems. They will not tell you whether a bilingual transfer confirmation reads in the intended order or whether an Arabic validation message makes sense.
Build a small release gate around real journeys:
- Run static checks in pull requests with axe-core, Lighthouse or an equivalent tool.
- Use only the keyboard to complete the critical flow in Arabic and English.
- Test one screen reader on each supported platform, such as VoiceOver with Safari and NVDA with Chrome.
- Check 200% zoom, a 320 CSS-pixel viewport and high-contrast or forced-colour settings.
- Test mixed-direction fixtures: Arabic names, English names, IBANs, signed amounts, phone numbers, URLs and punctuation.
- Include disabled users in usability testing for high-risk flows. Automation cannot replace that evidence.
Treat defects by customer impact. A decorative icon without hidden text is not equal to an inaccessible one-time-password field. Block release when a user cannot identify a control, reach it by keyboard, understand an error, or verify a transaction.
Visual: SultanByte. Sources: W3C WCAG 2.2 (12 December 2024), W3C Internationalisation guidance (updated 25 June 2021), UAE National Digital Accessibility Policy (18 March 2024), and Mada recommended standards (accessed August 2026).
A release checklist that teams can own
Give each layer a named owner. Product owns the critical journeys and acceptable failure states. Design owns focus, contrast, reflow and mirrored behaviour. Engineering owns semantic HTML, direction, input parsing and automated checks. QA owns assistive-technology coverage and mixed-direction fixtures. Legal or compliance teams map this baseline to the product's exact obligations.
For a UAE or Qatar launch, keep evidence with the release: test results, known exceptions, remediation owners and the date of the next review. Do not claim WCAG conformance from a single scanner score. Conformance applies to complete pages and processes, not isolated components.
The useful target is a transaction that still works when the user changes language, enlarges text, removes the mouse or relies on speech and screen-reader output. If that path is sound, the interface is doing more than looking Arabic. It is usable in Arabic.
Cover: original SultanByte visual.
