Form Helper markup missing ARIA attributes for accessible forms

Direct answer

Do not extend the core CodeIgniter 4 Form Helper to inject ARIA attributes by default. The helper should remain a thin markup generator; accessibility attributes belong in a shared view layer or optional parameters. Wrapping form_open() in a reusable component is not sufficient by itself—it only enforces

/ and label structure for forms that actually use the wrapper. Raw form_open() calls elsewhere bypass it entirely. CSRF token regeneration changes only the hidden token value; it does not alter ARIA semantics. If an AJAX response replaces the entire form in the DOM, keyboard focus is lost and must be restored programmatically.

Likely explanation versus confirmed facts

Likely explanation

The Form Helper was designed to produce HTML tags, not accessibility semantics. Developers must supply aria-label, aria-required, for/id pairs, and grouping elements manually. Whether the helper merges unknown attributes into the rendered tag is an implementation detail that should be verified before relying on it.

Confirmed facts

• CodeIgniter 4.x Form Helper does not emit ARIA attributes or explicit label-for associations by default.
• CSRF regeneration affects the hidden csrf_test_name input value, not screen-reader labels or focus order.
• Replacing a form node in the DOM removes focus from the previously active element.
• A reusable view component can enforce grouping, but only under consistent team adoption.

Steps for this case

1. Create a view component or view cell that wraps form_open() with <fieldset> and <legend>, and accepts an optional ARIA attributes array.
2. Pass ARIA attributes directly to field helpers where supported, for example form_input(['name' => 'email', 'aria-label' => 'Email address', 'aria-required' => 'true']).
3. In AJAX handlers, regenerate the CSRF token, return it in the JSON response, update the hidden csrf_test_name input, then allow submission.
4. Before replacing a form via AJAX, record the active element. After insertion, return focus to that element or the first focusable field, and announce changes through an aria-live region if needed.

Verification

Render a test view with form_input(['name' => 'email', 'aria-required' => 'true']) and inspect the HTML output to confirm the attribute appears. Render the wrapper component and confirm the DOM contains <fieldset> and <legend>. Submit an AJAX form after updating the hidden CSRF input and confirm the server accepts the request. Navigate with NVDA or VoiceOver to confirm labels, required states, and focus order are announced.

Missing diagnostic detail

Are existing forms built through a shared component, or are raw form_open() calls scattered across views? This determines whether to prioritize a component mandate or a helper override.