Oman digital services: make accessibility a release criterion, not a late fix

A digital service is not complete because its main screen looks good on a designer's laptop. It is complete when a person can sign in, understand the form, correct an error and finish the task with the tools available to them. Oman’s Digital Accessibility Guideline gives government teams a practical reference for websites and apps, with particular emphasis on WCAG Level AA. The Ministry of Health’s current accessibility statement shows the operating shape of that work: it covers portals, forms, dashboards, mobile apps and documents, and commits to regular testing and supplier requirements.

That guidance is directed at government digital services; a private business should not present it as a blanket legal obligation. But it is a useful delivery standard for any Oman-based customer portal, booking flow, employee system or mobile app. Accessibility belongs in the definition of a releasable feature, alongside security, language support and performance—not in a backlog item created after users struggle.

Turn accessibility into a release test

Choose the one journey that matters most: submitting an application, booking an appointment, paying an invoice or approving a request. Test it from start to finish before every material release. A developer should be able to complete it with only a keyboard, at 200% zoom, and with clear focus at every step. A reviewer should also check that form labels, required fields, errors and success messages make sense without relying only on colour, position or an icon.

For bilingual products, test the Arabic journey as its own experience. A translated label is not enough if the reading order, right-to-left layout, field hints, numbers, dates, error text or uploaded-document instructions become confusing. Keep the same task and acceptance criteria in both languages; the implementation can differ, but the ability to finish the job should not.

The failures that polished interfaces still hide

• Keyboard traps and hidden focus: a modal, navigation menu or date picker opens, but a keyboard user cannot see where they are or escape it predictably.
• Unusable authentication and forms: a login depends on a puzzle, a field has no programmatic label, or an error is shown only as a red border after a long form submission.
• Pointer-only interactions: a mobile or kiosk task requires a drag gesture, a tiny target or a hover action with no equivalent control.
• Content outside the interface: a scanned PDF, image-only notice, video without captions or vague alternative text blocks the journey after the website itself appears to work.

These are not merely design preferences. WCAG 2.2 includes testable criteria for focus that is not obscured, alternatives to dragging movements, target size, accessible authentication and avoiding redundant entry. Automated checks can catch some defects, but they cannot decide whether a real applicant understands an Arabic error message or can recover after entering the wrong document number.

A one-week practical plan

Name a product owner for one high-value journey. Write five acceptance checks: keyboard completion, visible focus, usable form errors, 200% zoom and a complete Arabic and English pass. Add captions, transcripts or useful alternatives for the content that journey relies on. Then have someone outside the build team run the test and log failures with the same priority as a broken payment or missing record. For a supplier-built system, put this acceptance test and the evidence required to pass it into the statement of work before the contract is signed.

This is practical engineering guidance, not a legal compliance opinion. The important management decision is simple: do not buy or release a digital service until its core task has been tested for people who do not use it exactly as the build team does. That makes the service more dependable for everyone—and makes later accessibility work smaller, cheaper and less disruptive.

1. 01Digital Accessibility Guideline — Gov.om
2. 02Digital Accessibility Statement — Ministry of Health Oman
3. 03Web Content Accessibility Guidelines (WCAG) 2.2 — W3C