A Gulf bank operating in three countries discovers, three days before a Qatari tender deadline, that its accessibility statement is English-only, its barrier-report email has no published SLA, and its retail banking app has never been tested against the Mada switch-access protocol. The pre-existing WCAG audit it relies on in Saudi Arabia is necessary but not sufficient. This article is the checklist we wish the bank had been given six months earlier — what Qatar's e-Accessibility regime actually requires, what Mada adds on top, and how to tell when each one applies.
The MOTC e-Accessibility Policy in brief
The Qatar Ministry of Communications and Information Technology (MOTC) administers the e-Accessibility Policy. The policy applies directly to every Qatari government digital service. It is also increasingly cited by the Qatar Central Bank for financial services and by the Communications Regulatory Authority for telecom customer channels. In practice, any operator competing for Qatari public-sector or regulated-private contracts will see MOTC's checklist in the tender document.
The policy assumes WCAG 2.2 Level AA as its technical baseline. On top of that baseline, it adds Qatar-specific provisions that are not in WCAG and that automated tooling alone cannot verify:
- Arabic-English parity at the depth Saudi DGA also requires — but with a few Qatari-specific conventions noted below.
- Procurement provisions — accessibility is a mandatory clause in government IT contracts. Vendors must demonstrate prior conformance evidence before contract award, not after.
- A published accessibility statement on every public service, in Arabic and English, linked from the homepage footer with a date of last review.
- A barrier-report contact route with a published response SLA. The SLA is the operator's commitment, not a regulator-imposed number, but it must be present and met.
- Periodic re-audit — at least every two years for services scoring above threshold; annually for services below.
- Vendor accessibility responsibility — when a government entity procures a service, the contracting entity is responsible for ensuring the vendor's product meets the policy. The vendor cannot disclaim it.
What Mada certification adds
Mada — the Qatar Assistive Technology Center — administers a separate certification program that goes beyond the MOTC policy. Mada certification is not the same thing as MOTC compliance; the two are layered. MOTC is the floor; Mada is the badge.
Mada certification adds the following on top of WCAG 2.2 AA:
- Arabic screen reader compatibility tested specifically against NVDA with Arabic voice and Apple VoiceOver Arabic. Both engines pronounce Arabic differently from each other; both must succeed.
- Switch access — single-switch and two-switch scanning patterns must reach every interactive element. This is the criterion that catches the most enterprise services off-guard, because nothing in WCAG explicitly tests switch traversal.
- Voice control — every interactive element must have a stable, speakable name in both Arabic and English. Icon-only buttons fail;
aria-label-only labels can fail if the label doesn't match what a user would naturally say. - Magnification and zoom — content must reflow correctly at 400% zoom without breaking layout or losing content. WCAG 1.4.10 only requires 320 CSS pixels; Mada raises it.
- Reading mode — content must survive Reader-mode strip (Safari Reader, Firefox Reader View) without losing meaning. This effectively tests semantic-HTML discipline.
When to seek Mada certification versus rely on WCAG AA + MOTC
This is the question that comes up first in every Qatari engagement, so it's worth being concrete about the answer.
You need Mada certification when:
- Your service will be promoted on Mada's Accessibility Catalog, which catalogues services accessible to disabled users in Qatar.
- A Qatari procurement document specifies Mada certification by name in the eligibility criteria.
- You are providing a service explicitly aimed at disabled users (educational platforms for learners with disabilities, assistive-technology-adjacent products, disability-focused government services).
- Your competitive positioning in Qatar depends on the inclusion credential.
WCAG 2.2 AA + MOTC compliance is sufficient when:
- You are a regulated private-sector operator (banking, telecom, healthcare) without a tender that specifies Mada by name.
- Your service is general-purpose and serves the whole population.
- Your existing accessibility program produces evidence that maps onto the MOTC evidence pack format.
The pragmatic sequence for most enterprise operators: get to WCAG 2.2 AA + MOTC compliance first; layer Mada on the specific surfaces where the marketing or procurement case justifies the additional work.
The MOTC evidence pack
For any Qatari government tender citing the e-Accessibility Policy — and many do, by reference — the evidence pack expected at submission is:
- A signed PDF audit report from an independent third-party auditor, dated within the last 12 months. Findings grouped by severity, mapped to WCAG success criteria, and to the MOTC policy clauses where they apply. Mueen reports satisfy this requirement.
- A bilingual accessibility statement published on the production service, linked from the homepage footer, with a date of last review and the auditor's name.
- The barrier-report contact route — an email address or form — with the published SLA for response (typically 2 working days). The route must be operational, not aspirational.
- If seeking Mada certification: a separate Mada conformance summary covering the switch-access, voice-control, magnification, and reading-mode tracks.
- The auditor's statement of independence — confirmation that the auditing firm is not also the firm that built or operates the service.
- The remediation plan for any findings rated Serious or Critical, with named owners and target dates.
The single most common reason MOTC submissions get bounced for shape, in our experience: the accessibility statement exists on the website but is English-only, or links to a 404, or has no date of last review. The fix is small; the cost of missing it at submission is large.
Bilingual gotchas specific to Qatar
Qatari Arabic shares the vast majority of its conventions with Modern Standard Arabic as used across the Gulf, but a handful of patterns recur in Qatari procurement reviews that we don't see flagged as often in Saudi audits.
Qatari numeral conventions in financial flows
Qatar's banking and government services frequently mix Western Arabic numerals (0123456789) and Eastern Arabic numerals (٠١٢٣٤٥٦٧٨٩) depending on the field. The accessibility expectation is that the numerals match the user's stated locale preference, not the document author's preference. A Qatari riyal amount displayed in mixed numerals — Western digits inside Arabic copy without isolation — fails both the WCAG 1.3.1 structure test and the MOTC bilingual provision.
The fix is to wrap embedded Western-numeral content in a <bdi> element or in <span dir="ltr">, so the bidirectional algorithm renders it correctly and the screen reader reads it as digits rather than as RTL-mangled text.
<!-- Currency amount inside Arabic copy -->
<p>
ﺗﺑﻠﻎ ﺍﻟﻘﯾﻣﺔ ﺍﻹﺟﻣﺎﻟﯾﺔ
<bdi dir="ltr">1,250.00 QAR</bdi>
</p> Mixed-direction content in financial confirmations
Confirmation screens in banking flows — "you are about to transfer X to account Y on date Z" — routinely intermix Arabic narrative copy with Western-numeral account numbers, Latin-script SWIFT codes, and Arabic recipient names. The mixed-direction handling decides whether a screen reader can read the confirmation correctly. We see Qatari banking apps fail this regularly because the surrounding Arabic copy is bidirectional but the account number lives inside an unisolated <span>.
The language-switcher behavior
The MOTC policy expects that when a user toggles the language switcher mid-flow, they land on the equivalent page in the other language — not a home page, not a 404. For multi-step flows, the state should travel with the user across the toggle. Single-page apps with hash-routed localization tend to handle this correctly; legacy server-rendered apps with separate /en/ and /ar/ trees often do not.
Form validation in the user's locale
A surprisingly common failure: Arabic-labeled forms emit English validation messages because the validation library was configured English-only. The fix is configuration, not engineering, but the audit catches it every time. Same point applies to error toasts and ARIA-live announcements — they must be in the user's locale.
Common patterns we see across Qatari banking, government, and telecom
The audit findings cluster by sector. The patterns below repeat enough that we consider them sector-level diagnostics.
Banking
- SMS-based authentication failing accessibility. SMS OTP delivery is fine; SMS OTP that arrives in a format the screen reader can't parse, or that is delivered via an app the user can't get into without sight, fails 3.3.8.
- Numeric keypad components built with custom
divs rather than buttons — fails 4.1.2 Name, Role, Value. - Statement download as image-only PDF — untagged scans rather than tagged PDFs. Fails almost every PDF accessibility criterion at once.
- Session timeouts on transfer flows with no extension option. Fails 2.2.1 Timing Adjustable.
Government
- Authentication handoff to the national identity system — the redirect, consent screen, and return need to be keyboard-navigable and screen-reader announced. The accessibility of that handoff is part of the service's audit, regardless of who operates the identity layer.
- PDF forms as the only completion path — when a citizen must download, print, sign, scan, and re-upload a PDF, the entire service fails accessibility. The fix is to provide a digital-form alternative.
- Maps embedded from third parties — Google Maps, Mapbox, or in-house GIS. Inherits the vendor's accessibility posture. Either replace, get the vendor to fix, or document a credible alternative path (an address search, a list view, a phone number).
Telecom
- Self-service portals with custom dropdowns and tab panels — fails 4.1.2 broadly. The fix is usually to fall back to native HTML elements.
- Coverage maps — the same third-party map issue as government services.
- Bill-payment confirmation pages with mixed-direction content not isolated, per the bilingual section above.
- Auto-playing promotional video on the homepage — fails 1.4.2 Audio Control and frequently 2.3.1 Three Flashes if the video is heavy on transitions.
The pre-launch checklist for operators new to Qatar
If you are a Gulf operator preparing to bid on a Qatari tender or to launch a service in Qatar, this is the sequence we run with our customers:
- Baseline audit against WCAG 2.2 AA on every in-scope surface — web, mobile, authenticated flows. Get the score.
- Layer the MOTC additions — bilingual parity audit, accessibility-statement publication, barrier-report SLA commitment.
- Decide on Mada certification per the rule above. If yes, layer the switch-access, voice-control, magnification, and reading-mode tests.
- Assemble the evidence pack in the MOTC-expected shape: signed PDF, accessibility statement, contact route, remediation plan, statement of independence.
- Commit to a re-audit cadence — at least every two years for services scoring above threshold; annually for services below. Quarterly internal monitoring between formal audits.
The work is sequenced, not parallel — each step depends on the previous one. Most operators arriving in Qatar from Saudi Arabia find that step 1 is largely done (the DGA work transfers) but steps 2 and 3 are net new.