Interactive Grid inline edit focus trap still inconsistent after validation error in APEX 21.1+

Answer

No declarative attribute to control focus restoration after an Interactive Grid inline edit validation error is documented for APEX 21.1 through 23.x. Focus behavior is governed by the standard Interactive Grid edit model and by how Chrome and Firefox handle ARIA focus containment when an error is rendered.

Confirmed facts

• APEX 21.1 added keyboard navigation for the Interactive Grid toolbar and column headers.
• No release notes for APEX 21.1 to 23.x describe a new declarative attribute for focus restoration on inline edit validation errors.
• Built-in column validation and the built-in error display region are declarative and WCAG 2.1 AA compatible when used as designed.

Likely explanation

After a validation error the edit row remains in an active editing state. The grid uses focus containment semantics for the edit overlay. Chrome 118+ and Firefox 119+ diverge on where focus is left when the error message is rendered outside the editing cell, which produces the inconsistent trap or focus loss you observe. This is browser ARIA handling, not a configurable APEX attribute.

Declarative steps that keep WCAG 2.1 AA and cross-browser behavior

1. Keep inline edit enabled and rely on built-in column validation. Avoid custom dynamic actions that cancel edit or move focus programmatically.
2. Use the Interactive Grid attribute Error Display Region and ensure validation messages are presented inline with the editable cell. APEX renders these messages in an aria-live region so screen readers announce the error without a programmatic focus move.
3. Do not enable attributes or dynamic actions that force focus to the toolbar, column header, or first row on edit cancel. Let the browser return focus to the element that triggered validation.
4. Test with native keyboard navigation only in Chrome and Firefox using the Accessibility tree / Accessibility Inspector to confirm focus stays on the invalid control and the error is announced.

Custom JavaScript to forcibly restore focus is a last resort and risks breaking screen-reader announcements in the Chrome vs Firefox divergence.

One diagnostic that changes the recommendation

Is the validation error raised by built-in column validation, or by a custom server-side process / dynamic action? The focus restoration path and viable declarative configuration differ between the two. If it is custom, the error display region and aria-live association must be verified for your process.