Website Accessibility for Saudi Businesses: Practical Improvements
- Test complete customer tasks in Arabic and English, including errors and the final submission state.
- Use repeatable checks and realistic sample data to document barriers before commissioning repairs.
- Agree the scope of any formal evaluation; an automated score or preliminary review is not a compliance certificate.
Start with the enquiry journey, not a badge
A Saudi business website may work well for a visitor using a mouse and still prevent someone else from asking for a quote. A navigation drawer that cannot be closed from the keyboard, a required phone field with no label, or an Arabic form that rearranges numbers can break the same journey in different ways. Begin with one real task: find a service, understand its scope, choose a language and submit an enquiry. Record where that task becomes difficult before deciding what to redesign.
This is a planning guide for business owners and website teams, not a certification of any website. W3C's Easy Checks is a useful starting point, but explicitly describes a preliminary review rather than a comprehensive evaluation. Treat a clean automated report in the same way: useful evidence about the checks performed, with a clearly stated scope.
Choose a small, representative test set
Review a homepage, a service page, a contact page and a confirmation or error state. Include Arabic and English versions rather than assuming the translated page inherits the same behaviour. If there is a booking widget, document upload or payment step, include that journey separately. Test with realistic sample information that contains both Arabic text and Latin characters, such as a person's name next to an email address. Do not use customer data in test screenshots.
Write down the browser, device, language and interaction method with each finding. “The form does not work” is hard to reproduce; “On the Arabic contact page, Tab reaches the phone field but the focus outline disappears against the background” gives a developer a place to start. Save the steps and the expected result, then repeat those same steps after the fix.
Check navigation without a mouse
Move through the selected journey using the keyboard. Can you identify the focused item, open the menu, reach its links, dismiss it and continue to the main content? Check overlays such as a cookie panel or quote modal as well as the ordinary page. A visitor who becomes trapped in a decorative overlay cannot reach a perfectly usable form underneath it.
Ask the developer to show the order of interactive controls. It should follow an understandable task sequence rather than jump between hidden elements and unrelated sections. Test the language switch and return journey too: a visitor should be able to move to Arabic, find the equivalent service and continue with an enquiry. This is a proposed acceptance check, not a claim that a particular language-switch design is required by every standard.
Make form instructions survive typing
A placeholder saying “Your email” disappears when the visitor types. It should not be the only way to identify a field. W3C's form-label guidance explains how labels are associated with controls. Ask your team to demonstrate that each input has an accessible name and that the visible instruction remains understandable after a value is entered.
Try an empty submission and an invalid email using harmless test information. The page should explain what needs correcting, retain usable entries and provide a route back to the problem. An error indicated only by a red border is insufficient information for someone who cannot distinguish that colour. Also inspect the final state: opening an email draft and confirming delivery are different outcomes. The visitor should be told what actually happened.
Check the data as well as the appearance. Give the name, phone, topic and message different sample values, then inspect the generated draft or confirmation. Each value should appear in its intended place. A page can show four controls while the handler reads only one repeated field name. If the site uses separate mobile and desktop forms, test both versions; one successful layout does not verify the other.
Review Arabic direction and mixed content
Arabic text direction is a separate decision from text alignment. The W3C guidance on right-to-left HTML explains the direction attribute. A team should explicitly consider the document direction and the treatment of embedded content rather than applying a right-aligned style to an otherwise English page.
Use a short test sheet containing an Arabic name, an English company name, an email address, a phone number and a reference such as “RFQ-27”. Read each value on the page and after copying it into a plain-text editor. Check that labels, punctuation and numbers remain intelligible. Repeat the sheet in the submitted enquiry or confirmation view. These examples help reveal a particular site's problems; they do not replace an expert review of bidirectional text.
Give content the same attention as controls
A project screenshot, diagram or video may carry the only explanation of a service. Ask what a visitor learns when that visual is unavailable. Write image alternatives around their purpose, not a list of keywords. A process diagram needs an equivalent explanation of the steps; a decorative background does not need a promotional description repeated by a screen reader. Captions and transcripts should reflect the actual recording, and Arabic material deserves an Arabic review.
Read the page headings as an outline. Can a visitor distinguish the service overview, deliverables, examples and contact section? Check a magnified view for text hidden by sticky elements and for controls pushed beyond reach. Have the team inspect colour contrast with a measurement tool rather than deciding from a screenshot alone. These tasks concern actual understanding and use; avoid adding an accessibility control that merely changes colours while leaving a broken journey in place.
Turn findings into a repair brief
| Finding | Task | Retest proof |
|---|---|---|
| Menu traps focus | Find the service | Record a full journey through and past the menu |
| Labels vanish on entry | Check the form | Show labels and control names in both languages |
| Mixed text is unclear | Check contact data | Compare the test values before and after entry |
| Video has no text version | Learn the scope | Review text that conveys the key video content |
Assign each issue an owner and a retest step. Address obstacles that prevent task completion first, then improve clarity and consistency. Agree on the pages and states covered by the review; adding a new booking provider or replacing the navigation can introduce a new barrier even after an earlier review passed. Keep the record alongside the release checklist so accessibility remains part of maintenance.
Define what the supplier is promising
The WCAG overview explains the standards used to describe accessibility. When commissioning a formal evaluation, specify the version, target level, scope and reporting method rather than asking for “an accessible website” with no acceptance criteria. Clarify how manual checks, assistive-technology testing and user feedback will be included. This guide does not determine which legal requirements apply to your organisation.
For a website project, send the selected journeys, known barriers and desired review scope with your brief. Eclipse's website development page describes its web offering; use the contact page to ask about the proposed scope and deliverables. Agree any specialist accessibility assessment explicitly rather than assuming it is included.
Frequently asked questions
Does an automated accessibility score prove a website is accessible?
No. It reports the checks that tool performs. Review real journeys manually and agree the scope of any specialist evaluation.
Which pages should a business review first?
Start with the homepage, a service page and the enquiry form, including errors and the final submission state. Review both language versions.
Is Arabic text alignment the same as text direction?
No. Review the document direction and mixed Arabic, English and numeric content separately, including the values shown after submission.