Someone has told you your website needs to be accessible. It might have been a developer during a rebuild, a vendor with a widget to sell, or a procurement form on a tender. What nobody answers straight is the only question you actually asked. Is this the law, is it good practice, or is it a sales pitch?
Here is the honest version. The UAE has a real government policy with a real scope, and it probably does not bind your private company unless you do government work. What that policy points at, WCAG, is a technical standard that most of the world's accessibility rules reference. And most of what fails on a typical site is not an expensive design problem. It is careless markup, which is cheap to correct and overlaps almost entirely with building the site properly.
This guide covers the legal position precisely, then the fixes practically, then the cost.
What UAE policy actually binds
The central document is the National Policy for Digital Accessibility, issued by the Telecommunications and Digital Government Regulatory Authority in March 2024 [1] and also published on the official UAE government portal [2].
Read its scope article rather than its definitions, because the definitions are broad and the scope is narrow. The policy applies to federal government ministries, authorities and institutions. To semi-government entities, consultants, institutions and private companies engaged in digital transactions with a government entity. To partners, contractors and outsourced staff involved in those transactions. And to service providers developing websites and systems for federal entities [1].
Its technical annex adds one line in mandatory language: all public service sites must comply with Level AA of WCAG 2.1 [1].
Then, for everyone else, the language changes. Local government entities, semi-government entities and private sector entities should take the document into account and exert best efforts in compliance [1]. Should and best efforts are not must. That is aspiration, and it is worth reading the difference carefully rather than being told the policy applies to everybody.
So the practical test is simple. If you build a government-facing portal, hold a government services contract, supply a federal entity, or run a public service site, this policy reaches you and Level AA is your bar. If you run an ordinary private-sector site with no government transactions, it encourages you.
Two more things in that policy are worth knowing. It names its beneficiaries as People of Determination and Senior Citizenry, which it defines as persons aged 60 or older [1]. And its annex asks for things baseline WCAG does not, including an on-page text reader feature and text to sign language translation [1].
What we could not confirm, and why we are saying so
Two documents that could change the picture were not available to us.
Federal Law No. 29 of 2006, on the rights of people of determination, is the obvious candidate for a broader duty. Its primary text returned an access error when we tried to read it, so we do not know what it does or does not say about digital services.
Dubai Law No. 3 of 2022 we did read [3]. Article 4 gives a right of access to information platforms in accessible formats. Article 5 obliges government entities to provide service information in accessible formats. Neither article names websites or WCAG, and neither reaches private companies. Article 14 calls for an implementing bylaw, which we could not locate, and a bylaw is exactly where specific digital requirements would sit.
So we will put it plainly. We could not confirm a general private-sector legal requirement to meet WCAG in the UAE. We are not telling you there is none, because we did not get to read two of the documents that would settle it. If you are in a regulated sector, if you bid for government work, or if a client contract references accessibility, confirm the position with the relevant authority and take your own legal advice. We do not give legal advice.
Which version of WCAG, and why the answer is messy
Three official UAE sources give three different answers.
The National Policy for Digital Accessibility names WCAG 2.1 Level AA, three separate times [1]. TDRA's own digital accessibility statement, describing TDRA's own platforms, cites WCAG 2.2 AA [4]. The UAE Design System page says components are tested for WCAG 2.0 guidelines in one place and refers to adhering to WCAG 2.2 in another [5].
We report all three rather than picking one, because picking one would invent a settled position that does not exist. What they agree on is Level AA. The version number is the unsettled part.
The practical advice is easier than the confusion suggests. Target the most recent version unless a contract or tender names a specific one, in which case use the version it names. The versions are additive rather than competing. WCAG 2.2 added nine success criteria on top of WCAG 2.1 and is backward compatible, so content that meets 2.2 also meets 2.1 at the same level [6]. Aiming at the newer one is cheap insurance.
On levels, W3C describes AA as the level many organisations strive to meet [7], and cautions against requiring AAA site-wide because it is not possible to satisfy all Level AAA criteria for some content [8]. AA is the sensible target for a commercial site. AAA is not.
Most of what is broken is markup, not design
This is the part that changes the budget conversation. Here are the failures we find most often, what each one actually breaks, and how deep the fix goes.
Images with no useful alternative. Success Criterion 1.1.1, Level A, asks that non-text content has a text alternative serving an equivalent purpose [9]. Meaningful images need a description. Decorative ones should be marked so assistive technology skips them. This is an attribute per image. It is content work, not design work.
Headings used as styling. If your section titles are bold, larger paragraphs rather than real heading elements, screen reader users lose the ability to navigate the page by jumping between headings, which is how they skim. That fails Info and Relationships at Level A [10] and Headings and Labels at Level AA [11]. Fixing it means changing the tag and moving the styling to CSS.
Form fields with no label. A placeholder is not a label. It vanishes when typing starts and is not treated the same way by assistive technology. WCAG asks for a visible label programmatically associated with its input, under Labels or Instructions [12] and Name, Role, Value [13], both Level A. This is the failure that most directly costs you enquiries, because it sits on the form.
Colour contrast below the threshold. Body text needs at least 4.5 to 1 against its background, or 3 to 1 for large text, under Contrast Minimum at Level AA [14]. Logos are exempt. The usual cause is light grey placeholder-looking text that a designer chose on a bright monitor. In a design system this is a token change.
No visible focus indicator. Every element that can take keyboard focus must show it, under Focus Visible at Level AA [15]. Developers remove the browser default outline because it clashes with the design, then forget to replace it. WCAG 2.2 added a companion criterion, Focus Not Obscured, requiring that the focused element is not entirely hidden behind a sticky header or overlay [16]. Both are CSS.
Keyboard traps. Focus can enter a modal or custom widget but cannot leave it with the keyboard alone. That is Level A [17], and it is the one genuinely severe item on this list, because it does not degrade the experience, it ends it. This can take real engineering if the component is homemade.
Video without captions. Captions Prerecorded is Level A [18], which is baseline rather than advanced. Captions are synchronised and include meaningful non-speech sound. A transcript is not a substitute. This one is production work rather than markup, which is why it costs more than the rest.
Five of those seven are corrections a competent developer makes in hours. That is the whole point. The expensive framing of accessibility as a redesign is usually wrong, and it is worth being sceptical of anyone who leads with it. Correct markup also happens to be what search crawlers read, so the same fixes support the structural work described in our guide to ranking on Google in the UAE. This is one discipline serving two audiences, not two projects.
Arabic, and the two attributes people forget
This is the area where UAE sites fail in a way generic advice never covers, and where official UAE guidance is silent.
The lang attribute tells assistive technology which language the page is in, under Language of Page at Level A [19]. Screen readers use it to select a pronunciation engine. Get it wrong and Arabic content is read with English phonetic rules, which does not sound accented. It sounds like nothing. An Arabic page still carrying lang="en" from the English template is a common and completely invisible defect.
Then Language of Parts, at Level AA, covers any passage in a different language from the page around it [20]. On UAE sites this is constant: an English brand name inside an Arabic sentence, a quoted English contract clause, a product code. Proper names and terms that have entered common usage are excepted, but genuine passages should be marked so the screen reader switches rules for that fragment.
The dir attribute is separate from language and controls direction only. W3C's guidance on bidirectional text covers what happens when Latin text, numbers or phone numbers sit inside an Arabic paragraph, where markup is needed to stop the browser reordering characters incorrectly [21].
Worth stating clearly: the National Policy for Digital Accessibility does not mention language attributes, direction, bidirectional text or screen reader language switching anywhere [1]. On the accessibility question most specific to this market, there is no UAE-specific rule to follow, so follow W3C's.
For the design and cost side of building Arabic properly, our RTL website design guide covers layout, typography, icon mirroring and budgets, and our multilingual website guide covers running more than one language well. This section is the accessibility layer those two do not include.
What a scanner can and cannot tell you
Run an automated checker. It is fast, it is free, and it finds real problems.
Then read what W3C says about what you are holding. Evaluation tools cannot determine accessibility and can only assist in doing so. Human judgement is required. Some checks cannot be automated. Tools sometimes produce false or misleading results [22].
We are not going to tell you what percentage of issues automation catches, because no authoritative body publishes one. Every figure in circulation traces back to a company that sells testing tools or testing services. That does not make it a lie. It makes it marketing, and this is a topic with enough marketing in it already.
What a human has to check: whether alt text describes anything useful rather than merely existing, whether a keyboard trap is genuinely escapable, whether captions match the audio, whether the reading order makes sense heard rather than seen, and whether the focus indicator survives every background it lands on. A scanner sees markup. It cannot see whether the result is usable. Our QA and testing guide treats accessibility as one pass inside a proper test plan rather than a separate exercise.
Accessibility overlay widgets deserve a sentence, because they will be offered to you. Their claims are contested and we are not going to pass on either side's marketing as fact. What is not contested is what an overlay does not do. It does not correct the markup in your source, so the missing labels and broken headings are all still there underneath. Fix the source, then decide whether you want anything on top.
The commercial case, without the invented statistics
You will see claims that accessible sites earn a specific percentage more. We are not repeating them. No W3C, UAE government or standards source we reviewed publishes a general figure of that shape. W3C's business case material offers one organisation's case study on traffic after adding transcripts, which is traffic rather than revenue, and one case study is not a rule [23].
The qualitative argument is strong enough on its own. W3C notes that many accessibility requirements improve usability for everyone, particularly in limiting situations, giving contrast in bright sunlight and captions in noisy environments as examples [24]. That is most of a UAE audience on a phone, outdoors, half the year.
Beyond that: the same markup serves search crawlers, the same discipline serves an ageing customer base, and accessibility increasingly turns up in enterprise and government procurement questions whether or not it is in your own legal obligations.
What this costs
No government body, regulator or standards organisation publishes rates for accessibility work, which is expected, since none of them sell it. The figures below are our own, based on what we quote. They are not a market survey.
An accessibility audit of an existing site starts from around AED 3,000. That covers a manual and automated pass across your core pages and flows against WCAG Level AA, and a prioritised report listing each failure, the specific success criterion it breaches, and a recommended fix.
Remediation is scoped separately, after the audit, deliberately. Quoting a fix before you know what is broken is guesswork, and the honest spread is too wide to be useful: missing labels and focus styles are hours, a video library needing captions is a different order of work.
For context against our other published figures. A focused QA test pass on an existing build starts from around AED 4,000 [25], and an accessibility audit is a narrower pass, which is why it sits below it. A website build starts from around AED 3,500 for a focused business site [26], and building accessibly from the start costs less than retrofitting. Arabic subtitles added to a finished video start from around AED 300 [27], which is the relevant number if captioning is part of your remediation. If the audit finds problems that are genuinely structural rather than markup, that is a redesign conversation rather than a remediation one, and we would tell you so. Final pricing depends on scope.
Real client stories
These are anonymised situations from projects we have worked on.
The redesign that turned out to be markup. A UAE services business was told by another party that their site needed rebuilding to be accessible, with a quote to match. We audited it first. The failures were an unlabelled contact form, section titles built as styled paragraphs rather than heading elements, body copy at roughly 3 to 1 contrast, and a removed focus outline. Four categories, all in the markup and stylesheet, none requiring a new design. The visual design was left exactly as it was.
The Arabic page that was reading in English. A bilingual site had a well-built right-to-left layout and looked correct. The Arabic pages were still serving lang="en" because the language attribute lived in a shared template nobody had parameterised. To a sighted visitor everything was fine. To a screen reader user the Arabic was being pronounced with English rules and was unusable. The fix was one template change, plus tagging the English brand names embedded in Arabic paragraphs.
The scan that passed and the keyboard that did not. A client had a clean automated report and assumed they were done. Tabbing through the site by hand, the cookie banner could be entered but not left with the keyboard, so no keyboard-only visitor ever reached the site behind it. The scanner had not flagged it. That one took real engineering rather than a markup fix, which is the honest exception to everything else in this article.
How SKIMBOX approaches accessibility
We start with an audit, because we would rather tell you what is actually broken than sell you a rebuild you may not need. We test manually as well as with tooling, we report against specific success criteria so you can check our work, and we separate the markup corrections from the structural items so you can see which is which before committing.
On the legal position we will tell you what we can confirm and what we cannot, which is what this article does. We do not give legal advice, and we would rather say the scope is unconfirmed than tell you the law requires something we could not verify.
An accessibility audit of an existing site starts from around AED 3,000. Remediation is scoped after the audit rather than before it. Those are our own figures, not a market survey. Final pricing depends on scope.
See our web development services and UX and UI design services, or contact us to talk through your site.
For related reading, see our guides on RTL website design for UAE brands and UI and UX design cost in Dubai.
References
[1] TDRA, UAE - National Policy for Digital Accessibility, issued March 2024. Scope, technical annex, and target beneficiaries. dgov.tdra.gov.ae/-/media/dgov/pdfs/publications/national-digital-accessibility-policy-en.pdf
[2] U.AE Official UAE Government Portal - National Digital Accessibility Policy summary. u.ae/en/about-the-uae/strategies-initiatives-and-awards/policies/government-services-and-digital-transformation/national-digital-accessibility-policy
[3] Government of Dubai Legislation Portal - Law No. 3 of 2022 Concerning the Rights of Persons with Disabilities in the Emirate of Dubai. dlp.dubai.gov.ae
[4] TDRA, UAE - Digital Accessibility Statement, citing WCAG 2.2 AA for the Authority's own platforms. tdra.gov.ae/en/Participation/digital-accessibility-statement
[5] TDRA Digital Government, UAE - UAE Design System for federal government websites. dgov.tdra.gov.ae/services/design-system-for-federal-governments-websites
[6] W3C Web Accessibility Initiative - What's New in WCAG 2.2. w3.org/WAI/standards-guidelines/wcag/new-in-22/
[7] W3C Web Accessibility Initiative - WCAG 2 Level AA Conformance. w3.org/WAI/WCAG2AA-Conformance
[8] W3C Web Accessibility Initiative - Understanding Conformance, WCAG 2.2. w3.org/WAI/WCAG22/Understanding/conformance
[9] W3C Web Accessibility Initiative - Understanding Success Criterion 1.1.1 Non-text Content. w3.org/WAI/WCAG21/Understanding/non-text-content.html
[10] W3C Web Accessibility Initiative - Understanding Success Criterion 1.3.1 Info and Relationships. w3.org/WAI/WCAG22/Understanding/info-and-relationships
[11] W3C Web Accessibility Initiative - Understanding Success Criterion 2.4.6 Headings and Labels. w3.org/WAI/WCAG21/Understanding/headings-and-labels.html
[12] W3C Web Accessibility Initiative - Understanding Success Criterion 3.3.2 Labels or Instructions. w3.org/WAI/WCAG21/Understanding/labels-or-instructions.html
[13] W3C Web Accessibility Initiative - Understanding Success Criterion 4.1.2 Name, Role, Value. w3.org/WAI/WCAG21/Understanding/name-role-value.html
[14] W3C Web Accessibility Initiative - Understanding Success Criterion 1.4.3 Contrast Minimum. w3.org/WAI/WCAG21/Understanding/contrast-minimum.html
[15] W3C Web Accessibility Initiative - Understanding Success Criterion 2.4.7 Focus Visible. w3.org/WAI/WCAG22/Understanding/focus-visible
[16] W3C Web Accessibility Initiative - Understanding Success Criterion 2.4.11 Focus Not Obscured Minimum. w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html
[17] W3C Web Accessibility Initiative - Understanding Success Criterion 2.1.2 No Keyboard Trap. w3.org/WAI/WCAG21/Understanding/no-keyboard-trap.html
[18] W3C Web Accessibility Initiative - Understanding Success Criterion 1.2.2 Captions Prerecorded. w3.org/WAI/WCAG22/Understanding/captions-prerecorded.html
[19] W3C Web Accessibility Initiative - Understanding Success Criterion 3.1.1 Language of Page. w3.org/WAI/WCAG22/Understanding/language-of-page.html
[20] W3C Web Accessibility Initiative - Understanding Success Criterion 3.1.2 Language of Parts. w3.org/WAI/WCAG22/Understanding/language-of-parts
[21] W3C Internationalization - Inline markup and bidirectional text in HTML. w3.org/International/articles/inline-bidi-markup/index.en.html
[22] W3C Web Accessibility Initiative - Selecting Web Accessibility Evaluation Tools. w3.org/WAI/test-evaluate/tools/selecting/
[23] W3C Web Accessibility Initiative - The Business Case for Digital Accessibility. w3.org/WAI/business-case/
[24] W3C Web Accessibility Initiative - Accessibility, Usability, and Inclusion. w3.org/WAI/fundamentals/accessibility-usability-inclusion/
[25] SKIMBOX - Software testing and QA services in Dubai, our own commercial figures. skimbox.co/resources/blogs/software-testing-qa-dubai
[26] SKIMBOX - Website development cost in Dubai, our own commercial figures. skimbox.co/resources/blogs/website-development-cost-dubai
[27] SKIMBOX - Arabic voiceover and subtitling in Dubai, our own commercial figures. skimbox.co/resources/blogs/arabic-voiceover-subtitling-dubai



