The Saudi Digital Government Authority no longer publishes accessibility as guidance. It publishes a score — a 0–100 composite index attached to every public-facing digital service operated by a Saudi government entity. By 2030, every service must reach 80. Roughly two-thirds of in-scope services do not yet hit that bar. The remaining four years are an unusually concrete deadline, and this is the field guide we hand our customers when they ask what the regulator is actually measuring.
What the DGA accessibility index measures
The DGA index is not a single number from a single tool. It is a weighted composite that rolls up five tracks:
- Technical conformance to WCAG 2.2 Level AA — the foundation. Automated checks against the W3C's 50 success criteria, supplemented by manual review of the criteria that cannot be automated (focus order, keyboard traps, screen reader announcements, motion safety).
- Arabic / English parity — does the service work equivalently in both languages? This is its own audit dimension, weighted separately from the underlying WCAG score, because the DGA has observed that English-passing services routinely fail in Arabic.
- Mobile experience — both responsive web behavior and any native iOS/Android apps the service exposes. Native apps are tested against WCAG-equivalent platform criteria (iOS Accessibility, Android Accessibility Suite).
- Authentication and identity flow accessibility — almost every Saudi public service flows through Nafath, the National Single Sign-On. The accessibility of that handoff is part of the service score, even when Nafath itself is operated by a different entity.
- Citizen support channels — the help, chat, FAQ, and barrier-reporting routes. These count because they are how a user with a disability tells you the rest of the service is broken.
A single Mueen audit produces findings across all five tracks. Reports surface them separately so a program manager can see which dimension is pulling the composite down.
Why 80 is the threshold
Scores break into bands and each band carries consequence:
- ≥ 90 — published on the unified citizen portal as a reference service. Subject to lighter audit cadence (annual).
- 80 – 89 — passes. The 80 floor is the line every public-facing service must reach by 2030.
- 75 – 79 — visible on the public dashboard with a remediation plan attached. Twice-yearly audit cadence expected.
- Below 75 — continuous monitoring required, quarterly remediation milestones reported upward to the Vision 2030 program owner.
- From 2027 — services persistently below 75 face removal from the unified citizen portal until remediated.
The 80 was chosen because it represents WCAG 2.2 AA conformance plus a measurable margin for bilingual parity and mobile coverage. A service that hits 80 has demonstrably done the work in all five dimensions — it cannot be reached by passing WCAG alone.
The five fastest paths to compliance
These are the moves we see produce the largest score lift per engineering hour. They are ordered by how cheap they are to ship, not by how virtuous they are.
1. Audit the bilingual flow as if it were a separate product
The DGA index treats Arabic and English as parallel surfaces. Most teams treat Arabic as a translation layer dropped onto an English layout. The audit catches every gap: hardcoded text-align: left instead of text-align: start, directional icons that don't mirror, error toasts not announced in Arabic via aria-live, language-switcher buttons that drop the user on a home page rather than the equivalent Arabic URL. Fix these and the parity sub-score moves materially without touching WCAG conformance at all.
2. Replace placeholder-as-label patterns universally
Forms that use placeholder text as the only label fail WCAG 1.3.1, 3.3.2, and 4.1.2 simultaneously. One pattern, three findings. The fix is mechanical — replace placeholder labels with real <label> elements, programmatically associated.
<!-- Before -->
<input type="email" placeholder="Email address" />
<!-- After -->
<label for="email">Email address</label>
<input id="email" type="email" autocomplete="email" />3. Make focus visible — globally — using 2.2 criteria
WCAG 2.2 added two focus-related success criteria (2.4.11 Focus Not Obscured Minimum, 2.4.13 Focus Appearance) on top of the older 2.4.7. The fix is a single global rule. Use :focus-visible so the indicator only shows on keyboard/programmatic focus, not on every mouse click.
:focus-visible {
outline: 2px solid var(--mueen-green-deep);
outline-offset: 3px;
border-radius: 4px;
}4. Ensure interactive targets are at least 24×24 CSS pixels
WCAG 2.5.8 Target Size (Minimum) is new in 2.2 and trips up nearly every mobile nav. Audit your icon buttons, sort handles, chips, and pagination controls. Bump padding rather than icon size where you don't want to disrupt design.
5. Run an automated check on every PR
One audit gives you a snapshot. One audit per PR gives you a program. Wire axe-core or your preferred engine into CI as a non-blocking step first, then promote the most severe categories to blocking once the team trusts the signal. The DGA cares about trend; continuous monitoring is what produces a defensible trend line.
What counts as a service in scope
The DGA's definition is broader than most teams initially read it. In scope:
- Every public-facing web service operated by a ministry, authority, municipality, public university, or public hospital.
- Every mobile application (iOS, Android) published by such an entity.
- Authenticated portals where the user is acting as a citizen (e.g. tax filings, benefit applications, permit renewals).
- Public-facing kiosks and self-service terminals where they expose a digital UI.
- PDF forms and other downloadable digital assets that the user must complete to receive a service.
- Third-party services embedded into a government property under government branding (e.g. an embedded payments component).
Out of scope, currently: internal-only staff tools (though ISO/IEC 30071-1:2019 captures these elsewhere), archived content not actively maintained, and content provided by third parties under their own branding.
The evidence pack format DGA accepts
When you submit an audit to demonstrate conformance, the DGA expects a specific bundle. We see submissions rejected for shape more often than for substance.
- A signed PDF report from an auditor independent of the agency that built the service. Dated within the last 12 months. Includes findings grouped by severity, mapping to WCAG success criteria, and the headline composite score.
- A signed JSON manifest of the same findings, in a structured format that DGA inspectors can verify mechanically. This is what makes spot-checks possible at scale.
- Raw axe-core or equivalent output for technical review.
- The auditor's statement of independence — a one-paragraph confirmation that the auditing firm is not also the firm that built or operates the service.
- The remediation plan with named owners and dates, scoped to the regulator-expected windows (Critical: 30 days, Serious: 90 days, Moderate: 180 days, Minor: annual cycle).
Mueen reports ship in this exact format because we built the report shape from the DGA's required submission. The PDF and JSON come out of the same audit run.
Third-party audit cadence
Annual is the floor and increasingly the worst case:
- Services scoring ≥ 80 — annual third-party audit.
- Services scoring 75 – 79 — twice-yearly third-party audit.
- Services scoring < 75 — continuous monitoring with quarterly remediation milestone reports.
The third-party requirement is non-negotiable. An internal team audit, however thorough, does not satisfy the DGA. The audit must come from a firm that did not build the service. Internal teams running automated scans is a healthy practice between audits, not a substitute for one.
Common gotchas
Nafath and other SSO accessibility
The Nafath integration is part of your service score even when Nafath itself is operated centrally. The handoff — the redirect, the consent screen, the OTP entry, the return — needs to be keyboard-navigable, screen-reader announced, and accessible to users who cannot read SMS-delivered codes. If a user with a disability can complete every step of your service except the login, your service fails.
Bilingual parity beyond translation
Audit teams catch four bilingual patterns repeatedly: Arabic content in an unflipped layout (dir="rtl" missing on the root), directional icons not mirrored under RTL, mixed-direction content not isolated (phone numbers and URLs inside Arabic copy without <bdi>), and validation messages emitted only in English even when labels are in Arabic. None of these are caught by automated tools alone — they require an Arabic-speaking reviewer.
Mobile app parity
A web service that scores 85 and a mobile app that scores 50 average to a service that fails. The DGA reads the composite, not the better number. If you have an iOS and Android app, audit them against Apple Accessibility Inspector and Android Accessibility Scanner respectively, then layer manual VoiceOver/TalkBack review on top. Native testing is not optional.
Embedded third-party widgets
Maps, payment forms, chat widgets, and analytics overlays inherit their vendor's accessibility posture and contribute to your score. The remediation route is either replace the widget, get the vendor to fix it, or document the gap with a credible alternative path. The DGA accepts the third option when the documented alternative is genuinely equivalent.
PDFs that are part of the service
If users must download and complete a PDF to receive the service, that PDF is in scope. Untagged scans of paper forms fail every accessibility criterion at once. Tagged PDFs (or HTML-form equivalents) are the only acceptable shape.