Web Accessibility: WCAG 2.2 by the Numbers, and What Arabic Sites Need

Web accessibility (a11y) is a set of conditions written as numbers: a contrast ratio of at least 4.5:1 for body text, a pointer target no smaller than 24×24 CSS pixels, a page that works at 320 CSS pixels wide without horizontal scrolling, and a keyboard focus indicator that is visible and not covered. The reference is WCAG 2.2 from the World Wide Web Consortium (W3C), a formal Recommendation whose latest published version is dated 12 December 2024.

The question that comes before all of it for a business owner is "am I legally required to do this?" The answer in Egypt and Saudi Arabia is clearer than it looks, and we get to it after the criteria. In short: the documents published up to September 2026 address government entities, and we found nothing that imposes a technical standard on a private commercial website in either country.

Levels A, AA and AAA: what each one means

WCAG criteria are spread across three levels, and conformance is cumulative: Level AA conformance means satisfying all Level A and Level AA criteria together, and Level AAA means satisfying all three.

The part worth noticing is that W3C itself writes in the conformance section that "it is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA success criteria for some content". So AAA is a set of criteria some of which are inherently unreachable for certain content, not an upgrade you buy with a bigger budget. The level policies around the world are built on is AA.

Another condition gets skipped often: conformance is measured on the full page, and where a page is part of a multi-step process (a cart, a signup, a booking) then every page in that process has to meet the same level. A flawless product page and a broken payment step mean the whole path fails.

Contrast: the actual numbers

The specification defines "large text" as 18 point, or 14 point bold. Since nobody writes CSS in points, the Understanding document for the criterion gives the conversion outright: one point equals 1.333 pixels, so 14 and 18 point come to roughly 18.5 and 24 pixels. A 24px heading or a 19px bold lead paragraph counts as large text and needs only 3:1, while 16px body text needs the full 4.5:1.

Watch 1.4.11 in particular, because it is the one modern designs fail most. A light grey input border on a white background can look fine and fail on measurement, since the border is what identifies the field in the first place. The same applies to an icon that signals a state, or a colour swatch in a chart that carries meaning.

If your colours are documented in a design system, the right place to fix these ratios is the colour token layer, not each component separately.

Target sizes and keyboard navigation

2.5.8 Target Size (Minimum) is new in 2.2 at Level AA, and requires a pointer target of at least 24×24 CSS pixels. It carries a precisely defined spacing exception: where a target is smaller, draw a 24-pixel-diameter circle centred on it, and that circle must not intersect another target's. This is what makes a row of tiny share icons packed together a failure, while the same icons with enough space pass. Level AAA raises the figure to 44×44 pixels.

Keyboard operation runs across four consecutive criteria:

• 2.1.1 Keyboard (A): every function on the page is operable from a keyboard.
• 2.1.2 No Keyboard Trap (A): whatever you can enter with the keyboard you can leave with the keyboard. A modal that holds focus inside itself is the classic case.
• 2.4.3 Focus Order (A): the tab sequence preserves meaning. This is exactly where pages break when they are reordered visually with the order property in Flexbox or Grid without changing the source order in HTML.
• 2.4.7 Focus Visible (AA): the focus indicator is visible. Removing outline with no replacement is a direct failure.

WCAG 2.2 added a fifth criterion for a familiar problem: 2.4.11 Focus Not Obscured (Minimum) at Level AA requires that the component receiving focus is not entirely hidden behind author-created content such as a sticky footer, a fixed header or a cookie bar.

Text resizing, reflow and text spacing

1.4.12 is misread constantly. The specification says plainly that content is not required to use these values; what is required is that the page loses no content or functionality when a user imposes them from their settings or a browser extension. The practical difference: a button fixed at height 40px with one line of text will clip that text once a 1.5 line height is forced, while a button that relies on padding grows.

And 256 pixels in the reflow criterion is not a typo. The first figure (320) is the width for content that scrolls vertically; the second is the height for content that scrolls horizontally, such as vertical scripts. The criterion excludes what genuinely needs a two-dimensional layout: maps, diagrams, video and data tables.

What WCAG 2.2 actually added

Version 2.2 added nine criteria on top of 2.1, and removed one: 4.1.1 Parsing, which demanded well-formed markup free of duplicate attributes and became obsolete once modern browsers handled those errors themselves.

Three of these touch what an Arabic development team builds every week. 3.3.8 means in practice that blocking paste in an OTP field or a password field is a failure, since the specification names password manager support and copy-and-paste as examples of mechanisms that satisfy it. 2.5.7 means a drag-and-drop reorder in a dashboard needs a pair of move-up and move-down buttons beside it. And 3.3.7 cuts straight through shipping forms that ask for the address twice.

Accessibility on Arabic sites

This part is missing from ready-made translations, because its sources sit in internationalisation documentation rather than accessibility documentation.

dir and lang in the right place

W3C internationalisation guidance is firm on two points. First, base direction is set with dir="rtl" on the html element itself, and in the absence of the attribute the default direction is left to right no matter how Arabic the content is. Second, setting base direction from CSS is wrong, because text direction is semantic information that must survive when styles do not load. So the correct line at the top of the document is: <html dir="rtl" lang="ar">

The lang attribute is not cosmetic. The Understanding document for 3.1.1 explains that a screen reader uses it to load the correct pronunciation rules. An Arabic page with no lang="ar", or with a forgotten lang="en" in the template, gets read by an English speech engine over Arabic text. And when you drop an English term into an Arabic paragraph, 3.1.2 Language of Parts at Level AA asks you to mark it with a span carrying lang="en", with an exception for proper names and terms that have become part of the surrounding vernacular.

In CSS, swap left and right for the logical start and end as the same guidance recommends, so the layout works in both directions without a second stylesheet.

Content your users type

Our sites are full of fields where people write a mix: an English company name inside an Arabic interface, or an Arabic review that opens with a Latin product name. This is where dir="auto" earns its place, since the browser decides direction from the first strongly directional character in the element. The guidance is explicit that the approach is not foolproof (a paragraph that opens with an Arabic word inside an English sentence will be aligned right), but it gives the expected result in the vast majority of cases. Alongside it, the dirname attribute on form fields sends the text's direction to the server with the data itself, so a review is stored with its own direction instead of being guessed at display time.

One case still needs a manual fix: an Arabic page title that begins with a Latin word. Browsers do not read the document's direction when they render the title in a tab or a bookmark; they guess it from the first strong character, so the order comes out wrong. The workaround the guidance recommends is adding a right-to-left mark (&rlm;) at the start of the title.

Arabic digits and their direction

The W3C note on Arabic and Persian layout requirements documents a detail developers walk into. Arabic-Indic digits (٠ ١ ٢ ٣), used in Egypt, Saudi Arabia and Iraq, are classified AN in the bidirectional algorithm, while European digits (0 1 2 3) are classified EN, and the two do not order the same way inside mixed Arabic text. In every case the digits themselves are written left to right even inside text read right to left.

The practical consequence: mix digit shapes on one page and you will get unexpected ordering in a phone number, a date, or an invoice number next to a currency symbol. Pick one shape and hold to it across the interface. The same note records that in Arabic writing the percent sign goes to the left of the number, ٪١٢ rather than ١٢٪.

Arabic type and line height

That note also states that Arabic ascenders and descenders extend much further than their Latin counterparts, and that alignment needs particular care where the two scripts meet. This ties straight back to 1.4.12: a line height tuned on a Latin typeface and then applied to an Arabic one clips hamzas and descending dots, and a button with a fixed height clips its own label. The test is quick: force a 1.5 line height across the page and see what breaks.

Button and field names as the reader hears them

2.5.3 Label in Name at Level A requires the component's programmatic name to contain the text shown visually. The failure we keep meeting in local projects: a button reading «إرسال الطلب» with aria-label="Submit" attached. Someone driving the page by voice says what they see, and finds nothing that matches.

The W3C ARIA practices guide describes what aria-label does plainly: an assistive technology user perceives only the contents of that attribute, not the visible link text. One forgotten translation in one attribute erases the entire Arabic label for a screen reader.

Is digital accessibility mandatory in Saudi Arabia and Egypt?

Saudi Arabia

The Digital Government Authority issued a document titled «إمكانية الوصول لمحتوى المواقع الحكومية الإلكترونية» on 1 December 2022, classified within its regulatory framework under «الأدلة الإسترشادية», the advisory-guides category, which sits apart from "policies" and from "controls and standards". Its scope, as the Authority describes it, is "digital platforms, digital portals and government websites", and the document presents WCAG guidance, evaluation tools and assistive technologies. In other words it is an advisory guide aimed at government entities, not a regulation imposing a specific conformance level.

Alongside that, individual entities commit themselves in their published policies. The policy on access to digital government information and services at the Communications, Space and Technology Commission states in clause 4.8 that its platforms comply with the minimum W3C accessibility and usability standards and with WCAG 2.0. That is an obligation the entity places on its own platforms, and against WCAG 2.0 rather than 2.2.

Egypt

Law 10 of 2018 on the rights of persons with disabilities, published in the Official Gazette, issue 7 (bis, C), on 19 February 2018, defines in its third article «النفاذ إلى الاتصالات وتكنولوجيا المعلومات» as removing barriers so that persons with disabilities can reach information and communications technology "including the internet, electronic services and emergency services". Article 4, item 12, obliges the State to take the measures that secure access to and use of information, communications and technology for persons with disabilities.

So the law names the internet and electronic services explicitly, but it names no technical standard and no conformance level, and it does not direct the obligation at private establishments. Note too that the "engineering code" defined in the same article covers "buildings and public facilities", which is physical access rather than digital.

What this means for a commercial site owner

As of 21 September 2026 we found no published text requiring a private commercial website in Egypt or Saudi Arabia to meet WCAG at a stated level. Anyone working on a government project or bidding for a government tender will find the requirement in the tender documents or the entity's own policy, and there the number becomes contractually binding. Anyone selling into other markets, the European Union for instance, falls under those markets' rules, which are outside this article's scope.

That answer is more useful than alarm: do the work because it fixes the product, not out of fear of an inspector who is not coming.

A checklist at the code level

Semantic structure. Use header, nav, main, footer, button and a for what they were made for, and order headings h1 through h6 without skipping. 1.3.1 Info and Relationships requires structure and relationships to be programmatically determinable, and correct HTML does that for free.

ARIA, sparingly. The first rule of ARIA use is to use the native HTML element when it already carries the semantics and behaviour you need. The practices guide compresses the risk into one line, "No ARIA is better than Bad ARIA", and explains that role="button" on a div is a promise that you wrote the keyboard interaction that a native button ships with. And never put aria-hidden="true" or role="presentation" on a focusable element, because the user then lands on nothing.

Focus order. Make the HTML order the logical order, and avoid positive tabindex values. In modals: move focus in on open, keep it inside while open, and return it to the button that opened it on close, while keeping Esc available so the modal does not become the trap that 2.1.2 forbids.

Forms. Every field gets a label tied by for and id, not a placeholder alone. On error: name the field and describe the problem in text rather than colour alone (3.3.1), suggest the correction where one is known (3.3.3), and connect the message to the field with aria-describedby. Status messages that appear without receiving focus, such as "added to cart", fall under 4.1.3 and need role="status" to be announced.

Images and video. Alt text describes the function, not the appearance, and a purely decorative image takes an empty alt so assistive technology skips it instead of reading a file name. Video that carries information needs captions, which is also what makes the content usable in a noisy place or with sound off.

The manual test nothing replaces. Put the mouse away and walk the whole purchase or signup path with Tab, Shift+Tab, Enter and Esc. Most of the real breakage shows up in the first two minutes.

Free tools, and the limits they state themselves

• WAVE from WebAIM: a web tool and an extension for Chrome, Firefox and Edge that overlays issues on the page itself.
• axe DevTools from Deque: a browser extension inside developer tools, and the engine other tools lean on for impact weighting.
• Lighthouse, built into Chrome DevTools: gives an accessibility score inside the page report.
• NVDA from NV Access: a free, open-source screen reader for Windows, translated into more than 50 languages with a built-in synthesiser supporting over 55. It is the fastest way to hear your Arabic page the way its user hears it.

And the limit that has to be said out loud: W3C writes plainly that "tools cannot check all accessibility aspects automatically. Human judgement is required… Web accessibility evaluation tools can not determine accessibility, they can only assist in doing so". Chrome's own documentation notes that the Lighthouse score is a weighted average of automated audits and that manual audits are not counted. A 100 means the automated checks passed, not that the site conforms.

What improves for everyone

Describing images in text is an accessibility requirement and an SEO one at the same time. Google's image documentation calls alt text the most important attribute for describing an image, notes that it helps people who cannot see it including screen reader users, says Google uses it to understand the image subject, and points out that it serves as link text when the image is a link. The same holds for link text: descriptive text serves the reader and the search engine together, and empty link text appears in the documentation as a bad example.

W3C also notes that the same practices serve people on small screens and smart watches, older people with changing abilities, people with temporary disabilities such as a broken arm, anyone reading in bright sunlight or a noisy place, and anyone on a slow connection or a limited data plan. Those descriptions fit a wide share of the visitors to any site in Egypt and the Gulf.

As for the size of the primary group, from a primary source: the World Health Organization estimates in its fact sheet updated on 7 March 2023 that around 1.3 billion people, 16% of the world's population or one in six, experience significant disability.

Where to start

Begin with the four that fix the most for the least effort: bring contrast to 4.5:1 and 3:1 in the colour layer, restore a visible focus indicator on every interactive element, set dir and lang on the html element, and walk your main conversion path with the keyboard alone. Then move on to target sizes, forms and error messages.

A serious accessibility review touches design and code together, which is why at Snaabble we treat it as part of interface work rather than a line item added at the end. If you are planning a new site or dashboard, or want an existing interface reviewed against these criteria, tell the Snaabble team about your project and within 24 hours you will have an initial view of the scope with an estimate of time and cost, at no charge and with no commitment. If you are at an earlier stage, UX/UI design principles and website speed optimisation are reasonable places to start.

Sources

• Web Content Accessibility Guidelines (WCAG) 2.2, W3C, Recommendation of 12 December 2024.
• What's New in WCAG 2.2, W3C WAI.
• Understanding SC 1.4.3 Contrast (Minimum), W3C WAI.
• Structural markup and right-to-left text in HTML, W3C Internationalization.
• Arabic & Persian Layout Requirements, W3C Group Draft Note of 2 October 2025.
• ARIA Authoring Practices Guide: Read Me First, W3C WAI.
• إمكانية الوصول لمحتوى المواقع الحكومية الإلكترونية, Digital Government Authority, Saudi Arabia.
• سياسة الوصول إلى المعلومات والخدمات الحكومية الرقمية, Communications, Space and Technology Commission.
• Law 10 of 2018 on the rights of persons with disabilities, Egyptian Official Gazette, issue 7 (bis, C), 19 February 2018.
• Selecting Web Accessibility Evaluation Tools, W3C WAI.