Accessibility often arrives late in a project, usually as a line in a government tender or a complaint from a customer who could not finish checkout. By then, fixing it means reopening designs and rewriting components. The good news is that most of the work is not exotic. It is a handful of habits that, once your team knows them, cost almost nothing to keep.
Why accessibility is a product issue
Accessibility means people can use your product whatever their vision, hearing, movement or cognition. That includes blind users on screen readers, people with low vision who zoom to 200%, someone with a tremor who relies on a keyboard, and the far larger group with a temporary injury, an ageing parent’s eyesight or a phone in bright Dubai sunshine. Designing for them makes the product clearer for everyone.
There is a commercial and regulatory side too. The UAE recognises the rights of people of determination in federal law, and government digital guidelines in the UAE and Saudi Arabia point to the Web Content Accessibility Guidelines (WCAG) as the benchmark. If you sell into Europe, the European Accessibility Act has applied to many consumer services since June 2025. Tenders increasingly ask for WCAG 2.1 or 2.2 at level AA, so it pays to be ready.
What WCAG actually asks for
WCAG can look intimidating, with dozens of success criteria across three levels. Level A is the bare minimum, AA is what contracts and regulators usually mean, and AAA is aspirational for most products. Every criterion hangs off four principles, and if your team remembers these, they will catch most problems before an auditor does.
WCAG 2.2, published in October 2023, added criteria that matter most on phones and in forms: keyboard focus that is not hidden behind sticky headers, alternatives to dragging, a minimum target size of 24 by 24 pixels and not asking people to re-enter information they have already given. It also discourages memory puzzles at login, which is worth remembering when you choose a CAPTCHA.
- Perceivable — content can be seen or heard in more than one way, so images have text alternatives and videos have captions.
- Operable — everything works with a keyboard, touch targets are large enough and nothing flashes or times out unexpectedly.
- Understandable — labels are clear, errors explain how to fix them and navigation behaves consistently from page to page.
- Robust — the code uses proper HTML so browsers, screen readers and other assistive tools can interpret it reliably.
Quick checks you can run this week
You do not need a specialist audit to find the biggest issues. In our experience, a product team can uncover most of the serious barriers in an afternoon using free tools and a little patience. Pick your three most important journeys, such as signing up, searching and paying, and run each of these tests on them.
Automated tools are a useful starting point, but they only catch a portion of real problems. A scanner can tell you an image has no alt text; it cannot tell you the alt text says “image123” or that the error message appears somewhere a screen reader never reaches. Treat a clean Lighthouse score as the beginning of the conversation, not the end.
The mistakes we see most often
- Pale grey text on white that fails contrast, especially in placeholders and footers.
- Form fields with placeholder text instead of real, persistent labels.
- Clickable divs and icons that cannot be reached or activated with a keyboard.
- Error states shown only in red, with no text explaining what went wrong.
- Carousels and pop-ups that move focus away or cannot be paused or dismissed.
Accessibility in Arabic and bilingual products
Products for the region add a layer that many global guides ignore. Each page needs the correct lang attribute, ar or en, so screen readers switch voice and pronunciation. When a single page mixes both languages, mark the mixed passages too. Without this, VoiceOver will cheerfully read Arabic text with English phonetics, which is unusable for the very people you are trying to serve.
Arabic typefaces also need more care with size and line height. Diacritics and connected letterforms become hard to read at sizes that are fine for Latin text, so we usually set Arabic body copy slightly larger. Check that icons with direction, like arrows and progress steps, mirror correctly in right-to-left layouts, and that focus order follows the reading direction rather than the source code.
Do not forget the words themselves. Plain language helps everyone, including the many people in the Gulf who read your site in their second or third language. Short sentences, clear headings and familiar words make pages easier to scan with a screen reader and easier to translate well. Write link text that makes sense on its own, such as “Download the price list” rather than “click here”.
Making accessibility a team habit
One-off audits produce a report, a burst of fixes and then a slow slide back. What lasts is building accessibility into the way you already work. The simplest step is adding it to your definition of done, so no ticket closes until its feature passes the keyboard, contrast and screen reader checks above. It becomes routine surprisingly quickly.
- Designers annotate headings, focus order and alt text in Figma, and use a contrast-checked colour palette from day one.
- Developers reach for native HTML elements first and add axe checks to the build pipeline so regressions fail early.
- QA testers include keyboard and screen reader passes in every regression cycle, not only before launch.
- Product owners write acceptance criteria that mention accessibility and budget time to fix what testing finds.
If a feature cannot be used with a keyboard, it is not finished, however good it looks.
It also helps to test with real people. A short session with two or three users who rely on assistive technology will teach your team more than any checklist. Several organisations in the UAE work with people of determination and can help arrange this, and the cost is modest compared with the insight you gain.
On budget, accessibility built in from the start adds relatively little to design and development, mostly in the early sprints while shared components and patterns are set up. A specialist audit of an existing website usually starts from a few thousand dollars, depending on how many templates and journeys it covers, and the cost of the fixes it recommends varies widely with how the product was built.
The bottom line
Aim for WCAG 2.2 AA, learn the four principles and run the five quick checks on your key journeys this week. Handle Arabic properly, with language tags, readable type and mirrored layouts. Then make accessibility part of your definition of done, so it stays fixed. Products built this way reach more customers, satisfy tender requirements and are simply nicer to use.
