Qatar’s published 2011 e-Accessibility Policy identifies WCAG 2.0 Level AA as its website reference and requires public-sector websites providing public information and services to meet international accessibility standards. The Government Website and e-Services Framework also identifies AA as the minimum and encourages higher levels where feasible. These are dated policy references, not evidence that all subsequent requirements remain unchanged. [1] [2]
Mada describes its role in developing national accessibility policy and supporting government digital frameworks. Its current web accessibility services page refers to WCAG 2.2 Levels A and AA. The same page describes accreditation eligibility through a Mada Web Accessibility Monitor score of at least 90% plus successful manual usability assessment. [3] [4]
Treat this as a specific accreditation process. A monitoring percentage is not interchangeable with a WCAG conformance claim. Organisations pursuing Mada accreditation should confirm the current procedure directly with Mada. An external audit can support preparation, but it does not authorise another provider to issue Mada accreditation.
Qatar’s Ministry of Social Development and Family confirms the issuance of Law No. 22 of 2025. Its official summary includes nondiscrimination, reasonable accommodation and securing digital accessibility and access to information technology. Al Meezan lists the law as in force. [5] [6]
The important organisational distinction is between a broad legal duty and the technical criteria used to assess a product. Do not assume that a general reference to digital accessibility automatically specifies WCAG 2.2 AA, requires a VPAT for every purchase or establishes the same deadline for every organisation. Obtain an applicability review before making those claims in a contract or public statement.
An MCIT-hosted executive summary is explicitly labelled “Upcoming National ICT Accessibility Policy” and describes WCAG 2.2 AAA where possible. The material reviewed does not establish that this upcoming version has formally entered into force. Therefore, this article does not present it as an enacted universal AAA obligation. [7]
Before approving a project, request the authoritative instrument, its effective status, applicable entities and any implementation instructions. This prevents a proposal, guidance page or historical policy from being used as an inaccurate acceptance condition.
For new and substantially redesigned web services, VisiAble recommends WCAG 2.2 Level AA as a technical project target, alongside any applicable local or contractual requirements. W3C recommends the latest WCAG version when developing or updating policies. Level AA requires all applicable A and AA criteria, and conformance addresses full pages and complete processes. [8]
If a contract names an earlier version, record that requirement rather than silently replacing it. Ask the evaluator to explain the mapping and any additional checks needed. Conversely, do not commission a new platform solely against a historical baseline without considering the needs covered by more recent criteria.
Where a project seeks additional AAA improvements, define the particular criteria and coverage. A blanket statement that a service is “AAA compliant” requires much stronger evidence than selecting a few enhanced features.
Start with tasks that have consequences for users. Examples include submitting an application, booking healthcare, managing a bank transaction, applying for employment or accessing learning material. For each task, document the full path, responsible suppliers and any dependencies on documents or external systems.
The following assessment brief is a recommended delivery approach, not a claim that every listed item is a separate Qatari statutory requirement.
Web transactions
Discovery, forms, validation, payments and confirmation
Define priority complete journeys
Authentication
Registration, recovery and verification paths
Agree identity-provider boundaries
Bilingual content
Arabic and English messages and documents
Assign content and technical owners
Mobile apps
Platform-specific interaction and assistive technology
Commission an appropriate app scope
Documents and media
Essential downloads and instructional content
Identify separate review coverage
External components
Booking, payment and embedded help systems
Obtain supplier evidence and repair commitments
Use the table to agree coverage before pricing the audit. A count of URLs alone says little about difficulty: one transactional service may contain more interaction states than dozens of informational pages. Include access to authenticated areas, realistic test data and clear rules for testing external platforms.
For Qatar-facing services, Arabic should be part of the assessment scope from the beginning. Mada’s policy discussion specifically highlights accessible Arabic digital content. [3] In practice, English approval should not be used as a substitute for testing the Arabic journey.
Review equivalent tasks in both languages, including errors and confirmation messages. Inspect mixed-direction content such as reference numbers, dates and telephone numbers. Check whether switching language preserves the user’s context and whether translated instructions give the same information about requirements and fees.
Assign language-specific findings to the relevant content and development owners. Shared components may need one technical repair, while instructions or PDFs may require separate changes in each language. Clear ownership prevents the same defect from being closed in English while remaining unresolved in Arabic.
Accessibility belongs in the purchase brief, not only in a final review. Mada’s policy portal provides procurement-related resources, including a guide to adopting an ICT accessibility procurement policy. [9] Organisations can use such resources to inform their processes while confirming the rules applicable to the specific tender.
Ask bidders to state the standard, scope, methods, supported technology combinations and exclusions. Require practical evidence from the product being purchased, not only a marketing statement about an accessible design system. A supplier should also explain how defects will be repaired and who will verify the corrections.
Recommended contract deliverables include a documented assessment plan, an issue register with reproducible evidence, remediation responsibilities and retesting arrangements. If an ACR or another conformance document is requested, identify the format and the product version it will describe. Do not assume such documentation is universally mandatory in Qatar.
An automated accessibility checker can support accessibility testing in Qatar by identifying selected technical failures across the pages it can inspect. W3C explains that no evaluation tool alone can establish whether a website meets accessibility standards. Combine automated checks with expert manual evaluation, keyboard testing and relevant assistive technologies, covering the agreed Arabic and English service journeys. [10]
User involvement adds another perspective. Ask people with different access needs to carry out realistic tasks and capture the difficulties they encounter. W3C recommends combining user evaluation with standards-based assessment. [11] Describe participant coverage accurately; feedback from a small group cannot establish accessibility for every disability or task.
Consider a hypothetical organisation in Qatar offering online appointments. Its homepage has a strong automated score, but the appointment calendar cannot be operated with a keyboard. The English error message explains a missing field, while the Arabic version displays only a colour change. The confirmation arrives as an image-only attachment.
The practical assessment follows the whole booking: service discovery, language choice, date selection, validation and confirmation. Findings are grouped by root cause, allocated to the platform and content owners, then retested after repair. This example is illustrative and does not describe a VisiAble client or an assessed Qatari organisation.
Confirm requirements
Review applicable rules and agree the benchmark
Requirements register
Map scope
Inventory services, languages and dependencies
Scope and prioritised journeys
Evaluate
Combine methods and document limitations
Findings with reproducible evidence
Remediate
Assign owners and address root causes
Repair plan and implementation record
Verify
Retest fixes in the agreed build
Verification outcomes and open issues
Maintain
Set release reviews and feedback handling
Ownership, monitoring and review triggers
Set milestones against the actual complexity of your services. Avoid promising full remediation within an arbitrary number of days before understanding legacy systems, supplier dependencies and document volumes. Progress should be visible through resolved barriers and verified journeys, alongside monitoring indicators.
Assign an accountable owner, with responsibilities across development, content, procurement and service delivery. Review accessibility when templates change, new documents are published or external integrations are replaced. Training should cover the decisions each team actually makes, rather than relying only on a general awareness session.
An accessibility statement should explain the organisation’s position, known limitations and a usable contact route. W3C provides guidance on preparing such statements. [12] Ensure that feedback reaches a team able to respond and assign a repair; publishing a statement without an operational process offers limited help to a blocked user.
The sources reviewed do not establish one universal requirement for every website. Confirm the organisation’s legal, policy, sector and contractual obligations. WCAG 2.2 AA is VisiAble’s recommended technical target for new web work, not a substitute for that review.
No such conclusion is established here. The published summary is labelled upcoming and refers to AAA where possible. Confirm formal adoption and scope before using it as a mandatory project condition. [7]
No. An audit evaluates an agreed scope and produces findings. Mada accreditation follows Mada’s own eligibility and assessment process. Confirm current accreditation arrangements with the centre. [4]
Yes, where both versions are offered. Include equivalent journeys, messages and relevant documents in each language. A shared template does not prove that the content and interactions are equally accessible.
A widget may offer useful preferences, but its presence is not evidence that a complete service conforms. Assess the underlying product, the tool’s interactions and the agreed scope before making a claim.
No. The findings describe the assessed version and scope. New content and software changes can introduce barriers. Define ongoing checks and reassessment triggers as part of service ownership.
VisiAble helps organisations evaluate digital accessibility through professional audits, manual testing and conformance documentation based on recognised standards. For Qatar-facing projects, the assessment can be scoped around priority services, Arabic and English journeys, relevant content and the agreed technical benchmark.
Agree deliverables, remediation support and any retesting before commissioning the work. VisiAble’s role is to provide assessment evidence and practical guidance within that scope; legal applicability and any official accreditation remain separate decisions.
Planning a launch, redesign or procurement review in Qatar? Request a professional accessibility audit and establish what your team needs to test, fix and verify.