# Arabic confirmation dialogs: focus and safe execution

An operator opens an Arabic supplier record, chooses Delete, and sees a confirmation dialog. The name is familiar, but the supplier code belongs to another branch. A useful confirmation must make that difference readable before the operator commits. It must also let them leave without changing anything.

For MENA procurement portals, merchant dashboards and customer-service tools, confirmation dialogs sit between an interface decision and a consequential server action. Their quality depends on focus, bilingual content and the application's handling of submission. A translated “Are you sure?” does very little on its own.

This guide proposes a confirmation flow for deleting a supplier record. It is an engineering design, not a payment-authorisation mechanism or a claim of accessibility conformance. Teams can apply the same review separately to Saudi and UAE deployments while keeping their permissions and business rules specific to each environment.

*Cover: original SultanByte artwork showing a confirmation dialog between a reviewed record and a separate server decision.*

## First decide whether a dialog is necessary

Reserve interruptions for decisions that benefit from a deliberate review. A routine editable preference may be better served by a visible save result and a reliable undo. A complex deletion involving dependencies may need a dedicated review page rather than a small overlay.

[WCAG's error-prevention guidance](https://www.w3.org/WAI/WCAG22/Understanding/error-prevention-legal-financial-data.html) covers financial transactions, legal commitments and certain changes to user-controllable data. It allows alternatives: reversibility, checking with an opportunity to correct, or review and confirmation before final submission. It does not require a modal for every save.

For the supplier example, product owners should settle the actual consequence first. Does Delete remove a draft record, archive a supplier, or schedule an irreversible purge? Use that exact verb in the title and action button. State what happens to linked orders without promising behaviour the backend does not provide.

If the person needs to examine many related records, let them navigate a review page. Shrinking a complicated operation into a dialog does not make it simpler.

## Use a real modal, not just a dark backdrop

The [HTML Standard](https://html.spec.whatwg.org/multipage/interactive-elements.html#the-dialog-element) distinguishes `show()` from `showModal()`. For this design, use a native `dialog` opened with `showModal()`. A visible `open` attribute or a custom overlay is not interchangeable with that operation.

[W3C technique H102](https://www.w3.org/WAI/WCAG22/Techniques/html/H102) describes the browser handling focus entry, background inertness, Escape and focus restoration for a native modal. It also notes that browser controls remain reachable. “Modal” should not mean attempting to trap someone inside the entire browser window.

Give the dialog an accessible name linked to its visible title. Keep its action buttons inside it. Add a visible Cancel control with an explicit button type so it cannot accidentally submit an enclosing form. Style the backdrop, but do not treat its appearance as evidence that the background is unavailable to keyboard or assistive-technology users.

A component library can still be useful. Ask which underlying element and opening method it uses, and test the integrated component. Adding `aria-modal="true"` to an ordinary container does not implement keyboard handling or make the background inert.

## Choose where focus starts and where it returns

The [ARIA Authoring Practices modal pattern](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/) recommends choosing initial focus according to the task. It suggests the least destructive action for difficult-to-reverse operations, and a focusable static element near the beginning when structured or lengthy content needs to be read first.

For a short supplier-deletion prompt, start on Cancel. For a longer impact summary, focus the heading or introductory text, then let users read the details before reaching the buttons. Do not automatically focus Delete because it is visually prominent.

Keep the DOM sequence meaningful in both languages. Do not reverse keyboard order with positive `tabindex` values to imitate an RTL screenshot. Test Tab and Shift+Tab, visible focus, Escape and every close control. A custom implementation should meet the APG interaction pattern; native behaviour still needs testing in the supported browsers.

When the dialog closes, return focus to the invoking control when it remains usable. Successful deletion can remove that control. In that case, choose a logical destination, such as the supplier-list heading or the next relevant row, instead of leaving focus on a removed node. Write this destination into the component's acceptance criteria.

## Show the exact record in readable Arabic

Present the supplier name, distinguishing code and consequence as separate labelled fields. Keep the stored identifier independent of translated display text. Two branches with similar Arabic names must remain distinguishable without relying on a truncated label or colour.

[W3C's inline bidirectional-text guidance](https://www.w3.org/International/articles/inline-bidi-markup/) recommends tightly wrapping opposite-direction phrases with appropriate directional markup. In an Arabic dialog, isolate a known LTR supplier code in its own `dir="ltr"` span. Use `bdi` or suitable automatic direction handling for names whose direction is unknown. Preserve the actual identifier; visual reordering is not a normalization rule.

Keep Arabic language and direction metadata on the rendered content. A translated title does not automatically translate a close button's accessible name, an error message or a pending-state announcement. Review those strings together. SultanByte's [broader Arabic accessibility guide](https://www.sultanbyte.com/arabic-web-accessibility-uae-qatar) covers the surrounding page conventions.

Let long names wrap. At narrow widths, stack the labelled details and controls rather than compressing them into a horizontal strip. [WCAG's reflow guidance](https://www.w3.org/WAI/WCAG22/Understanding/reflow.html) describes a width equivalent to 320 CSS pixels for vertically scrolling content, with exceptions for content that requires two-dimensional layout. An ordinary confirmation should not need a wide comparison table to explain what will be deleted.

![Proposed confirmation flow: review the exact record, choose deliberately, validate on the server, then report the outcome. Closing the dialog dismisses the view; it does not prove that submitted work was cancelled.](https://cdn.hashnode.com/uploads/covers/60ecf4a0fc37a15ec15655e8/d8c7754a-9c14-44a5-8d0e-aac902b34efb.png align="center")

*Original infographic: SultanByte. Proposed interaction and execution framework informed by WHATWG HTML, W3C WAI and OWASP guidance, October 2026. It is not a browser compatibility chart or a security certification.*

## Keep dismissal separate from the business action

A close event tells the application that the dialog closed. It is not, by itself, permission to delete. Define an explicit confirmation path and keep Escape, Cancel, navigation and dismissal out of it.

There is a subtle reuse hazard in native dialogs. The HTML Standard defines `returnValue` as retaining its last assigned value. Closing without supplying a replacement does not make that value fresh evidence of consent. If your implementation uses it, reset it for each opening and require the intended confirmation action for the current record. Do not execute a destructive operation from any close event that happens to expose an old success value.

Capture the reviewed record ID and version when preparing the confirmation. If the active workspace, selected record or relevant details change, invalidate that review. Do not let a reusable dialog read whatever global selection happens to exist when its asynchronous handler eventually runs.

Once submission starts, the meaning of Cancel needs attention. Dismissing a view does not establish that the server stopped working. Our proposed flow changes the control to Close and retains an operation-status route when work can continue. If the product offers genuine cancellation, make it a separate server operation with an explicit result. Never display “Cancelled” merely because a request was aborted in the browser.

## The server must recognise the reviewed operation

[OWASP's transaction-authorisation guidance](https://cheatsheetseries.owasp.org/cheatsheets/Transaction_Authorization_Cheat_Sheet.html) separates identifying significant transaction data from enforcing authorisation on the server. It also discusses permitted state transitions and protecting reviewed data against modification. Those principles are useful here, although a supplier-deletion dialog is not a substitute for the stronger authorisation required by a financial workflow.

For the proposed deletion API, check the authenticated actor, permitted workspace and target record on every execution attempt. Compare the expected record version with the current version. If a relevant change has occurred, refuse the stale operation and require a fresh review that explains the difference.

Give a submission its own operation identifier and define how retries retrieve the same outcome. A disabled button can discourage repeat clicks, but it cannot establish server-side deduplication. Treat a lost response as unresolved until the application reads the durable outcome; do not invite the operator to repeat an irreversible action blindly.

Keep the review payload small. It needs enough information to identify the intended action, not a copy of every supplier attribute. Diagnostics should record the operation reference and outcome without collecting the whole dialog as free-text telemetry.

## Make the outcome available without reopening the dialog

A disappearing overlay is an ambiguous result. Show whether the operation succeeded, was refused, remains pending or has an unknown outcome. Keep the record reference visible where the operator can return to it.

[WCAG's status-message guidance](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html) addresses updates that assistive technology can announce without moving focus. Use a suitable status region for a concise pending or completion message. Keep it outside a dialog that will be closed; a message hidden with its container is a poor completion signal.

For a validation failure, explain what changed and how to review again. For a service failure, preserve enough context to check status or retry safely. Avoid both extremes: silently closing on every response, or repeatedly moving focus to a modal for routine progress updates.

Before release, run the whole flow in Arabic and English. Use similar supplier names with different codes, a long mixed-script name, keyboard-only navigation and supported screen readers. Repeat at narrow widths and enlarged text. Open, confirm, reopen for another record, then try both Escape and the Cancel button: the previous decision must not carry forward. Change the record while the dialog is open and require a stale-review refusal. Finally, lose the submission response and verify that the operator can discover the outcome without deleting twice.

These are proposed acceptance tests, not reported benchmark results. Product should approve the wording and consequence; engineering should demonstrate the interaction and server behaviour together. Release the flow when the person can identify the record, decline safely and recover the outcome of a deliberate submission.