The Disability Rights Context

Saudi Arabia’s Law of Rights of Persons with Disabilities is the starting point for understanding the national direction. Its implementing regulations are published through the Authority for the Care of People with Disabilities. The framework concerns rights, services, participation and the responsibilities of relevant bodies across society. [1] [2]

For digital teams, the important point is that access cannot be reduced to the physical environment. Information, communication and services increasingly reach people through digital interfaces. If a required service can be completed only online, barriers in its forms, documents, media or authentication process can become barriers to the service itself.

The law and regulations should still be read accurately. A broad right to access or receive services is not the same thing as a clause naming every WCAG success criterion. Technical conformance claims therefore need a separate benchmark, a defined scope and evidence from testing.

Saudi Arabia’s national framework also sits within the wider principles of the United Nations Convention on the Rights of Persons with Disabilities. Article 9 of the Convention addresses access to information and communications, including information and communications technologies and systems. [8]

The Role of the Digital Government Authority

The DGA is central to the government side of the framework. Its Digital Government Regulatory Framework brings together principles, policies, standards and guidance for digital government. The Core Digital Transformation Standards then turn that framework into measurable expectations for government entities. [3] [4] [5]

The standards are broader than accessibility. They cover areas such as strategy, institutional capability, digital services, beneficiary experience, channels, data and technology. Accessibility is therefore best understood as part of the way a government service is designed, delivered, measured and improved.

Within the standards programme, government entities are expected to make digital services available to different beneficiary groups, including people with disabilities, and to retain evidence that inclusive access has been implemented. The framework also connects service delivery with channel planning, user experience and continuing improvement. [3] [4]

This matters for accountability. A policy statement alone does not demonstrate that a service works. Evidence may include approved requirements, accessible design specifications, supplier deliverables, audit results, remediation records, test scripts, accessibility statements, user research and release controls.

What Government Entities Should Take From the Standards

A government entity should treat accessibility as an operational responsibility across the full service lifecycle. The following practices align the DGA’s outcome-based expectations with a credible technical programme.

• Identify accessibility requirements before design and procurement decisions are fixed.
• Include people with disabilities among the beneficiary groups considered in research, service design and testing.
• Set a documented technical baseline for websites, applications, documents, media and acquired systems.
• Apply the requirements to complete journeys, including registration, identity verification, payment, booking and support.
• Require suppliers to provide conformance evidence and to correct defects before acceptance.
• Use repeatable quality controls during design, development, content publishing and release.
• Keep evidence of testing, remediation, exceptions, ownership and future review.
• Provide a clear route for users to report accessibility barriers and receive support.

The responsible team should extend beyond developers. Product owners decide scope and priorities. Designers shape interaction and visual presentation. Content teams control language, headings, alternatives and documents. Procurement teams influence supplier obligations. Quality assurance teams define acceptance evidence. Leadership assigns ownership and resources.

Does Saudi Arabia Require WCAG

The safest answer is specific rather than absolute. The official Saudi sources reviewed for this article clearly support accessible digital services in government and inclusive access for people with disabilities. They do not support the claim that one publicly stated WCAG version is a universal statutory requirement for every Saudi website. [3] [4] [5] [6]

This distinction is important because several online summaries describe a Saudi Web Accessibility Standard or a nationwide WCAG 2.1 Level AA mandate as though it applies identically to public and private organisations. A legal or compliance statement of that kind should not be repeated without a current primary source from the competent Saudi authority.

WCAG remains the most useful technical benchmark. It turns an accessibility objective into criteria that teams can design, test and procure against. Level AA is widely used because it includes the foundational Level A requirements and additional criteria that address common barriers without requiring every Level AAA criterion. [9] [10]

WCAG 2.2 Level AA is preferable for new work. WCAG 2.2 builds on WCAG 2.1 and adds requirements addressing current interaction patterns, including focus appearance, focus not being obscured, dragging movements, target size, consistent help, redundant entry and accessible authentication. A service conforming to WCAG 2.2 also needs to satisfy the applicable WCAG 2.1 criteria. [9]

If a Saudi authority, sector regulator, contract or tender names WCAG 2.1, WCAG 2.2 or another standard, the named requirement governs that relationship. An internal WCAG 2.2 target should supplement, not replace, those obligations.

What the Framework Means for Private Companies

Private companies should avoid two opposite mistakes. The first is to assume that every Saudi website is already subject to one identical WCAG clause. The second is to assume that accessibility is irrelevant outside government. The actual position depends on the organisation’s activities and relationships.

Accessibility may become a direct or practical requirement when a private company is involved in any of the following.

• Designing, developing, hosting or operating a government website, application or digital platform.
• Delivering a public service on behalf of a government entity.
• Responding to a tender or contract that includes accessibility standards, test evidence or acceptance criteria.
• Operating in a regulated sector with customer access, communication or service requirements.
• Providing a system that government employees or beneficiaries must use.
• Serving customers in another jurisdiction whose accessibility rules apply to the product or service.
• Making a public commitment to WCAG conformance, inclusive service or equal access.

Even where no specific WCAG clause has been identified, accessibility can reduce failed transactions, support more customers, improve procurement readiness and lower the cost of later remediation. The stronger business decision is to define and evidence an accessibility baseline before a complaint, tender or major redesign forces the issue.

Government Suppliers and Procurement

Government procurement is one of the clearest routes by which accessibility expectations reach private suppliers. A supplier may be asked to meet requirements in a request for proposal, technical specification, design system, acceptance plan or service-level agreement.

Vague wording such as accessible for everyone is difficult to test and enforce. Procurement documents should state the product scope, named standard and level, testing methods, required evidence, defect severity, remediation times, acceptance authority and continuing obligations after release.

Useful supplier evidence can include an accessibility conformance report, a completed evaluation against the agreed WCAG version, manual test results, assistive technology results, a list of known limitations and a remediation plan. A generic certificate or automated scan score should not replace evidence from the actual product.

Contracts should also address third-party components. Payment gateways, identity services, document viewers, chat tools and embedded maps can interrupt an otherwise accessible journey. The organisation needs a plan for testing the integration, escalating defects and providing an accessible alternative when it cannot control the third party directly.

Accessibility Covers More Than Websites

A mature programme covers every digital touchpoint needed to find, understand and complete a service. Depending on the organisation, the scope may include the following.

• Public websites, microsites and customer portals.
• Mobile applications and responsive web services.
• Registration, login, one-time password, identity verification and recovery journeys.
• Forms, bookings, payments, uploads and confirmation messages.
• PDF files, Word documents, reports, policies and downloadable forms.
• Video, audio, webinars, captions, transcripts and social media content.
• Self-service kiosks, ticketing devices and other public digital interfaces.
• Internal systems used by employees, contractors and service teams.

Testing only a home page gives a false sense of confidence. A user may be able to read the landing page but still fail at date selection, document upload, identity verification or payment. The audit scope should follow the user’s task from entry to completion.

Arabic and Bilingual Services

Saudi digital services are commonly Arabic-first or bilingual. Accessibility must be tested in every supported language because layout, content and component behaviour can change between versions.

• Set the correct page and passage language so screen readers use the appropriate pronunciation.
• Verify right-to-left reading order, focus order and visual placement.
• Test mixed Arabic and English labels, numbers, dates, addresses and codes.
• Check that visible Arabic labels match the programmatic names announced by assistive technology.
• Review Arabic error messages, instructions, alternatives, captions and support content.
• Test both Hijri and Gregorian date controls when the service offers them.
• Confirm that PDFs have meaningful tags, headings, tables and reading order in Arabic.

An English interface passing an automated check does not prove that the Arabic interface works. Direction changes can alter navigation order, icon placement and component logic. Arabic content also needs human review because automated tools cannot judge whether an alternative description, instruction or error message communicates the intended meaning.

What Level AA Means in Practice

WCAG Level AA affects design, code, content and interaction. A credible implementation normally includes the following results.

• All essential functions can be reached and operated with a keyboard without trapping the user.
• Keyboard focus is visible, predictable and not hidden behind other content.
• Images that convey meaning have appropriate text alternatives.
• Form fields have accessible names, instructions, error identification and status messages.
• Text and essential controls meet colour contrast requirements.
• Content remains usable when text is enlarged or the viewport becomes narrow.
• Headings, landmarks, lists and tables communicate the correct structure.
• Controls expose accurate names, roles, values and states to assistive technology.
• Video has captions and other alternatives when required.
• Authentication avoids unnecessary memory, transcription and physical interaction barriers.

Automated scanning helps identify repeatable code-level failures, but it cannot judge all content, interaction or user experience. Manual testing, keyboard testing and testing with screen readers and other assistive technologies are needed to understand whether the service works in practice.

Accessibility Is Broader Than a Widget

An accessibility widget can offer personalisation features such as text resizing, contrast changes or reading support. It cannot independently establish WCAG conformance or correct every barrier in the underlying product.

A widget cannot decide whether alternative text conveys the correct meaning, repair an inaccessible custom control, add accurate captions, fix the reading order of a PDF or verify that a complete Arabic service journey works with a screen reader. It may support some users, but it does not replace accessible design, remediation and testing.

Organisations should be especially careful with claims such as fully accessible or certified compliant. A defensible statement identifies the standard, version, level, scope, testing date, methods, known limitations and contact route.

Governance Evidence and Continuing Improvement

Accessibility degrades when it is treated as a one-time project. New pages, components, documents, campaigns and integrations can introduce barriers after an audit. Governance is what keeps the standard active.

A practical governance model assigns an executive sponsor, an accountable accessibility owner and defined responsibilities across product, design, engineering, content, procurement, quality assurance, customer support and legal or compliance teams.

Evidence should be proportionate and useful. Keep the approved baseline, scope decisions, audit reports, remediation tickets, exception decisions, supplier evidence, retest results, accessibility statement and feedback records. These materials support internal assurance and make future reviews faster.

Metrics should measure outcomes rather than only activity. Useful measures include the percentage of critical journeys tested, high-severity defects closed, supplier deliverables accepted, documents remediated, staff trained for relevant roles and user-reported barriers resolved.

What Saudi Organisations Should Do Now

1. Map the applicable framework Identify the responsible authority, sector rules, government relationship, tender terms and contractual commitments. Separate legal duties from technical targets and internal policy.
2. Adopt a named baseline Use WCAG 2.2 Level AA for new and substantially updated services unless a competent authority or contract specifies another standard.
3. Assign accountable ownership Name an accessibility owner and define decision, reporting and escalation responsibilities across the organisation.
4. Include accessibility in procurement Put measurable requirements, evaluation evidence and remediation obligations into briefs, requests for proposal, contracts and acceptance criteria.
5. Audit representative journeys Test high-value and high-risk tasks such as registration, login, identity verification, booking, payment, document upload, download and support.
6. Test Arabic and English separately Verify language, direction, content, components and assistive technology behaviour in each supported version.
7. Combine evaluation methods Use automated checks for coverage, then add expert manual review, keyboard testing and assistive technology testing.
8. Remediate underlying barriers Fix code, design, content and document issues. Do not rely on an overlay or widget as the primary response.
9. Publish an accurate statement Explain the standard, scope, current position, known limitations, support route and improvement process without making unsupported claims.
10. Retest and maintain Verify fixes, monitor releases, review supplier updates and reassess critical journeys on a defined schedule.