When developing an Arabic-language service, I see the user's success in completing the task as the most important test of the design. The W3C WCAG 2.2 Recommendation provides a reference that includes criteria for keyboard focus, input labels and identifying errors. The version cited was published in December 2024; I treat it here as an established reference for developing our services in 2026.
A journey that can be completed by keyboard
My suggestion is to try submitting an application from start to finish without a mouse. Does focus reach the fields in a sensible order? Is its position clearly visible when a menu or dialog opens? Is it hidden behind a sticky bar? These practical questions reveal problems that may not show up when a page is only reviewed visually.
Reading order deserves particular attention in Arabic interfaces that contain numbers and English names. We should test what a screen reader user hears, what happens when text is enlarged, and how tables behave on a phone. Page direction alone is not enough to make sure every mixed element is understood.
The error message is part of the service
Suppose a user attaches a file whose size is not accepted. "Unable to submit" does not tell them what to do. I prefer a message that states the problem, the required limit and how to fix it, while keeping the rest of their data saved. The error should also be associated with the relevant field and made available to people using assistive technologies.
It helps to show the requirements before an error occurs: the file type, its size, and whether the field is required. Text inside a field is used as an example where needed, alongside a persistent label that stays clear after the user has typed. These details reduce repeated attempts and calls to ask for help.
Testing the whole service
- Start an application, save it and return to it without losing context.
- Deal with missing items and error messages using the keyboard.
- Read the status and instructions when the view is zoomed in and on a small screen.
- Reach the final confirmation and understand the next step and where to get help.
Automated checks can catch some of the problems, but testing the task itself needs human review and the use of suitable tools. Passing a single screen does not prove the accessibility of a journey that includes signing in, attachments, confirmation and returning to the application.
What I aim for is to make accessibility part of how service quality is defined from the outset, so that more service users can understand what is required and complete it independently and with clarity.