If you are building a public website, customer portal or SaaS product in the UAE, accessibility needs to be part of engineering rather than a plugin installed before launch. This UAE WCAG 2.2 website accessibility checklist explains the practical checks I would use before releasing a production interface: semantic HTML, keyboard access, focus behaviour, forms, authentication, mobile targets, bilingual layouts and real assistive-technology testing.
The UAE National Digital Accessibility Policy is aimed at making digital products easier to use for people of determination and older people. The current UAE Design System front-end guidance tells government teams to follow WCAG 2.2 Level AA, use semantic markup, support keyboard navigation and test with screen readers. The official UAE portal also states that it follows WCAG 2.1 and 2.2 Level AA as a minimum.
For a private company, the exact legal or contractual obligation depends on its sector, customers and procurement requirements. I treat WCAG 2.2 AA as a strong engineering target, not as a certificate I can declare after running one automated scan. This article is technical guidance, not legal advice.
What UAE WCAG 2.2 accessibility means in practice
WCAG is organised around four ideas: content must be perceivable, operable, understandable and robust. Those words become useful only when they are connected to real user journeys. A customer must be able to find a service, understand the page, complete a form, recover from an error and confirm the result without depending on a mouse, perfect vision or one specific device.
The W3C WCAG 2.2 specification builds on WCAG 2.1 and adds criteria that are especially relevant to modern SaaS interfaces. At Level AA these include keeping keyboard focus from being hidden, providing alternatives to dragging, maintaining minimum target sizes and avoiding authentication steps that depend only on memory or puzzle solving.
The UAE guidance also makes an important point: adding an accessibility widget does not make the underlying front end accessible. A toolbar cannot repair an unlabeled form, a modal that traps the keyboard incorrectly, a chart with no text alternative or a checkout button that disappears at 200% zoom. The component itself has to work.
UAE WCAG 2.2 website accessibility checklist
1. Start with semantic HTML and a predictable page structure
Use real headings, navigation landmarks, lists, buttons and form controls before adding ARIA. Each page needs one clear H1 followed by a logical H2 and H3 hierarchy. A screen-reader user should be able to jump between the header, navigation, main content and footer without listening to the whole page.
A common front-end mistake is turning a styled div into a button. It may respond to a mouse click but provide no keyboard behaviour, role or accessible name. A native button already supplies those behaviours and is easier to maintain across React, Next.js, Angular and plain HTML.
2. Complete every important journey with a keyboard
Disconnect the mouse and test the navigation, menus, filters, modal dialogs, pricing tabs, forms and checkout flow using Tab, Shift+Tab, Enter, Space and Escape. Focus order should follow the visual and reading order. There should be no keyboard traps, and focus should return to a sensible place when a dialog closes.
Sticky headers, cookie notices and chat widgets can cover the active element. WCAG 2.2 adds a Level AA requirement for focus not to be entirely hidden by author-created content. I check this on desktop and mobile-sized viewports, not only in a wide browser.
3. Make focus visible and touch targets usable
Do not remove the browser outline unless you replace it with an equally clear focus style. The indicator needs enough contrast against light and dark states. Test focus on cards, icon buttons and controls inside menus, because those are where custom CSS often hides it.
WCAG 2.2 Level AA introduces a minimum target-size criterion of 24 by 24 CSS pixels, with defined exceptions. In production design I usually aim for larger controls where the layout allows it, especially for mobile navigation, pagination, close buttons and compact dashboard actions.
4. Give forms real labels, instructions and recoverable errors
Placeholder text is not a label. Associate every input with a visible label and connect supporting help or error text through aria-describedby when needed. Required status should be communicated in text and programmatically, not by colour alone.
When submission fails, move focus to an error summary or announce the result with a polite live region. Preserve the values the user already entered. For payment, legal or destructive actions, provide a review or confirmation step so the user can correct a mistake.
<label for="email">Work email</label>
<input id="email" name="email" type="email"
autocomplete="email" aria-describedby="email-error">
<p id="email-error" role="alert">
Enter an email address such as name@company.ae.
</p>In a React or Angular component, render the message only when an error exists, but keep the association and focus-management logic predictable. Do not announce validation on every keystroke unless the feedback genuinely helps.
5. Design accessible authentication
Login flows deserve their own review. Allow password managers and paste. Provide a reveal-password control with an accessible name. Avoid puzzles or memory tests unless an accessible alternative exists. If the product uses one-time codes, label the fields clearly, support autofill where possible and give users enough time to complete the process.
This matters for UAE PASS integrations as well as local authentication. External identity verifies a person, but your application still owns the usability of the redirect, callback errors, account linking and recovery screens.
6. Test Arabic, English and right-to-left layouts
Accessibility and internationalisation overlap. Set the correct page language and mark isolated phrases when the language changes. For Arabic, use proper right-to-left layout rather than visually reversing individual components. Check reading order, icon direction, form alignment, validation messages and mixed Arabic-English values such as email addresses or reference numbers.
Text expansion can expose layout failures even before translation is complete. Buttons should not clip longer labels, headings should reflow and cards should grow without hiding content. Do not lock essential text inside images.
7. Respect zoom, reflow, contrast and reduced motion
Test at 200% zoom and at a narrow viewport. Users should not need horizontal scrolling to read ordinary content, and fixed-height containers should not cut off enlarged text. Maintain sufficient contrast for body text, controls, icons and focus indicators, including hover, disabled and error states.
Animations should respect prefers-reduced-motion. A decorative hero effect can be removed without affecting the message. A carousel, progress animation or auto-updating dashboard needs pause controls and an alternative that does not make the task depend on motion.
8. Provide meaningful alternatives for images, charts and media
Informative images need alt text that explains their purpose in context. Decorative images should use an empty alt attribute. Charts need a concise summary and access to the underlying important values; screenshots should not be the only way technical instructions are communicated. Video needs captions, and audio-only information needs a transcript.
How I would test a UAE website or SaaS release
I use automation as the first pass, not the final verdict. Lighthouse, axe or another rules engine can detect missing names, contrast failures and structural problems, but it cannot decide whether a workflow makes sense or whether an alt description communicates the right information.
My release process starts with representative journeys: sign in, search, filter, submit a lead form, complete a payment, update account settings and recover from an error. I run automated checks on the shared templates, then perform keyboard-only testing, zoom and reflow checks, reduced-motion testing and screen-reader checks with tools such as NVDA or Narrator. Mobile testing includes touch targets, orientation and visible focus where an external keyboard is used.
For component-based applications, accessibility tests should sit close to the design system. A button, dialog or input fixed once should improve every screen that uses it. I also keep accessibility regressions in the normal issue tracker with an owner and severity instead of placing them in a separate document that nobody revisits.
Production readiness checklist
- Every page has a unique title, one H1 and clear landmarks.
- All controls have accessible names and correct native semantics.
- Important journeys work with keyboard only.
- Focus remains visible and is not covered by sticky content.
- Forms provide labels, instructions and useful error recovery.
- Authentication supports password managers and accessible alternatives.
- Text, controls and focus indicators meet contrast requirements.
- Pages reflow at zoom without clipping essential content.
- Arabic and English layouts have correct language and reading direction.
- Motion can be reduced and auto-updating content can be controlled.
- Images, charts and media provide appropriate alternatives.
- Automated checks are backed by manual and assistive-technology testing.
If you are already reviewing security and privacy, accessibility belongs in the same production gate. My Next.js security checklist covers another part of that release process, while the UAE full-stack development page explains how I approach complete product delivery.
Practical takeaway
An accessible UAE website is not created by adding a badge or passing one score. It comes from semantic components, visible focus, usable forms, keyboard support, bilingual testing and repeated checks on the actual journeys customers need to complete.
Start with the highest-value workflow and fix the shared components underneath it. That creates a better product for people of determination, older users, mobile users, keyboard users and customers working in difficult conditions. It also produces cleaner front-end code and fewer surprises during procurement or audit.
If you need a practical accessibility review or want to build a WCAG-aware SaaS platform for the UAE, send me the project details.
Written from production experience