WCAG 2.2

WCAG 2.2 — what Saudi enterprises actually need to hit.

A clause-by-clause breakdown of the nine new 2.2 success criteria and which ones the Saudi regulator is checking first.

11 min read · Updated 19 May 2026

WCAG 2.2 was finalized by the W3C in October 2023 and added nine new success criteria on top of the 50 inherited from 2.1. Most Gulf enterprise teams last audited against 2.1 and have not yet noticed the addition. The DGA's index already tests 2.2 in full. So does the Qatar MOTC. This article walks each of the nine new criteria — what it tests, why the W3C added it, the code pattern that fixes it, and whether the Saudi regulator is checking it at AA, AAA, or both.

The conformance hierarchy in one paragraph

WCAG defines three levels: A (the baseline that must be met for any conformance claim), AA (the practical legal target across the Gulf and most of the world), and AAA (the highest level, mandated only for select services). The Saudi DGA accessibility standards and the Qatar e-Accessibility Policy both assume Level AA for in-scope services. AAA is required selectively — typically on national identity services, emergency services, core banking authentication, and government educational platforms serving learners with disabilities. Universal AAA across an entire enterprise is not feasible and is not expected. The skill is knowing where AAA applies and reaching it on those surfaces while holding AA everywhere else.

The nine new success criteria in WCAG 2.2

Each item below names the criterion, the level (AA or AAA), and what the regulator is doing about it in 2026.

2.4.11 Focus Not Obscured (Minimum) — Level AA

When a user-interface component receives keyboard focus, the focus indicator must not be entirely hidden by author-created content. Translation: a sticky header, sticky footer, chat widget, or cookie banner cannot fully cover the focused element. Partial obscuring is acceptable; complete obscuring fails.

This is one of the most common 2.2 failures in Saudi banking dashboards: a sticky chat widget covers the bottom-right corner where a focused "confirm transfer" button lives, leaving the user unable to see the focused state. The DGA checks this on first audit pass.

Fix: ensure scrolled-into-view focused elements come into the viewport unobscured. The CSS scroll-padding property handles most cases.

html {
  scroll-padding-top: 80px;   /* matches sticky header height */
  scroll-padding-bottom: 60px; /* matches chat widget height */
}

2.4.12 Focus Not Obscured (Enhanced) — Level AAA

Like 2.4.11 but stricter: no part of the focused element may be hidden. Required only on AAA-mandated surfaces. The DGA checks this on identity-flow and core-banking authentication screens.

2.4.13 Focus Appearance — Level AA

The focus indicator must meet minimum size and contrast requirements: at least as large as a 2 CSS pixel solid outline around the unfocused component, with a contrast ratio of at least 3:1 against the adjacent colors. Default browser focus rings often fail one or both. A custom focus ring that is "the same blue as the brand" usually fails contrast against the brand background.

Fix: a single global rule, using :focus-visible so the indicator only renders on keyboard focus (not on every mouse click). Pair it with an outline-offset so the ring doesn't touch the element edge.

:focus-visible {
  outline: 2px solid var(--mueen-green-deep);
  outline-offset: 3px;
  border-radius: 4px;
}

/* Suppress the indicator on mouse focus only */
:focus:not(:focus-visible) {
  outline: none;
}

The DGA and SAMA-supervised entities both test 2.4.13 in every audit. It is the single most common new-2.2 failure we surface.

2.5.7 Dragging Movements — Level AA

If a function can be performed by dragging, it must also be operable by a single pointer without dragging — a click or tap alternative. Calendar week selectors, range sliders, signature pads, map pins, and Kanban boards are the common offenders.

The fix is to provide explicit input controls that achieve the same outcome as the drag. A range slider needs adjacent numeric inputs. A signature pad needs an upload-an-image alternative. A calendar week range picker needs explicit "from" and "to" date fields.

2.5.8 Target Size (Minimum) — Level AA

Interactive controls must be at least 24×24 CSS pixels — or have an equivalent target area provided by spacing. There are explicit exceptions (inline links in body text, browser-default form controls, controls duplicated elsewhere on the same page with a larger target), but most icon buttons fall under the rule.

This trips up almost every mobile navigation in the Gulf. The fix is to expand padding rather than icon size, so the design footprint stays the same but the hit area meets the minimum.

.icon-btn {
  /* Icon stays 16x16 visually, target is 24x24+ */
  display: inline-flex;
  align-items: center;
  justify-content: center;
  min-width: 24px;
  min-height: 24px;
  padding: 8px;
}

3.2.6 Consistent Help — Level A

If help is offered on multiple pages (a contact link, a chat widget, a FAQ entry, a self-service portal), those help mechanisms must appear in a consistent relative order across pages. A user looking for the chat widget should not have to re-discover its location on every page.

This is the cheapest of the new criteria to comply with — it is mostly a design-system discipline issue. Put help in the same place in the header or footer and leave it there.

3.3.7 Redundant Entry — Level A

Information the user has already entered in the same flow must not be asked for again — it should either be auto-populated or available for selection. Re-typing a billing address on a checkout flow where the shipping address has already been collected is the canonical fail.

The fix is product work, not just engineering: persist state across flow steps, offer a "same as shipping" checkbox, pre-fill from the authenticated user's stored profile. The criterion has explicit exceptions (re-entry essential for security, re-entry of information that has expired or changed).

3.3.8 Accessible Authentication (Minimum) — Level AA

This is the one that has changed the most enterprise behavior in 2026. Login flows cannot rely on a cognitive function test — remembering a password, transcribing a code from one window to another, solving a puzzle CAPTCHA — without offering an alternative.

The W3C wrote this criterion because users with cognitive disabilities, motor impairments, and many older users genuinely cannot complete password-only or transcription-CAPTCHA login flows. The accepted alternatives are: passkeys (WebAuthn), biometric auth, OTP delivered to a saved device, password managers (the page must not block them with paste-blocking JavaScript), or single-sign-on.

The fix is usually to enable passkey support or to remove the paste-blocking JavaScript that breaks password managers.

<!-- Allow password managers to autofill -->
<input type="password"
       id="password"
       autocomplete="current-password"
       />

<!-- Add passkey alternative -->
<button type="button" id="passkey-signin">
  Sign in with a passkey
</button>

The DGA checks 3.3.8 on every authentication surface. SAMA-supervised banking institutions are now expected to offer passkey or biometric as a real path, not as an experimental feature.

3.3.9 Accessible Authentication (Enhanced) — Level AAA

Like 3.3.8 but with no cognitive function test at any step. Required on services classified as critical citizen infrastructure — national identity (Nafath flows), tax authority logins, emergency-services portals. AAA on authentication is a tougher bar because it means the password path cannot be the default; the alternative has to be at least as discoverable.

Which criteria the Saudi regulator checks first

The DGA does not publish a checking order, but the audit data we see across our customer base shows a clear pattern. On a fresh audit of a previously-untested service, these are the new-2.2 criteria the regulator flags fastest, in order of how often they appear:

  1. 2.4.13 Focus Appearance — almost every site fails it before remediation. Brand-color focus rings against brand-color backgrounds rarely make 3:1.
  2. 2.5.8 Target Size — icon nav bars, sort handles, pagination chevrons.
  3. 3.3.8 Accessible Authentication — password-only login with paste-blocking is universal in legacy systems.
  4. 2.4.11 Focus Not Obscured — sticky chat widgets are the recurring culprit.
  5. 2.5.7 Dragging Movements — flagged whenever there is a map, calendar range picker, or signature surface.

SAMA-supervised entities are scrutinized hardest on 3.3.8 because authentication accessibility intersects with their financial-inclusion mandate. Banks that have not enabled passkeys or that have known paste-blocking JavaScript on login forms tend to fail this clause first.

When AA is sufficient and when AAA is mandated

Level AA is the assumed bar across every Gulf regulator we have reviewed. The DGA's 80/100 composite is calibrated to AA. The Qatar MOTC policy is calibrated to AA. SAMA's accessibility expectations for regulated entities are calibrated to AA.

AAA is mandated, not chosen, on the following surfaces:

Universal AAA across an entire enterprise property is not feasible because some criteria (1.4.6 enhanced contrast, 2.3.2 three flashes, 3.1.6 pronunciation) require either content rewrites or production-capacity that is genuinely expensive. The discipline is to ring-fence the AAA surfaces, hit AAA on them, and hold AA everywhere else with a clear policy on which is which.

The pre-existing criteria that still trip teams up

The new 2.2 criteria get the headlines, but the criteria carried over from 2.0 and 2.1 still produce most of the volume in any audit. The high-frequency failures in the Saudi enterprise context:

1.4.3 Contrast (Minimum) — AA

4.5:1 for normal text, 3:1 for large text (18pt or 14pt bold and larger). Brand palettes rarely survive a contrast check unmodified. Mueen design tokens publish the contrast ratio next to each color pair specifically so designers can pick conformant pairs without re-testing each time. (You can see this pattern in our own tokens.css.)

1.3.1 Info and Relationships — A

Structure must be programmatically determinable. Headings that are styled divs rather than h1–h6. Form labels that are visually next to a field but not programmatically associated. Lists implemented as styled paragraphs.

3.3.2 Labels or Instructions — A

Every input needs a label. Placeholder-as-label is the universal fail; placeholder text disappears on input and is not reliably exposed to assistive technology.

4.1.2 Name, Role, Value — A

Custom widgets — bespoke dropdowns, custom-built checkboxes, tab panels assembled from divs — must expose their name, role, and current value to assistive technology. The fix is usually to use the native HTML element when one exists, and to layer the correct ARIA pattern when no native element is available.

4.1.3 Status Messages — AA

Non-modal status changes (toast notifications, "added to cart" confirmations, validation success messages, async loading states) must be programmatically announced to assistive technology, typically via an aria-live region.

<!-- Live region for status announcements -->
<div role="status"
     aria-live="polite"
     aria-atomic="true"
     id="status-region">
</div>

<script>
// Update the region's text to announce a status change
document.getElementById('status-region')
  .textContent = 'Application submitted successfully.';
</script>

The bilingual layer

Every WCAG criterion has an Arabic dimension that automated tools mostly miss. The four that matter most in Saudi enterprise audits:

How to operationalize this

A team that has decided to take WCAG 2.2 seriously typically follows the same sequence:

  1. Audit the surface once against full 2.2 AA. Identify which surfaces also need AAA (per the list above). Get the baseline score.
  2. Fix the new-2.2 hits first — focus appearance, target size, authentication. These are the criteria the regulator checks fastest and they are cheap to remediate.
  3. Tackle the pre-existing high-frequency failures — contrast, labels, name/role/value. These produce the volume.
  4. Wire the audit into CI. Run automated checks on every PR. Block merges on critical regressions. Ticket the rest.
  5. Re-audit quarterly with a manual review layer for the criteria automation cannot test (focus order, screen reader announcements, motion safety, cognitive load).

The cadence matters more than any single sprint of remediation. Audit once and you have a snapshot. Audit continuously and you have a program. The DGA's quiet direction of travel is toward continuous monitoring as the default expectation for services scoring below 80.