Accessibility violation: missing aria-label on browsable API form inputs

Answer first

Use aria-labelledby pointing to the existing <label> id as the primary naming mechanism. Use aria-label only as a fallback when no visible label is rendered. Use aria-describedby only for help text, not for naming. Do not add positive tabindex values; keep DOM order matching visual order.

Confirmed facts

• DRF browsable API templates already render a <label> per field in the default horizontal and vertical layouts. The accessible name is missing because the control is not reliably linked to that label for assistive technology.
• aria-labelledby reuses visible label text, avoids duplication, and is the WCAG / HTML-AAM recommended pattern when a visible label exists.
• aria-describedby is not a naming mechanism. It is appropriate for help_text so the description is announced after the name.
• Positive tabindex values break keyboard navigation and custom template overrides. The correct tab order is DOM order.

Likely explanation

The violation is reported because automated checkers see controls without an explicit accessible name. In practice the label is present visually but the input lacks a stable id/for pair or an ARIA reference. DRF template internals are not a stable public API and block names vary by version, so the fix must stay inside shipped templates and preserve existing context variables and blocks.

Steps for this case

1. Ensure each field label has a stable id. In the shipped DRF templates, derive the id from the control id or field name and render <label for="..." id="...-label">.
2. Add aria-labelledby="...-label" to the input, select and textarea. Keep the existing <label for> association.
3. Fallback when label is missing or empty: render aria-label from the serializer field's label attribute. DRF already derives this from the field name via Django humanization, which preserves localization. Fall back to the raw field name only if label is absent.
4. Attach help text with aria-describedby referencing a description element, not as a name.
5. Do not add tabindex attributes. Verify visual order matches DOM order in the default templates. Avoid tabindex > 0 entirely.
6. Keep changes within DRF's shipped templates only, leaving block structure unchanged so projects that override templates continue to work. Document the change for projects that copied templates wholesale.

Verification

• Run axe-core or Lighthouse against a browsable API endpoint and confirm zero "form element has no label" violations.
• Inspect rendered HTML: each control has either aria-labelledby referencing an existing label id, or aria-label when no label renders.
• Tab through the form with a keyboard and confirm focus order matches visual order with no tabindex attributes present.
• Test with a screen reader to confirm announced names match visible labels.

One diagnostic detail that changes the recommendation: which DRF version and which browsable API layout you are using, and whether you have custom template overrides for rest_framework/horizontal/form.html or field partials. Template block names differ across versions, so the exact edit location depends on that.