Arabic accessibility is a reading journey, not a mirror button.

Define the task in Arabic

A bilingual website can look polished and still make a simple task difficult. Start an Arabic accessibility review with a visitor goal, such as reading a business guide, comparing a sponsorship format or downloading a project brief. Write down the expected steps and the information needed at each step. Ask a fluent Arabic reviewer to describe what each label promises before trying it. The purpose is to identify gaps between the interface and the reader's understanding. This proposed review is a practical starting point, not a declaration that a site meets every accessibility requirement.

Set language and direction deliberately

Language and direction are separate decisions. W3C guidance recommends setting the overall right-to-left direction on the HTML document when appropriate, and declaring its language. For an Arabic page, that commonly means lang set to ar and dir set to rtl. A developer should make these choices in the markup, rather than relying solely on visual alignment. Use a deliberate component review for menus, article navigation and form controls. The desired outcome is a coherent reading order, not mechanically moving every symbol to the opposite side of the screen.

Stress-test mixed content

Test the uncomfortable examples: an English company name within an Arabic sentence, a product code, a telephone number, a percentage, a date and a link. Include punctuation beside each example because errors may appear at the boundary between scripts. W3C's bidirectional-text guidance explains why document direction alone does not resolve every mixed-text case. Ask the developer to isolate or mark the relevant inline content correctly. Keep a screenshot and the exact test string for each defect. Avoid treating a visually pleasing screenshot with short placeholder text as proof that real customer information will render correctly.

Make forms understandable

Review every form from the reader's perspective. W3C recommends labels that identify controls. A placeholder that disappears when typing begins should not carry the entire explanation of a field. Check whether required information, example formats and validation messages remain understandable in Arabic. An error should help the person recover, rather than merely announce failure. Test a long organisation name and an unfamiliar sector description. If an input accepts either language, define how its text direction should behave. Do not require a visitor to guess which invisible formatting rule the system expects.

Follow the keyboard journey

Complete the same task using a keyboard. W3C's keyboard accessibility guidance calls for functionality to be operable through a keyboard interface, with a limited exception for inherently path-dependent input. In a practical review, follow focus through the menu, language switch, filters, forms and download controls. Check that the focused element can be identified and that opening a panel does not leave the user trapped. Use assistive-technology testing with appropriate expertise where possible. Automated checks can help find issues, but a successful scan should not substitute for observing the actual reading and interaction sequence.

Record evidence before declaring completion

Keep the review record specific: page, language, viewport, control, expected behaviour, observed behaviour and correction owner. Retest the complete task after a fix, because a local change can disturb another component. Separate language-quality feedback from functional defects so each reaches the right person. For a growing publication, maintain a small set of difficult bilingual examples and reuse them whenever templates change. The goal is not a decorative Arabic edition. It is an edition in which a reader can understand the offer, operate the controls and reach the intended result without avoidable uncertainty.