WordPress accessibility compliance means building and maintaining a site that people with disabilities can use as fully as anyone else, measured against a recognized standard. Today that standard is WCAG 2.2 at level AA, published by the W3C in October 2023. It covers visitors who use screen readers, navigate by keyboard, magnify the screen, rely on captions or have cognitive and motor impairments. It also covers a much larger group: anyone on a small phone in bright sunlight, holding a coffee, using one thumb.
Accessibility is part of how we plan and build every web design project, because retrofitting it is slower and more expensive than designing for it. This guide explains what WCAG 2.2 AA asks for, where WordPress sites usually fall short, why overlay widgets are not a shortcut, and how to test and maintain compliance. It is a practical guide, not legal advice; if you have specific obligations, confirm them with your advisors.
Why WordPress accessibility compliance matters for UAE businesses
Three reasons come up in almost every conversation we have with clients.
- Reach and reputation: the UAE has made inclusion of People of Determination a national priority, and government entities work to WCAG-based requirements for their digital services. Suppliers, partners and semi-government clients increasingly expect the same standard.
- European and international exposure: the European Accessibility Act has applied since 28 June 2025 to a range of products and services, including e-commerce offered to consumers in the EU. Microenterprises are exempt for services, but UAE businesses selling into Europe should check where they stand.
- Commercial performance: clear contrast, readable text, logical headings, usable forms and descriptive links help every visitor, and several of the same signals help search engines and AI assistants understand your pages.
What WCAG 2.2 AA actually requires
WCAG is organized around four principles: content must be perceivable, operable and understandable, and it must work reliably with assistive technologies. Level AA includes every level A criterion plus the AA criteria, and it is the level most laws and procurement policies reference. The requirements that matter most on a typical business site are:
- Text alternatives: meaningful images have alt text that conveys their purpose; decorative images are marked so screen readers skip them.
- Captions and transcripts: pre-recorded video with speech has captions, and audio content has a text alternative.
- Color contrast: normal text has a contrast ratio of at least 4.5:1 against its background, large text at least 3:1, and interface components and meaningful graphics at least 3:1. Color is never the only way information is conveyed.
- Resize and reflow: text can be enlarged to 200 percent, and content reflows at a width equivalent to 320 CSS pixels without horizontal scrolling.
- Keyboard access: everything that works with a mouse works with a keyboard, with a visible focus indicator and no keyboard traps.
- Structure: headings, lists, landmarks and tables are marked up correctly, and the page language is declared.
- Forms: every field has a visible label, errors are identified in text with suggestions to fix them, and required fields are clear.
- Names, roles and values: custom components such as menus, tabs, accordions and sliders expose their state to assistive technology.
What changed in WCAG 2.2
WCAG 2.2 builds on 2.1, so a site that meets 2.2 AA also meets the earlier versions’ requirements, with one exception: the Parsing criterion, 4.1.1, was removed as obsolete. Six new criteria apply at levels A and AA.
| Criterion | Level | What it means on a WordPress site |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | Sticky headers, cookie banners and chat widgets must not completely hide the element that has keyboard focus |
| 2.5.7 Dragging Movements | AA | Sliders, sortable lists and map interactions that use dragging need a single-pointer alternative, such as buttons |
| 2.5.8 Target Size (Minimum) | AA | Clickable targets are at least 24 by 24 CSS pixels, or have enough spacing, with some exceptions such as links within text |
| 3.2.6 Consistent Help | A | Help mechanisms such as contact details, WhatsApp or chat appear in the same relative place across pages |
| 3.3.7 Redundant Entry | A | Multi-step forms and checkouts do not ask users to re-enter information they have already given in the same process |
| 3.3.8 Accessible Authentication (Minimum) | AA | Logins do not rely on memory or puzzle tests without an alternative; password managers and pasting must work |
For many UAE sites, the first and third criteria are the most common failures. Sticky headers plus a floating WhatsApp button plus a cookie banner can cover a large part of a mobile screen, and small icon links in footers often fall below the minimum target size.
Where WordPress sites usually fall short
WordPress core takes accessibility seriously, and the theme directory has an accessibility-ready tag for themes that pass a defined review. Most problems are introduced above core.
Themes and page builders
Many commercial themes remove focus outlines for visual neatness, use headings for styling rather than structure, or build menus and mobile navigation that cannot be operated by keyboard. Page builders make it easy to choose a heading level by size, which produces pages that jump from H2 to H5, and some widgets such as tabs and carousels lack proper ARIA attributes.
Sliders and motion
Auto-rotating hero sliders are a common failure: they move content before people can read it, often lack pause controls and are difficult to operate with a keyboard or screen reader. A single strong hero usually communicates better anyway. Any animation that plays automatically for more than five seconds needs a way to pause it.
Forms and plugins
Contact forms using placeholder text instead of labels, error messages shown only in red, and CAPTCHAs that require reading distorted text are frequent issues. Booking widgets, embedded maps and chat tools from third parties may not meet the standard at all, and they still count as part of your site.
Content added after launch
Even a well-built site degrades as editors upload images without alt text, paste text into headings, use “read more” as link text and publish PDFs that are scanned images. Content governance is where long-term WordPress accessibility compliance is won or lost.
Arabic and bilingual accessibility
Bilingual sites add requirements that are easy to miss. Each page must declare its language correctly, with lang=”ar” and dir=”rtl” on Arabic pages, so screen readers switch to an Arabic voice and read in the right order. English phrases inside Arabic content should carry their own lang attribute. Focus order must follow the visual right-to-left layout, and icons that indicate direction must be mirrored. Alt text, form labels, error messages and accessible names on buttons need translating as carefully as visible text. We test Arabic pages with screen readers configured for Arabic, because a page that works in English can be confusing when read aloud in Arabic.
Why overlay widgets are not a compliance solution
Accessibility overlays are scripts that add a toolbar with options such as contrast modes and text resizing, often marketed as making a site compliant with one line of code. They do not fix the underlying markup: missing labels, broken keyboard navigation, poor heading structure and inaccessible components remain. Many disabled users already have their own assistive technology and find overlays interfere with it. Businesses using overlays have still faced complaints and legal action in some markets. Investing in real fixes in the theme and content is the only reliable route. A settings toolbar can be offered as an extra, but never instead of an accessible build.
How we test and maintain compliance
- Automated scanning: tools such as axe and WAVE quickly catch contrast failures, missing alt text and label errors. They typically find only a portion of issues, so they are a starting point.
- Keyboard testing: tab through every template, menu, form and modal, checking visible focus, logical order and that nothing is hidden behind sticky elements.
- Screen reader testing: NVDA on Windows, VoiceOver on macOS and iOS, and TalkBack on Android, in both English and Arabic.
- Zoom and reflow: check pages at 200 percent zoom and at 320 CSS pixels wide.
- Template-level fixes: fix issues in the theme and reusable components, so every page built from them benefits.
- Editor guidance: a short checklist for the content team covering alt text, headings, link text, video captions and accessible PDFs.
- Regular reviews: retest after major updates, new plugins or redesigned templates, and publish an accessibility statement with a contact route for people who encounter barriers.
Frequently asked questions
Is WCAG 2.2 legally required for private businesses in the UAE?
The position depends on your sector, your clients and where you sell. Government entities work to WCAG-based requirements, and those requirements often pass to their suppliers through procurement, while businesses serving EU consumers may be subject to the European Accessibility Act. Take legal advice on your specific obligations. Building to WCAG 2.2 AA is a sound default whatever the answer.
Can an existing WordPress site be made accessible without a redesign?
Often, yes. An audit identifies issues in templates, components and content, and many can be fixed within the existing design: contrast adjustments, focus styles, form labels, heading corrections and ARIA fixes. Sites built on heavily customized themes or builders with inaccessible widgets may need some components replaced. The audit shows which approach costs less.
Does accessibility conflict with a premium visual design?
No. Accessible design limits a few habits, such as very low-contrast gray text, auto-playing carousels and hidden focus states, but leaves full creative control over layout, typography, imagery and motion. Many of the most refined brand sites are also highly accessible. Constraints such as contrast ratios tend to sharpen design decisions rather than weaken them.
How long does an accessibility audit take?
It depends on the number of unique templates and interactive components rather than the page count. A typical business site built from a limited set of templates can be audited in days, while complex sites with bookings, portals or checkouts take longer. Testing representative templates and key user journeys gives reliable coverage without reviewing every page individually.
An inclusive site that works harder for everyone
Accessible websites are clearer, easier to use and more resilient. The same work that allows a screen reader user to book a consultation also makes forms quicker to complete, pages easier to scan and content easier for search engines to interpret. Treated as part of the build and maintained through good content habits, WCAG 2.2 AA becomes a standard your site meets routinely rather than a project you repeat.
If you would like an honest assessment of where your WordPress site stands against WCAG 2.2 AA, the Bdazzil team would be glad to talk it through with you.
