# Arabic autocomplete: reliable selection in MENA apps

An Arabic supplier picker can display the right names and still submit the wrong supplier. A delayed response replaces the current suggestions, the highlighted row moves, and Enter accepts a record the user did not mean to choose.

For a MENA procurement tool, CRM or service-booking product, autocomplete deserves a contract of its own. The contract must connect editable text, asynchronous results and an explicit record selection. Translating the placeholder does not establish that connection.

This guide proposes an editable, single-select combobox for authorised business records. It concentrates on interaction and request state. SultanByte's [Arabic search guide](https://www.sultanbyte.com/arabic-search-production-normalization-stemming-relevance-qa) covers retrieval and ranking; changing an analyzer will not fix a stale popup.

*Cover: original SultanByte artwork showing an Arabic autocomplete workflow from typed query to explicit record selection.*

## Decide whether the field accepts text or a record

Write the submission rule before choosing a component. A general search box can accept an arbitrary query. A supplier field on a purchase order should identify a particular permitted supplier. These are different products even when their dropdowns look similar.

For the supplier picker proposed here, keep the typed text separate from the selected record ID. Typing a name is not selection. Once the user edits a selected label, clear the selection and require another explicit choice before submission. Otherwise the screen can show one name while the hidden field still contains another supplier's ID.

The [WAI-ARIA combobox pattern](https://www.w3.org/WAI/ARIA/apg/patterns/combobox/) distinguishes editable fields that allow arbitrary text from fields restricted to allowed values. It also distinguishes manual selection from automatically selecting the first suggestion. Use manual commitment for this workflow: highlighting a candidate helps navigation; accepting it commits the record.

When no candidate fits, offer a separate authorised create-record process if the product supports one. Do not silently create a supplier from an unselected query. Product owners should decide what happens on blur, Escape and form submission, then make those decisions visible in acceptance tests.

## Keep text editing under the user's control

Use a real text input with a persistent label. In the proposed component, preserve its current value while the person types; send a separate query representation to the search service. Avoid rewriting the field after every keystroke or replacing it with the first result.

Composition events need explicit handling. MDN documents [InputEvent.isComposing](https://developer.mozilla.org/en-US/docs/Web/API/InputEvent/isComposing) as indicating events between composition start and end. Its compatibility page currently marks the property as limited availability, so validate the event sequence in your supported browser and keyboard combinations rather than relying on that property alone.

For this design, track composition start/end, suspend suggestion requests during composition, and avoid treating a composition-confirming Enter as a record-selection command. Resume from the committed input value. Deduplicate the final input and composition-end paths so one committed value does not accidentally schedule two identical requests.

Do not assume every Arabic keyboard produces the same events, or that composition concerns apply only to Arabic. Test the actual desktop and mobile input methods your users employ. Include paste, selection replacement, deletion and switching keyboards mid-entry.

## Reject old responses even when cancellation exists

Assign a new generation to every meaningful input or context change. The context includes the active workspace, authenticated session and chosen search scope, not just the visible string.

Capture that generation when dispatching a request. When a result arrives, allow it to update the interface only if its generation still matches the current one. Apply the same check to errors and loading-state cleanup. An old request's final cleanup must not switch off the spinner for a newer request.

[AbortController.abort()](https://developer.mozilla.org/en-US/docs/Web/API/AbortController/abort) can abort fetch operations and response-body consumption. Use it to cancel superseded browser work, but retain the generation check as the component's acceptance rule. Cancellation and permission to render a result are separate decisions in this proposed design.

Invalidate immediately when the user clears the input, starts composing, changes workspace or leaves the component. Do not wait until the next debounced request starts. That waiting interval is precisely when an older response could otherwise repopulate a cleared field.

Also track whether the popup is still wanted. Escape should dismiss it without a late response reopening it. A matching query generation alone cannot express that interaction decision. Clear the active option when replacing results; do not reuse an array position that now refers to another supplier.

![Proposed autocomplete flow: preserve typed text during editing and composition, request authorised candidates with a generation, reject outdated responses, then explicitly select a record ID. Clearing, workspace changes and dismissal invalidate the relevant pending interaction.](https://cdn.hashnode.com/uploads/covers/60ecf4a0fc37a15ec15655e8/7797dc7e-40bd-4e20-943d-b24e1080ab2e.png align="center")

*Original infographic: SultanByte. Proposed interaction design informed by W3C APG, MDN and OWASP documentation, October 2026. It is a design framework, not measured performance.*

## Make the popup usable without a mouse

For a listbox popup, the APG pattern keeps DOM focus on the combobox and uses `aria-activedescendant` to identify the active option. Give the input `role="combobox"`, an accessible name, `aria-controls`, an accurate `aria-expanded` state and the appropriate `aria-autocomplete` value. The list and its options need their corresponding roles and selection state.

Use Up and Down to navigate suggestions, Enter to accept an active candidate, and Escape to dismiss. Preserve browser text-editing shortcuts. In particular, do not reinterpret Left and Right as result navigation merely because the interface is RTL. Choose a tested implementation and verify its behaviour instead of adding roles to a visually convincing dropdown.

W3C's [editable combobox example](https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-autocomplete-list/) warns that its demonstration is not intended for production environments. It also demonstrates keeping the active option in view. Require testing across your supported browsers and assistive technologies when evaluating a component library; copying the example is not a substitute.

For the proposed record picker, expose enough information to distinguish similar names without turning each option into a miniature page of buttons. If users must open details or perform several actions inside each result, reconsider the interaction pattern rather than nesting arbitrary controls in a listbox option.

## Separate Arabic labels from identifiers

A candidate might combine an Arabic business name, an English branch label and an internal supplier code. Render these as distinct pieces rather than concatenating one fragile string.

The [HTML Standard's bdi element](https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-bdi-element) isolates a text span from surrounding bidirectional formatting; its direction defaults to auto. Use that isolation for an unknown-direction name, and an explicitly LTR fragment for a code whose contract is LTR. Keep the code's stored value separate from its visual placement.

For this component, show a secondary distinguishing attribute only when the user is authorised to see it. A branch or city may be sufficient; a personal phone number should not become default decoration. Preserve meaningful label text when showing a match, and render untrusted names as text rather than treating a search response as trusted HTML.

Do not add a second, frontend-only Arabic normalization rule to make highlighting easier. A transformed query may not occupy the same positions in the original display label. Either use a documented match-offset contract or omit highlighting until you can map it correctly. The selected ID must remain independent of the highlighting calculation.

## Tell users whether search failed or found nothing

A timeout is not an empty result. Maintain separate states for loading, successful results, no matches and a recoverable failure. Keep the entered text when a request fails and provide a retry route that uses the current context.

[WCAG's status-message guidance](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html) distinguishes the results list itself from messages about the search, such as completion or no-results notices. Those messages should be available to assistive technology without moving focus. A changing list does not justify announcing its entire contents on every keystroke.

In this design, use a concise status region and avoid repeated announcements for superseded requests. Translate the status messages alongside labels. Test what is actually spoken: a spinner with an accessible name is not evidence that users hear when the request finishes.

## Authorise suggestions before returning them

[OWASP's authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) calls for permission checks on every request and warns against relying on client-side controls. The suggestion endpoint is a data endpoint, even if it returns only names.

For the proposed supplier picker, derive the permitted workspace on the server, restrict candidates to the caller's access, and recheck the selected ID when the purchase order is submitted. A record can become unavailable between suggestion and submission. Return a useful validation response instead of trusting the earlier dropdown.

If you cache candidates, bind reuse to the correct authorization context and invalidation policy. Clearing the visible list on logout does not erase a shared cache. Avoid recording raw queries in routine diagnostics when operational counters can explain failures without exposing customer text.

For a Saudi deployment and a UAE deployment, document the actual search-service and diagnostic destinations separately. Do not infer those routes from an Arabic locale or a country selector. This guide proposes engineering controls; it does not claim that one configuration satisfies both countries' legal obligations.

## A release test that exercises the whole selection

Use synthetic suppliers with similar Arabic names, mixed-script labels and different IDs. The following cases are proposed acceptance tests, not benchmark results:

*   Dispatch query A, then query B. Deliver B first and A last. Only B may populate the current suggestions or status.
    
*   Clear the field while a request is pending. Its eventual response must not restore candidates or a selected ID.
    
*   Select a supplier, edit its label, then submit. Require a new selection rather than submitting the old ID.
    
*   Start composition while a prior request is pending. Verify that its response cannot replace the composing interaction and that confirmation does not accidentally select a record.
    
*   Press Escape during loading. The completed request must not reopen the dismissed popup.
    
*   Switch workspaces with a request in flight. Reject the old response and test direct server requests for an unauthorised supplier.
    
*   Navigate and submit using the keyboard and supported screen readers in Arabic and English. Repeat with the mobile keyboard open and enlarged text.
    

For CTOs, require evidence against the deployed component and endpoint, not just a library's accessibility claim. For product teams, observe whether a user can identify the intended supplier, recover from a failed search and understand why an edited label requires another selection. Ship when the submitted ID reliably represents that deliberate choice.