Accessibility on an Arabic website is not a separate checklist added after the layout. Direction, text shaping, focus order, labels, errors, and content structure affect whether people can complete the task.
Automated scanners are useful, but they cannot tell you whether a menu restores focus, an Arabic error makes sense, or a mixed-language field reads in the right order.
Set language and direction in HTML
Use lang="ar" and dir="rtl" on the document. Use dir="auto" for user-generated text when its direction is unknown, and bdi to isolate a short name or code inside a sentence.
Prefer logical CSS properties. They let one component adapt to RTL and LTR without a second set of fragile overrides.
Use native elements first
Links navigate. Buttons perform actions. Labels identify fields. Headings describe the document structure. Native elements bring keyboard behavior and accessibility semantics that a styled div does not.
Add a skip link before navigation and make it visible when focused. Keep one clear page heading, followed by section headings in a logical order.
Test the keyboard path
Move through the page with Tab and Shift+Tab. Activate controls with Enter and Space where appropriate. Open the mobile menu, close it with Escape, and confirm focus returns to the button that opened it.
Every focus indicator must be visible against the dark or light surface beneath it. Sticky navigation and floating actions must not cover the focused element.
Connect form errors to fields
Every input needs a visible label. When validation fails, set aria-invalid="true" and connect the error with aria-describedby. Use a status region for the overall result, but do not rely on a toast as the only explanation.
Test errors in Arabic, including long messages and email addresses inside RTL text. Also test network failure, slow submission, and a successful reset.
Check contrast and resize
WCAG 2.2 AA requires at least 4.5:1 contrast for normal text and 3:1 for large text. Important control boundaries and focus states also need enough contrast to be distinguished.
Arabic fonts can look smaller or denser than Latin fonts at the same numeric size. Test the actual family, weight, line height, diacritics, and numbers. Resize text and inspect the page at 320 pixels without horizontal scrolling.
Avoid fixed-height cards for translated content. Do not clip task-critical text to preserve a neat grid.
Write useful alternative text
Describe what an informative image contributes in context. Use empty alternative text for decoration. A screenshot in a case study should identify the screen or state rather than repeat the file name.
Icon-only controls need an accessible name. Decorative SVGs should be hidden from assistive technology so they do not add noise.
Respect motion preferences
Use prefers-reduced-motion to remove nonessential movement. Avoid scroll effects that make reading or focus tracking difficult. Content should remain understandable when animation is disabled.
The final review needs real tasks in a real browser. Navigate the site, submit the form, open every overlay, read the content at narrow widths, and inspect what happens when something fails. A perfect scanner score is useful evidence, but it is not the whole accessibility result.