Updated September 30, 2026
Web accessibility in the UAE means building websites that people with disabilities can use to find information, operate controls, and complete tasks. A booking page may look clear yet fail when someone uses a keyboard or screen reader.
Accessibility belongs in requirements, development, and QA. It affects HTML structure, focus, forms, media, and interactive components, not just colors and alternative text.
Lucidly's Web Development Services in the UAE are a relevant starting point for planning these requirements alongside a website build.
This guide explains how to implement and test accessible websites using WCAG 2.2, including Arabic and English experiences and the UAE policy context.
Web Accessibility: The Practical Answer
Build accessibility into the task a user needs to complete: use semantic HTML, support keyboard operation, provide understandable labels and errors, and verify the full journey with assistive technology.
For UAE projects, separate two decisions:
Technical target: W3C recommends WCAG 2.2 for current accessibility work. Level AA includes the applicable Level A and AA requirements.
Applicable obligations: the UAE's National Digital Accessibility Policy references WCAG 2.1 AA for public service sites. Confirm the requirements that apply to the organization, service, sector, and contract.
A passing automated scan is a useful starting point. It does not establish that a person can complete a booking, checkout, or inquiry.
What WCAG 2.2 Means for Website Teams
WCAG 2.2 provides testable accessibility requirements organized around four principles: Perceivable, Operable, Understandable, and Robust, commonly summarized as POUR.
Perceivable: users must be able to receive the information.
Operable: users must be able to navigate and use the interface.
Understandable: content and interactions should be clear and predictable.
Robust: browsers and assistive technologies need reliable semantic information.
WCAG then translates these principles into individual success criteria that can be evaluated during design, development, and QA.
WCAG A, AA, and AAA
Level | Practical Meaning |
|---|---|
A | Foundational requirements that address major accessibility barriers. |
AA | Includes Level A plus additional requirements and is a common practical conformance target. |
AAA | Adds stricter requirements; do not assume every website can satisfy every AAA criterion. |
Claiming WCAG 2.2 AA does not mean selecting a few AA recommendations. The applicable Level A and Level AA success criteria must all be satisfied.
What WCAG 2.2 Added
WCAG 2.2 extends WCAG 2.1 and adds nine success criteria. Several are particularly relevant to everyday websites.
WCAG 2.2 Requirement | Level | Practical Impact |
|---|---|---|
Focus Not Obscured (Minimum) | AA | Keyboard focus cannot be completely hidden behind author-created content. |
Dragging Movements | AA | Drag-based functionality generally needs a simple pointer alternative where dragging is not essential. |
Target Size (Minimum) | AA | Pointer targets generally need sufficient size or spacing. |
Consistent Help | A | Repeated help mechanisms need predictable relative placement where the criterion applies. |
Redundant Entry | A | Previously supplied information generally should not need to be entered again within the same process where the criterion applies. |
Accessible Authentication (Minimum) | AA | Authentication should not depend solely on certain cognitive-function tests without an appropriate alternative or mechanism. |
For developers, this is an important distinction: modern accessibility requirements affect interaction behavior and application logic as well as presentation.
Plan Accessibility Before Development Starts
Accessibility is easier and less disruptive to implement when teams define testable requirements before building components and templates. Lucidly’s guide to How to Plan a Website explains how these decisions fit into the wider planning process. Instead of writing "Make the website accessible," define requirements such as:
The booking journey must be completable using a keyboard alone, with visible focus and no keyboard traps.
or:
Form validation must identify the field in error and explain how to correct it.
Before development starts, identify:
The WCAG version and target level.
Critical user journeys.
Interactive components requiring keyboard or focus behavior.
Forms, checkout, booking, login, or account flows.
Content and media responsibilities.
Accessibility testing responsibilities.
Acceptance criteria before launch.
For a Dubai-based project, Lucidly’s Web Development Services in Dubai can help define accessibility requirements alongside the scope, components, and launch criteria.
Define Critical Journeys
Identify the flows that matter most: contact, booking, login, checkout, search, and language switching. Give each an acceptance criterion covering completion, error recovery, and confirmation. This sets the scope for the journey testing described below.
Start With Semantic HTML
Semantic HTML is the foundation of accessible front-end development because native elements communicate meaning and expected behavior to browsers and assistive technologies. Use native elements when they already provide the required purpose:
<button> for actions.
<a> for navigation.
<input>, <select>, and <textarea> for form controls.
<label> for identifying form fields.
<nav> for navigation regions.
<main> for primary page content.
Heading elements for document hierarchy.
Lists when content is logically a list.
A button should normally be a real button rather than a generic element styled to look like one.
Build a Logical Heading Structure
Headings should represent content relationships rather than visual size. Use H1 for the main page topic, H2 for main sections, and H3 for subsections within them. CSS should control appearance; HTML should communicate structure.
Give Controls Understandable Names
A control needs an accessible name that explains its purpose. An icon-only close control, for example, should communicate "Close" rather than leaving assistive technology with an unnamed button or only a description of how the icon looks. Users should be able to understand what a control does without depending only on its visual appearance. For the broader interaction and navigation decisions behind this work, see UX And UI Design For Websites.
Build for Keyboard Access and Predictable Focus
Important functionality must be reachable and operable without a mouse. Check that users can move forward and backward using Tab and Shift + Tab, see where focus is, operate controls with expected keys, and leave every interactive component.
Keep Focus Visible
Do not remove the browser's focus indicator without providing an effective alternative. Under WCAG 2.2 Level AA, a component receiving keyboard focus must not be entirely hidden by author-created content. Check sticky headers, banners, fixed footers, and chat widgets.
Avoid Keyboard Traps
A dialog must allow users to enter, operate its controls, close it, and return focus appropriately. If focus enters a component but cannot leave using the keyboard, the component is a trap. A quick check: can I reach it, identify focus, operate it, and leave it without a mouse?
Build Accessible Forms Around the Task
An accessible form provides clear labels, instructions, understandable validation, and a way to recover from errors without relying on visual cues alone.
Label the Control, Not Just the Placeholder
A field should expose a clear purpose such as "Email Address" rather than depending only on "Enter email here." Placeholder text can provide additional guidance, but it should not normally replace the field's label.
Explain Requirements Before Errors Occur
If a field requires a particular format, tell users before submission. Typical examples include password rules, file restrictions, required fields, date formats, and special validation requirements.
Make Errors Actionable
Avoid "Invalid input." Prefer "Enter an email address in the format name@example.com." Errors should identify what needs attention and explain what should change. Do not rely on a red border alone; users must be able to understand the error without distinguishing the color.
Avoid Unnecessary Re-entry
WCAG 2.2's Redundant Entry criterion addresses situations where information already provided during the same process is requested again. Where the criterion applies, that information should generally be populated or available for selection rather than forcing the user to type it again.
Make Images and Media Understandable
Accessible media preserves important information when someone cannot perceive its visual or audio presentation.
Write Alt Text Around Purpose
Ask what readers would miss if an image were unavailable, and describe that information rather than every visible object. Avoid generic text and keyword stuffing. Decorative images can usually use an empty alternative. A functional icon needs an accessible name describing its action, such as "Search" rather than "Magnifying glass."
Provide Alternatives for Complex Media
Put the important data or conclusions of charts and infographics in nearby text or another accessible format. Speech in video may need captions, while audio and important visual-only information may need other alternatives depending on the content.
Design for Contrast, Reflow, and Usable Targets
Visual accessibility means information and controls remain understandable when users have difficulty perceiving color, small details, or tightly spaced elements.
Do Not Use Color Alone
Color can reinforce meaning, but it should not be the only way users identify errors, selected states, required fields, chart categories, or status information.
Use Measurable Visual Checks
Test the actual interface, including labels, errors, buttons, and interactive states. These checks provide concrete acceptance criteria.
Check | Acceptance Target | How to Verify |
|---|---|---|
Text contrast | At least 4.5:1 for normal text and 3:1 for large text, subject to WCAG exceptions | Measure foreground and background colors with a contrast checker |
Text resizing | Text can be enlarged to 200% without losing content or functionality, except where WCAG permits exceptions | Enlarge text and check labels, controls, navigation, and forms |
Reflow | Ordinary vertically scrolling content remains usable at 320 CSS pixels wide without horizontal scrolling | Use browser responsive mode and complete a task at that width; content requiring a two-dimensional layout has exceptions |
For contrast testing, large text means at least 18 pt, or 14 pt when bold. Text resizing and reflow are separate checks: passing one does not establish the other.
Pointer Targets Need Enough Space
WCAG 2.2's Target Size (Minimum) criterion uses a baseline of 24 × 24 CSS pixels, with defined exceptions and spacing provisions. This matters particularly for small icon buttons, pagination, carousel controls, mobile menus, filters, and close buttons. The goal is to let users activate the intended control without repeatedly hitting its neighbor.
Account for Dragging, Motion, and Dynamic Content
Interactive content must remain usable when users cannot perform precise gestures or perceive visual-only state changes.
Do Not Make Dragging the Only Option
If users reorder an item by dragging, provide controls such as "Move Up" and "Move Down." WCAG 2.2 requires a single-pointer alternative for drag-based functionality where dragging itself is not essential.
Communicate Dynamic Updates
Modern websites update form errors, booking availability, cart totals, search suggestions, loading states, success confirmations, and filters. Important updates need to be communicated programmatically where required, not shown only as temporary visual changes.
Keep Interaction Predictable
Selecting an option should not unexpectedly submit a form, navigate elsewhere, move keyboard focus, or open a new context, unless that behavior is expected or communicated.
Respect Motion Preferences
Animations and movement should not be essential to understanding or operating the website. Where appropriate, respect user preferences such as prefers-reduced-motion rather than requiring everyone to experience substantial decorative movement.
Use ARIA to Fill Semantic Gaps, Not Replace HTML
ARIA adds roles, states, and properties when native HTML cannot fully describe a custom component. It does not make the component accessible by itself. It may help with dialogs, tabs, accordions, live regions, and other dynamic widgets.
Adding role="button" to a generic element does not give it the keyboard behavior of a real <button>. Developers must still implement the correct name, interaction, state, and focus behavior. Use native HTML first; add ARIA for a genuine gap.
Accessibility Implementation and QA Matrix
Connect each requirement with a likely failure and a way to verify the fix.
Area | Build It This Way | Common Failure | How to Verify |
|---|---|---|---|
Structure | Semantic headings and landmarks | Styled text replaces headings | Inspect and navigate page structure |
Keyboard | Operable controls and logical order | Mouse-only menu | Complete a workflow with the keyboard |
Focus | Visible and predictable focus | Focus disappears or stays behind a dialog | Tab through each component state |
Forms | Labels, instructions, useful errors | Placeholder-only field or color-only error | Submit the form with invalid input |
Images | Alternatives based on purpose | Generic or unnecessary alt text | Compare image purpose with its alternative |
Visual UI | Contrast, reflow, secondary cues | Meaning depends on color or zoom breaks layout | Test contrast and enlarged layouts |
Dynamic UI | Communicate relevant state changes | Visual update only | Trigger updates with assistive technology |
Custom components | Native semantics or complete ARIA behavior | Role added without keyboard support | Test semantics, state, focus, and keyboard |
Planning a website or reviewing an existing one? Talk to Lucidly about development and accessibility QA for your priority journeys. Message Us on WhatsApp.
How to Test Website Accessibility Properly
Combine automated checks, manual interaction, assistive-technology testing, and complete user journeys. W3C's Evaluation Tools Overview explains why tools support a broader review rather than establish conformance by themselves.
1. Start With a Small Testing Toolkit
Choose tools for different questions, rather than treating their scores as interchangeable.
Tool or Method | Use It For | What Still Needs Checking |
|---|---|---|
Run an accessibility audit in Chrome DevTools and inspect the reported elements | Manual audits are excluded from the score; a high score does not establish conformance | |
Review flagged errors and page structure in the context of the page | Whether alternatives are meaningful and interactions work | |
NVDA on Windows | Test how headings, controls, forms, and updates are presented by a screen reader | Other relevant browser, device, and assistive-technology combinations |
Keyboard and browser zoom | Check focus, operation, enlarged text, and responsive states | Screen-reader output and other criteria outside these checks |
Run automated checks on representative templates and important component states. Inspect each finding, fix its underlying cause, and rerun the relevant check. A scanner cannot reliably decide whether a label explains the right task.
2. Test Interactions Manually
Set the mouse aside and navigate with Tab and Shift + Tab. Check menus, dialogs, validation, and error recovery. Focus should follow a meaningful sequence, remain visible, and allow users to leave each component. Test resizing and reflow separately using the acceptance targets above.
3. Check With Assistive Technology
Use a screen reader to check headings, landmarks, control names, labels, invalid states, and dynamic updates. Confirm that it communicates the correct purpose and state, not merely that it announces something. Include every language version in the test scope.
4. Complete a Real Journey
Test a path such as Service → Booking → Details → Confirmation. Complete it using the keyboard, trigger an error, correct it, and confirm success. Repeat with a screen reader on relevant devices. Record the page or component, reproduction steps, expected behavior, observed result, and applicable WCAG criterion so another team member can verify the repair.
Project Example: Testing a Patient Inquiry Journey
In Lucidly's Magrabi Health Case Study, clear navigation and patient journeys were central to the website work for the brand's eye and ENT services. Accessibility testing brought those priorities down to a practical question: could a patient find a service, reach the inquiry form, correct an error, and submit successfully without using a mouse?
The team checked keyboard navigation, visible focus, field labels, and validation messages across the Arabic and English experiences. Screen-reader checks verified whether users could identify each field, understand correction guidance, and recognize the submission confirmation.
Barriers found during testing were corrected, and the affected journeys were tested again. This connected accessibility QA to a complete patient task rather than treating individual component checks as sufficient. The case study's Accessibility & QA section describes this work in more detail.
Accessibility Debugging Example: A Modal That Looks Fine but Fails
This hypothetical example shows how to connect a problem to evidence, cause, repair, and verification. It illustrates the behavior described in W3C's Modal Dialog Pattern.
Visible Symptom
A keyboard user opens a booking modal, but pressing Tab moves to links behind it.
Evidence
Reproduce it: Tab to the booking button, open the modal, and continue tabbing. Focus leaves the active dialog.
Likely Cause
The component was implemented visually without correct focus handling.
Fix
Give the dialog an accessible name and appropriate modal semantics. Move focus to a suitable element inside it when it opens, keep Tab and Shift + Tab within the active dialog, and prevent interaction with the background. Support Escape and a visible close button. On closing, return focus to the opening button unless the workflow requires another logical destination.
Verify
Open the dialog using the keyboard. Confirm that focus enters it, remains visible, and cycles through its controls without reaching background links. Close it with Escape, then repeat using the close button. Check that focus returns appropriately and background interaction is restored. Setting aria-modal="true" alone does not implement this behavior.
The same diagnostic pattern can be used for menus, filters, forms, tabs, and other interactive components.
Accessibility QA Before Launch
Review shared components first, representative templates next, and priority journeys last. Include the homepage, service, article, and contact templates, plus any account or ecommerce templates in use. Use a release record that makes unresolved issues visible:
Release Check | Evidence to Record |
|---|---|
Shared navigation, forms, and dialogs reviewed | Component states tested and findings |
Representative templates reviewed | URLs, languages, and viewport conditions |
Priority journeys completed | Keyboard and screen-reader results, including error recovery |
Repairs verified | Original issue reproduced and retested; related states checked |
Outstanding issues assigned | User impact, owner, next action, and retest status |
Prioritize barriers that prevent task completion. This record supports release decisions; it does not replace evaluation of all applicable success criteria.
What Web Accessibility Means for UAE Websites
Accessibility for UAE websites combines international technical standards with local requirements such as Arabic and English content, right-to-left interfaces, service journeys, and the UAE's digital-accessibility policy framework.
The UAE's official National Digital Accessibility Policy aims to improve access to digital services for People of Determination and senior citizens. Its stated scope includes federal government entities and also addresses semi-government organizations, service providers, contractors, and private-sector participation within the policy framework.
The policy's technical annex states that public service websites must comply with WCAG 2.1 Level AA. Meanwhile, the UAE Government's accessibility statement says its own digital platform is designed to meet WCAG 2.1 and WCAG 2.2 Level AA as a minimum.
For private organizations, this should not be simplified into a blanket statement that every UAE commercial website has the same legal WCAG obligation. Applicable requirements can depend on the organization, service, sector, contract, procurement conditions, and relevant authority. For a new technical implementation, WCAG 2.2 provides the current W3C conformance target, while project-specific obligations should still be confirmed separately.
Test Arabic and English Independently
A bilingual website needs testing in both languages. Start Arabic pages with the appropriate document language and direction, for example <html lang="ar" dir="rtl">. Language and direction are separate attributes; one does not establish the other. W3C's RTL Markup Guidance explains their use.
Check mixed Arabic and English content, phone numbers, directional icons, reading and focus order, and translated labels and errors. Repeat at narrow widths and increased zoom, where longer text can expose clipping or overlap.
Example: An Arabic Form Error That Is Visible but Not Associated With Its Field
Consider a hypothetical Arabic booking form that displays an error beside the phone field after submission.
Symptom: The error is visible, but a screen reader user returning to the field cannot identify what needs correcting.
Evidence: Inspect the field in DevTools. In this example, the error message has an ID, but the input does not reference it through aria-describedby. Screen-reader testing confirms that the error is not presented when the field receives focus.
Fix: Following W3C's Form Error Notification Guidance, associate the error with the input using aria-describedby and set aria-invalid="true" while the value is invalid. Preserve any existing description references. After submission, provide an accessible notification and a clear route to the affected field. A simplified pattern looks like this (shown with English text; the Arabic page uses the same structure with translated content):
<label for="phone">Phone number</label>
<input id="phone" type="tel"
aria-invalid="true"
aria-describedby="phone-error">
<p id="phone-error">Enter a phone number using digits only.</p>
Verify: Submit invalid information using the keyboard, reach the field, and confirm that its label, invalid state, and correction guidance are understandable. Correct the value and check that the invalid state and outdated error are removed. Repeat in English.
Keep Help Predictable
Repeated phone, live-chat, and human-contact mechanisms should retain a consistent relative order across the page sets covered by WCAG 2.2's Consistent Help criterion. A WhatsApp support link can be relevant here; not every FAQ link automatically qualifies as a help mechanism under this criterion. Also test whether fixed support widgets cover focused controls or form errors. Their presence should help users complete a task without creating a new barrier.
Accessibility Does Not End at Launch
New content, forms, third-party widgets, language versions, and component updates can introduce barriers after launch. Include automated checks during development, manual QA for new functionality, periodic tests of priority journeys, and guidance for content editors. Retest after redesigns or migrations.
For broader post-launch planning, see Website Maintenance and Support in the UAE. If defects are embedded in older templates or architecture, the Website Redesign Strategy can help frame remediation alongside migration and technical QA.
Frequently Asked Questions
What is the difference between WCAG 2.1 and WCAG 2.2?
WCAG 2.2 builds on WCAG 2.1 and adds new accessibility requirements rather than introducing a completely different framework. The additions cover keyboard focus, dragging, target size, consistent help, redundant entry, and accessible authentication. W3C recommends WCAG 2.2 as the current conformance target.
Should UAE websites target WCAG 2.2 AA?
WCAG 2.2 AA is a strong current technical target for new projects, but the standard a particular UAE organization must meet depends on its applicable policy, regulatory, contractual, procurement, or sector requirements. The UAE policy technical guidance references WCAG 2.1 AA for public service websites, while current UAE Government platforms also implement WCAG 2.2 AA.
Can an automated accessibility tool confirm WCAG conformance?
No. Automated testing can identify many issues, but a complete evaluation requires checks that depend on human judgment and manual interaction. Automated tools should support manual and assistive-technology testing, not replace them.
Does every image need written alt text?
No. Informative images generally need an appropriate text alternative, while purely decorative images can often use an empty alternative so assistive technologies ignore them. The correct treatment depends on the image's purpose.
Is ARIA required for an accessible website?
No. Native semantic HTML can provide much of the required accessibility without ARIA. ARIA is most useful when a custom component needs semantics or states that native HTML does not provide sufficiently.
Can an existing website be made accessible without a complete rebuild?
Often, yes. Issues involving headings, labels, contrast, focus, keyboard behavior, content, and individual components can frequently be repaired within an existing website. A larger rebuild becomes more relevant when problems are deeply embedded in legacy templates, architecture, third-party systems, or reusable components that cannot be corrected cleanly.
Build Accessibility Into the Development Process
Start with the journeys people need to complete, define testable requirements, and verify repairs against the original failure. For UAE websites, include Arabic and English, responsive states, and the requirements that apply to the organization.
Ready to plan or review your website? Message Lucidly on WhatsApp or visit our Contact Us page with your website and priority journeys to discuss development and accessibility QA.