Ensuring reliable keyboard navigation and ARIA labeling in Insomnia’s request editor and response viewer

Question

The goal is to make Insomnia’s request editor and response viewer fully accessible via keyboard navigation and screen readers, ensuring that each UI element is announced with purposeful ARIA labels and that focus moves predictably through the interface.
Because modifying ARIA attributes or altering the tab order could disrupt existing plugins or custom workflows that rely on the current DOM structure, any redesign must preserve backward compatibility, and color contrast adjustments must be validated for both light and dark themes to avoid creating new accessibility issues.
What is the minimal set of ARIA attributes required to accurately describe each input field? How should the tab order be restructured to follow a logical sequence (URL → method → headers → body → send)? Which accessibility audit criteria must be met before a change can be considered ready for release?

Tasadduq Burney · Answer

To ensure Insomnia's request editor and response viewer are accessible, you must implement a semantic ARIA mapping and a linear focus flow. This allows screen reader users to understand the context of each input and navigate the interface without a mouse while maintaining DOM compatibility for plugins.

Minimal ARIA Attributes for Input Fields
The following attributes provide the necessary context for assistive technologies without disrupting the existing DOM structure:

aria-label: Required for icon-only buttons (e.g., the "Send" button or "Delete" icons in header rows) to provide a text alternative.
  aria-describedby: Used to programmatically link input fields to their corresponding validation error messages or help text.
  aria-expanded: Essential for toggleable sections, such as the Headers or Body tabs, to indicate whether the content panel is currently visible.
  aria-live="polite": Specifically for the response viewer, ensuring that the completion of a request is announced without interrupting the user's current focus.

Logical Tab Order Restructuring
To prevent erratic focus jumping, the tab order should follow the functional sequence of constructing an HTTP request:

Method Selector & URL Input: The primary configuration point.
  Send Button: The trigger action for the request.
  Request Navigation Tabs: Access to Headers, Auth, and Body sections.
  Active Tab Content: The specific editor fields (e.g., key-value pairs in the Headers tab).
  Response Viewer: The final destination to review the output.

Accessibility Audit Criteria for Release
Before release, the changes must be validated against WCAG 2.1 Level AA standards:

SC 2.1.1 (Keyboard): All functionality must be operable via keyboard without requiring specific mouse gestures or creating "focus traps."
  SC 4.1.2 (Name, Role, Value): Every UI component must have a programmatically determinable name and role.
  SC 1.4.3 (Contrast): Text must maintain a contrast ratio of at least 4.5:1, verified across both light and dark themes.

Assumption: This guide assumes a standard DOM-based implementation. If the editor uses a canvas-based rendering engine, you will need to implement a parallel accessibility tree to expose these nodes to the OS.

Diagnostic Detail Needed: Are there any third-party plugins currently utilizing tabindex overrides that might conflict with this proposed linear sequence?

Ensuring reliable keyboard navigation and ARIA labeling in Insomnia’s request editor and response viewer

1 answer

Minimal ARIA Attributes for Input Fields

Logical Tab Order Restructuring

Accessibility Audit Criteria for Release

Your perspective belongs here.

0 question comments