United Arab Emirates

The UAE National Digital Accessibility Policy is one of the clearest public frameworks in the region. It aims to give people of determination and older people effective access to digital products and services. The official policy materials identify duties for federal government entities, mandatory staff training, technical guidance and the role of a digital accessibility officer. [4]

The policy’s technical guidance explicitly references WCAG 2.1 Level AA for public service websites. At the same time, newer UAE government accessibility statements and design initiatives increasingly reference WCAG 2.2. For organisations building or renewing a platform, WCAG 2.2 Level AA is therefore the more future oriented target, unless a contract or authority specifies otherwise. [5]

The policy does not justify a blanket claim that every private website in the UAE is automatically subject to the same federal obligations. Private companies may still be affected through local laws, sector regulation, government contracts, public service delivery or procurement requirements. The scope must be checked rather than assumed.

Saudi Arabia

Saudi Arabia’s accessibility direction is increasingly visible through government digital governance and entity level policies. In 2026, the Digital Government Authority published a digital accessibility policy for its platforms that refers to WCAG 2.2 Level AA. Other Saudi public bodies publish their own accessibility commitments, sometimes using WCAG 2.1 or a higher target for a specific service. [6]

This development matters to technology suppliers and agencies working with Saudi government entities. Accessibility should be addressed in requirements, design systems, acceptance criteria and testing evidence. It should not be left until the final launch review.

The national and sector specific position needs careful reading. A policy published by one authority does not automatically prove that every private sector website in Saudi Arabia has the same conformance obligation. A later article in this series will examine the Saudi framework, government standards and commercial implications in detail.

Qatar

Qatar established a national e-accessibility policy with support from Mada Center. Mada describes the policy as covering websites and mobile applications, telecommunications services, automated teller machines, public electronic kiosks and assistive technologies. It also calls for accessible digital content, including Arabic content. [7]

Qatar’s government website and mobile service frameworks have referred to WCAG in public digital services. Mada now provides policy support, digital accessibility services, accreditation, training and technical resources, including Arabic material for WCAG 2.1. This gives Qatar a structured institutional model that extends beyond a single website standard. [7] [8] [9]

Organisations should still confirm which version and conformance level a current tender, authority or accreditation process requires. A framework that originally referred to WCAG 2.0 may be implemented today with newer WCAG 2.1 or 2.2 expectations.

Bahrain Kuwait and Oman

Bahrain, Kuwait and Oman continue to expand digital government services and provide online services for people with disabilities. Their official portals are useful starting points, but the technical and contractual requirements for a specific project may sit with a ministry, regulator, procurement authority or delivery contract rather than one regional accessibility document. [10] [11] [12]

For organisations operating across these markets, the safe approach is to adopt a strong internal baseline and then perform a country and sector review. Waiting for a customer complaint or a tender clarification usually creates more cost than building accessibility into the product lifecycle from the start.

The Common Technical Language Is WCAG

Despite different policy structures, WCAG is the common technical language across the region. It allows government buyers, designers, developers, auditors and product owners to discuss testable requirements rather than vague claims that a platform is easy to use.

For most new public facing services, WCAG 2.2 Level AA is a reasonable target because it includes all Level A and Level AA requirements and adds criteria that address current interaction patterns. An organisation must still check whether an authority or contract specifies WCAG 2.0, WCAG 2.1, WCAG 2.2, a national standard or additional requirements.

What WCAG Level AA Means in Practice

A credible Level AA programme affects the underlying product, not only the appearance of the page. Typical requirements include the following.

• People can reach and operate interactive functions with a keyboard without becoming trapped.
• Keyboard focus is visible and follows a logical order.
• Images that communicate meaning have appropriate text alternatives.
• Form fields have accessible labels, instructions and error messages.
• Text and important interface elements have sufficient colour contrast.
• Content remains usable when text is enlarged or the page is viewed on a narrow screen.
• Buttons, links and controls expose correct names, roles and states to assistive technology.
• Recorded video provides appropriate captions, and audio or visual alternatives are supplied where required.
• Page structure uses meaningful headings, landmarks and reading order.
• Authentication and input processes do not create avoidable barriers for users with cognitive, visual or motor disabilities.

This work usually requires design review, code review, automated scanning, manual testing, keyboard testing and testing with assistive technology. Automated tools are useful, but they cannot determine whether every text alternative is meaningful, whether focus order makes sense, whether instructions are understandable or whether a complete user journey works with a screen reader.

Arabic and Bilingual Accessibility

Accessibility in the GCC must work in Arabic as well as English. Translating an accessible English page does not guarantee that the Arabic version remains accessible. Right to left layout, language metadata, reading order and component behaviour can all change when the interface switches language.

Regional testing should check that the page language and language changes are identified in code, Arabic labels are announced correctly, focus order remains logical in right to left layouts, and mixed Arabic and English content is understandable with screen readers. Teams should also review Arabic form validation, date fields, phone number inputs, menus, carousels and downloadable documents.

Arabic PDF accessibility deserves separate attention. A document can look correct visually while its tags, reading order, table structure and text encoding make it difficult to use with assistive technology. The same applies to bilingual reports and forms containing both left to right and right to left content.

Accessibility Is Broader Than a Widget

Accessibility widgets can provide useful personalisation features such as text resizing, colour adjustments or reading support. They do not by themselves correct every barrier in the website’s source code, content and interaction design.

For example, a widget cannot reliably repair an unclear form, create a logical heading structure, write an accurate text alternative, correct a broken keyboard interaction, caption a video or confirm that a checkout journey works with a screen reader. An organisation may use an accessibility tool as one part of its approach, but conformance depends on the underlying product and the evidence produced through testing.

What GCC Organisations Should Do Now

1. Identify the applicable requirements Map each service to its country, sector, regulator, customer and contract. Separate legal obligations from internal standards and good practice.
2. Adopt a technical baseline Use WCAG 2.2 Level AA for new and substantially updated products unless a binding requirement specifies another standard.
3. Include accessibility in procurement Add measurable requirements to briefs, requests for proposal, statements of work, acceptance criteria and supplier contracts.
4. Test more than the home page Cover representative templates and complete journeys such as registration, authentication, search, payment, booking, document download and support.
5. Combine automated and manual evaluation Use automated tools for repeatable checks, then add expert review, keyboard testing and assistive technology testing.
6. Include Arabic content and documents Test right to left interfaces, bilingual components, PDFs, videos and other content that sits outside the main website templates.
7. Retest after remediation Confirm that fixes work and that changes have not introduced new barriers. Accessibility is an ongoing product responsibility, not a one time certification exercise.