Web Development

Web Accessibility and WCAG in the UAE: What Is Actually Required and What It Costs to Fix

SKIMBOX Team

Most accessibility failures are not expensive design problems. They are markup mistakes. Here is what UAE policy actually binds, which WCAG version to aim at, and what an audit of an existing site costs. Ours start from around AED 3,000.

Web Accessibility and WCAG in the UAE: What Is Actually Required and What It Costs to Fix

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

Frequently asked questions

  • Is web accessibility a legal requirement for a private business in the UAE?

    We could not confirm that it is. The National Policy for Digital Accessibility binds federal government entities and the private companies that transact digitally with them. For the wider private sector it says entities should take the policy into account and exert best efforts, which is encouragement rather than obligation. We are not saying no requirement exists anywhere, because two relevant laws were not available to read during our research. If you work in a regulated sector, confirm with your regulator.

  • What is the UAE National Policy for Digital Accessibility?

    It is the UAE's central digital accessibility document, issued by the Telecommunications and Digital Government Regulatory Authority in March 2024 and published on the official government portal. It sets out who must make digital services accessible, names WCAG conformance targets, defines a Digital Accessibility Officer role, and lists technical guidelines in an annex. Its named beneficiaries are People of Determination and Senior Citizenry, which the policy defines as persons aged 60 or older.

  • Who exactly does the UAE policy bind?

    Its scope article lists federal government ministries, authorities and institutions; semi-government entities, consultants, institutions and private companies engaged in digital transactions with a government entity; partners, contractors and outsourced staff involved in those transactions; and service providers developing websites and systems for federal entities. The technical annex adds that all public service sites must comply with Level AA. Everyone else in the private sector is encouraged, not required.

  • What does WCAG stand for and who publishes it?

    Web Content Accessibility Guidelines. It is published by the World Wide Web Consortium through its Web Accessibility Initiative. It is the technical reference that most accessibility policy around the world points at, including the UAE's own policy. It is organised into four principles, then into individual success criteria, and each criterion carries a conformance level of A, AA or AAA so you can tell what is baseline and what is advanced.

  • Is WCAG itself a law?

    No. WCAG is a technical standard, not legislation. It carries no penalty on its own. Laws and government policies acquire teeth by referencing it, which is what the UAE's National Policy for Digital Accessibility does for the entities it covers. So the correct question is never whether WCAG is law. It is whether any rule that binds you, whether a policy, a regulator or a client contract, points at WCAG.

  • Which WCAG version does the UAE require?

    Official UAE sources do not agree. The founding National Policy for Digital Accessibility names WCAG 2.1 Level AA three separate times. TDRA's own digital accessibility statement for its own platforms cites WCAG 2.2 AA. The UAE Design System page references WCAG 2.0 in one place and WCAG 2.2 in another. All three cluster on Level AA. The version number is the part that is unsettled across the official documents.

  • Should I target WCAG 2.1 AA or 2.2 AA?

    Target the most recent version unless a contract or tender names a specific one, in which case use the version named. The newer version is additive rather than competing. WCAG 2.2 added nine success criteria on top of WCAG 2.1 and is backward compatible, so content that conforms to 2.2 also conforms to 2.1 at the same level. Aiming at the newer one costs you very little extra and covers both.

  • What is the difference between WCAG Level A, AA and AAA?

    Level A is the minimum. Failing it usually creates a hard barrier that stops some people from using the page at all. Level AA is the level most organisations aim at and the level named in UAE government policy and in most international rules. Level AAA is the highest bar. W3C notes that it is not possible to satisfy all Level AAA criteria for some content, so it is not a sensible site-wide target.

  • Why is AA the normal commercial target?

    Three reasons. It is the level the UAE's own policy names. It is the level referenced across most accessibility policy internationally. And W3C itself describes it as the level many organisations strive to meet, while cautioning against requiring AAA everywhere. AA removes the barriers that actually stop people using a site, without demanding content changes that some material genuinely cannot support. It is the pragmatic bar, not a compromise.

  • What are the four principles behind WCAG?

    The guidelines are grouped under four ideas. Can people perceive the content, including when they cannot see or hear it. Can they operate the interface, including with a keyboard alone. Can they understand the language and predict how the page behaves. And does the content work reliably with assistive technology such as screen readers, rather than only in one browser. Every individual success criterion sits under one of those four.

  • What is the single most common accessibility mistake on a website?

    Two compete. Missing or meaningless image alternatives, which is Success Criterion 1.1.1 at Level A. And headings that are only bold, larger text rather than real heading elements, which fails Info and Relationships at Level A and Headings and Labels at Level AA. Both are extremely common, both are invisible to a sighted mouse user, and both are usually fixed by correcting markup rather than by redesigning anything.

  • Do decorative images need alt text?

    No. The criterion asks for a text alternative that serves an equivalent purpose, and a purely decorative image has no informational purpose to serve. Those should be marked so assistive technology skips them, normally with an empty alt attribute. The mistake in both directions is common. Meaningful images get no alternative, and decorative flourishes get described out loud, which turns a page into noise for a screen reader user.

  • What colour contrast ratio does my text need?

    At least 4.5 to 1 against its background for normal text, and 3 to 1 for large text. That is Success Criterion 1.4.3, Contrast Minimum, at Level AA. The stated intent is that text stays readable for people with moderately low vision. Logos and brand marks are exempt. Light grey body copy on white is the usual offender, and it is normally a token change in the design system rather than a redesign.

  • Do form fields need labels if there is already a placeholder?

    Yes. A placeholder disappears as soon as someone starts typing, which leaves anyone who is distracted or uses memory support with no way to check what the field was for. It is also not treated the same way as a real label by assistive technology. WCAG asks for a visible label that is programmatically associated with its input, under Labels or Instructions and Name, Role, Value, both at Level A.

  • What is a keyboard trap and why does it matter so much?

    It is when keyboard focus can move into a component, such as a modal, a dropdown or a custom widget, but cannot move back out with the keyboard alone. It is Success Criterion 2.1.2 at Level A. It matters more than most failures because it does not degrade the experience, it ends it. A keyboard-only user is stuck and the rest of the page becomes unreachable until they reload.

  • Why does my site need a visible focus indicator?

    Because it does for a keyboard user what the cursor does for a mouse user. It shows where you are. Success Criterion 2.4.7, Focus Visible, at Level AA, requires that any element able to receive keyboard focus shows a visible indicator. Developers frequently remove the browser default outline because it clashes with a design, then never replace it. That is one CSS rule to fix, not a redesign.

  • What did WCAG 2.2 add about focus indicators?

    Success Criterion 2.4.11, Focus Not Obscured Minimum, at Level AA. It requires that the focused element is not entirely hidden by other content. The usual cause is a sticky header, a floating chat bubble or a cookie banner sitting over the element that currently has focus, so the indicator technically exists but nobody can see it. In most cases it is a z-index and scroll-offset correction in CSS.

  • Do headings really matter for accessibility?

    Yes, and more than people expect. Screen reader users navigate by jumping between headings the way a sighted reader skims a page. If the headings are only styled text, that navigation does not exist and the page has to be read from the top every time. Correct heading elements in a logical order also happen to be what search crawlers use to understand a page, so one fix serves both.

  • Does my video need captions, or is a transcript enough?

    Captions specifically. Success Criterion 1.2.2, Captions Prerecorded, sits at Level A, which is the baseline tier. Captions are synchronised with the video and carry dialogue plus meaningful non-speech sound. A transcript is a separate document that is not synchronised to what is on screen, so it does not satisfy that criterion on its own. Transcripts are useful and worth having, but they are an addition rather than a substitute.

  • Does the UAE policy require video captions?

    No. We read the full policy document and the words caption and subtitle do not appear anywhere in it. Video is addressed through two other routes instead: a requirement for how-to instructional videos, and a separate requirement for text to sign language translation. That is a genuine gap between the UAE policy and WCAG itself, which treats captions as a Level A requirement rather than an advanced one.

  • Does the UAE policy require sign language support?

    For the entities it binds, yes. The policy's technical annex lists text to sign language translation as a required feature, aimed at users with hearing impairments. It is listed as its own item, separately from the general accessibility guidance, and it is not the same thing as captioning. Note that this is an obligation on entities within the policy's scope, not a general requirement on every private website in the country.

  • What is a text reader feature and does UAE policy require it?

    It is an on-page text-to-speech tool, usually triggered by a Listen link, that reads page content aloud without the visitor needing their own screen reader installed. The policy's technical annex requires it for entities in scope. It goes beyond baseline WCAG, which assumes a user brings their own assistive technology. It is worth knowing about if you build for a government entity, because a WCAG audit alone will not flag its absence.

  • Is adding dir="rtl" enough to make an Arabic site accessible?

    No, and it is not enough for design either. The dir attribute sets text and layout direction. It says nothing about which language the content is in. Screen readers rely on the lang attribute for that, under Success Criterion 3.1.1 at Level A, to pick the right pronunciation rules. Get lang wrong and Arabic can be spoken with English phonetics, which is not merely accented. It is unusable.

  • What happens if my Arabic page has English brand names or numbers mixed in?

    Any passage in a language different from the page's main language should be marked up so assistive technology switches pronunciation rules for that fragment. That is Success Criterion 3.1.2, Language of Parts, at Level AA. Proper names and terms that have entered common usage are excepted. Mixed-direction text also needs correct markup so the browser does not reorder characters around an embedded Latin phrase or phone number.

  • Does UAE policy say anything specific about Arabic or right-to-left accessibility?

    Not that we could find. The National Policy for Digital Accessibility does not mention the lang or dir attributes, bidirectional text, or screen reader language switching anywhere in its text. It covers text reader features and understandable content in general terms only. So on the single accessibility question most specific to this market, the guidance to follow is W3C's, because there is no UAE-specific rule to follow instead.

  • If an automated scanner passes my site, is it accessible?

    No. W3C states plainly that evaluation tools cannot determine accessibility and can only assist in doing so, that human judgement is required, and that tools sometimes produce false or misleading results. A clean scan tells you that a subset of mechanically detectable problems was not detected. It cannot tell you whether your alt text describes anything useful, whether a caption matches the audio, or whether the page makes sense end to end.

  • What percentage of accessibility issues do automated tools catch?

    We are not going to give you a number, because no authoritative one exists. W3C does not publish a figure. Neither does any UAE government source we checked. Every percentage circulating publicly traces back to a company selling testing tools or testing services, which makes it marketing rather than a measurement. The honest statement is the qualitative one: automation assists, it does not determine conformance, and manual checking is not optional.

  • What can only manual testing find?

    Anything that requires judgement. Whether alt text actually describes the image rather than merely existing. Whether a keyboard trap is genuinely escapable. Whether captions match what is being said. Whether the reading order makes sense to somebody hearing the page rather than seeing it. Whether the focus indicator is visible against every background it lands on. A scanner sees markup. It does not see whether the result is usable.

  • Do accessibility overlay widgets fix the problem?

    Overlay tools are contested, and we will not pass on either their vendors' claims or their critics' claims as fact. No W3C, UAE government or standards source we reviewed endorses them. What we can say without controversy is what an overlay does not do: it does not correct the underlying markup, so the alt text, labels and heading structure in your source stay wrong. Fix the source first, then decide.

  • Does fixing accessibility help my SEO?

    There is real overlap, by mechanism rather than by a marketing statistic. Descriptive alt text, real heading elements in a logical order, properly labelled form controls and semantic structure are the same markup that search crawlers parse. Two audiences, assistive technology and search engines, both need machine-readable structure. So accessibility remediation is usually not a separate project from technical SEO. It is the same work counted twice.

  • Is it true that accessible websites make more money?

    We will not repeat that claim. No W3C, UAE government or standards source we reviewed publishes a general statistic of that shape, and the versions circulating tend to come from companies selling accessibility products. W3C's business case material offers one organisation's case study about traffic after adding transcripts, which is not revenue and not a general rule. The commercial argument for accessibility is sound qualitatively. It does not need an invented number.

  • How much does an accessibility audit cost in Dubai?

    An accessibility audit of an existing site starts from around AED 3,000 with us. That covers a manual and automated pass across your core pages and flows against WCAG Level AA, with a prioritised list of failures, the specific success criterion each one breaches, and a recommended fix for each. No official body publishes rates for this work, so that is our own figure rather than a market survey. Final pricing depends on scope.

  • What does it cost to fix the issues once the audit finds them?

    We scope remediation separately, after the audit, because quoting a fix before you know the faults is guesswork. The spread is genuinely wide. Missing labels, broken heading structure, absent focus styles and contrast token changes are hours of work. Captioning a video library, rewriting content for clarity or rebuilding a custom component that traps keyboard focus are days or weeks. The audit is what turns that range into a number.

  • Is accessibility work more expensive for a bilingual Arabic and English site?

    Somewhat, because most checks run twice. Labels need to be correct in both languages, headings need real markup in both, and the lang and dir handling has to be verified on each version including mixed-language passages. It compounds with your existing Arabic build rather than being a separate cost track. If the Arabic version was built as a translated copy rather than a proper right-to-left build, expect more.

  • What is the fastest first check if I think my site has problems?

    Five things, in this order. Do meaningful images have useful alternatives. Are headings real heading elements in a logical order rather than styled text. Can you tab through the whole page and back out of every menu and modal using only the keyboard. Is the focus indicator visible at every stop. Does body text pass a 4.5 to 1 contrast check. Those five cover most of what audits find.

  • Who does UAE policy say digital accessibility is actually for?

    Two named groups. People of Determination, which is the UAE's official term, defined in the policy as anyone with a permanent or temporary, total or partial impairment that limits meeting ordinary requirements because of environmental or behavioural barriers. And Senior Citizenry, which the policy defines as persons aged 60 or older. The second group is named explicitly throughout rather than implied, which is worth noting when you are deciding who your site is for.

SKIMBOX Team

Tech Consultancy

Get fresh writing in your inbox

One email a fortnight. No filler.

By subscribing, you agree to our privacy policy.

Want us to build something?

We work with teams across MENA, UK, USA, and India to build products, run programs, and grow.

Get in touch

Continue reading