# Arabic form errors: accessible correction and recovery

An Arabic supplier-onboarding form returns a red banner: "Something went wrong." The operator has entered the company name, contact details and a branch reference, but cannot tell which answer needs attention. Trying again produces the same banner. Switching to English clears the form.

That is a recovery failure, even if the validation rules are correct. For MENA business software, an error flow needs to preserve the operator's work, explain a correctable problem in the chosen language, and distinguish rejected input from an unresolved server request.

This guide proposes an error-handling contract for Arabic and English administrative forms. It covers feedback and recovery, not the detailed rules for validating national identifiers or a claim of WCAG conformance. Use the same interaction principles across deployments, while keeping each country's accepted fields and business rules explicit.

*Cover: original SultanByte artwork showing a rejected form returning to correction rather than being confused with a completed save.*

## Separate an invalid answer from a failed request

Start with a small vocabulary of outcomes. A missing required value is a field error. A supplier that another operator changed while the form was open is a conflict. An expired session requires authentication. A connection lost after submission may leave the result unknown.

Do not send all four through the same "invalid form" component. Asking someone to edit a valid company name will not repair a network failure. Nor should a timeout produce "Nothing was saved" unless the application has established that fact.

For the proposed supplier form, define separate application states: editing, submitting, rejected, saved and unresolved. Add a conflict state if concurrent edits are possible. These are suggested product states, not HTTP status codes or a new standard.

Give each state an allowed next action. Rejected input returns to correction. A confirmed save shows the resulting record. An unresolved request offers a status check or a controlled recovery path rather than an unqualified instruction to submit again. Agree that behaviour with the backend team before polishing the banner.

## Describe the problem and the correction

[WCAG 2.2's error-identification criterion](https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html) requires an automatically detected input error to identify the affected item and describe the error in text. A red outline alone cannot do that. The separate [error-suggestion criterion](https://www.w3.org/WAI/WCAG22/Understanding/error-suggestion.html) asks for known correction suggestions unless they would compromise security or the purpose of the content.

For a missing supplier name, a proposed Arabic message is "أدخل اسم المورد" (Enter the supplier name). For a restricted branch-reference field, explain the accepted format and show an example drawn from that field's actual contract. Avoid an example that implies every Saudi or UAE business uses the same identifier scheme.

Keep the visible field label in the message or its immediate context. An operator should not need to decode an API property such as `legalEntityName`. Translate the complete sentence rather than joining a translated field name to an English validator fragment.

A helpful error is not permission to disclose another customer's data. If a reference is unavailable, decide how much the caller may learn. Never expose the name of an inaccessible organisation just to explain why a uniqueness check failed.

## Use one summary and messages beside the fields

For a long administrative form, use a summary near the beginning and an inline message at each affected answer. [W3C's forms tutorial](https://www.w3.org/WAI/tutorials/forms/notifications/) recommends concise error lists with links to the relevant controls and describes associating messages through `aria-describedby`.

The [GOV.UK error-summary component](https://design-system.service.gov.uk/components/error-summary/) provides a concrete implementation reference: it combines a summary with field-level messages and moves keyboard focus to the summary. Its conventions are design-system guidance, not a separate obligation imposed on MENA applications.

For this proposed flow, move focus to a focusable summary heading or container after a failed submit. Make each summary item a link that brings the corresponding control into view and focuses it. For a grouped answer, choose a useful target within the group. Test the behaviour instead of assuming a fragment URL always produces the intended focus transition.

Keep summary and inline wording consistent. Associate both the persistent hint and the current error with the input; replacing the hint association with the error should not silently remove needed format instructions. Mark a field invalid when the application has determined it is invalid, then clear that state when appropriate.

Do not make every field error an assertive announcement while also moving focus to an announcing summary. Treat that combination as something to test for repetition. The operator needs a coherent explanation, not several voices competing to read the same list.

## Keep the error contract independent of its translation

Return stable, documented field identifiers and error codes from the service. Let the presentation layer map supported codes to reviewed Arabic or English messages. An example contract might contain a field key, a code such as `required`, and bounded parameters needed to explain a rule. It should not contain executable HTML.

Keep a form-level path for errors that cannot truthfully be attached to one field. Unknown codes need a safe translated fallback and a support reference, not an empty banner. If the service owns localisation instead, agree the locale and fallback rules explicitly; do not mix untranslated backend sentences with client-generated fragments.

[OWASP's input-validation guidance](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html) separates syntactic checks from semantic checks and warns that validation does not replace authorisation or safe output handling. Apply the same distinction to feedback: "wrong format" and "not permitted for this operation" should not become interchangeable diagnoses.

Keep server-side enforcement authoritative. Browser validation is an early convenience, not permission to accept a submitted value. A caller can bypass the interface, and business conditions can change after an earlier availability check.

For asynchronous field checks, bind the result to the value and request generation that produced it. Discard an old rejection arriving after the user has corrected the field. A green availability indicator should mean "checked for this value at this point," not promise that the eventual save will succeed.

![Proposed Arabic form recovery flow: identify the failure type, show correction links for rejected input, preserve permitted values while the user edits, then report a verified server outcome. An unknown result requires a status check rather than a claim that nothing was saved.](https://cdn.hashnode.com/uploads/covers/60ecf4a0fc37a15ec15655e8/b5a95073-d971-42ee-b2bf-a6e50710cef8.png)

*Original infographic: SultanByte. Proposed recovery framework informed by W3C WAI, WHATWG HTML, OWASP and GOV.UK guidance, October 2026. It is not a conformance certification or measured usability result.*

## Make Arabic errors readable without changing the data

[W3C's bidirectional-text guidance](https://www.w3.org/International/articles/inline-bidi-markup/) recommends directional markup around opposite-direction phrases and appropriate isolation for text whose direction is unknown. Apply that to references embedded in Arabic messages, not just to the page header.

Keep a known LTR branch code in its own directional wrapper. Use `bdi` or suitable automatic direction handling for a dynamic supplier name. Render inserted values as text. Do not reverse stored identifiers, add spacing to "fix" their visual order, or copy a formatted error sentence back into the saved field.

A language switch should change labels and messages while retaining permitted in-progress values and the same business operation. The selected country must remain independent of interface language: choosing Arabic should not change a UAE supplier form into a Saudi one. Recompute displayed messages from the same error codes in the newly selected language.

Allow long Arabic explanations to wrap beside their controls. Check punctuation around Latin references and test errors with genuinely long company names. SultanByte's [Arabic-digit validation guide](https://www.sultanbyte.com/arabic-digits-web-forms-validation) covers accepted digit families; this flow should explain those rules without silently changing them during recovery.

## Choose who presents validation feedback

The [HTML constraint-validation API](https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#the-constraint-validation-api) distinguishes checking validity from reporting it. It also defines `setCustomValidity()`: a non-empty message sets a custom error, while an empty string clears it.

That last detail matters when wiring server errors into controls. Updating the visible message is not enough if a stale custom-validity error still blocks submission. Re-evaluate and clear the custom error when it no longer applies. Clearing it does not override other native constraints.

Choose a deliberate presentation strategy. Native browser feedback may suit a short form. A custom summary may be more useful for a long bilingual workflow, but then the application owns the missing presentation behaviour. Do not disable native interactive validation without implementing and testing its replacement. Keep semantic labels and applicable constraints even when the presentation is custom.

Avoid aggressive error announcements on every keystroke. Consider validating on submission, then updating a previously rejected field as the user repairs it. Decide separately whether a particular field benefits from a check on leaving it. This timing is a proposed interaction policy, not a universal accessibility rule.

## Preserve work, but do not preserve every secret

Keep ordinary editable answers after a rejection unless there is a documented reason not to. Do not reload the form from its original record and discard unrelated changes. If re-authentication is required, decide which draft values can safely survive and where they may be held.

Do not turn "preserve input" into a blanket local-storage policy. Treat passwords, verification codes and uploaded sensitive material separately. Tell the user when a field must be entered again, rather than silently erasing it and presenting another unexplained error.

[WCAG's status-message guidance](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html) covers updates that can be conveyed to assistive technology without receiving focus. Use an appropriate status mechanism for meaningful progress or a confirmed save when focus stays in place. An error summary that deliberately receives focus is a different interaction; do not assume every update needs the same live-region treatment.

Keep the result visible long enough to inspect. For a supplier save, show the relevant record reference and a route to the saved record. If the result remains unresolved, say that plainly and preserve the recovery context until the service can establish the outcome.

## Review the failed journey before release

Run the form with keyboard navigation and supported screen readers in both languages. Submit several invalid fields, follow each summary link, correct only one answer and submit again. Verify that old errors disappear, remaining errors still point to the right controls, and unaffected values survive.

Then test a delayed validation response, language switching, session expiry and a connection interruption around submission. Include a long Arabic name and an LTR reference in the same message. At a narrow phone width, check that the summary and inline explanations remain readable without covering their controls.

Product owners should review the wording against the actual business rule. Engineers should inspect the server outcome as well as the screen. Release when a person can locate the problem, make a permitted correction and learn what the service actually did, without reconstructing their work after each attempt.