OfflineTools

Need help with your JSON?

Try our JSON Formatter tool to automatically identify and fix syntax errors in your JSON. JSON Formatter tool

Implementing Accessible JSON Formatter Settings Panels

Why Accessibility Matters in Settings Panels

Settings panels are where users customize their experience. For a JSON formatter, these settings might control indentation, sorting, theme, or other display options. If these controls are not accessible, users with disabilities might be unable to configure the tool to meet their needs, severely limiting its usability.

Accessible design ensures that everyone, including those using screen readers, keyboard navigation, or other assistive technologies, can easily understand and interact with your settings.

Accessibility isn't just a feature, it's a fundamental requirement for inclusive software.

Common JSON Formatter Settings

A typical JSON formatter might expose settings for:

  • Indentation Type: Spaces or Tabs
  • Indentation Size: Number of spaces/tabs (e.g., 2, 4)
  • Key Sorting: Alphabetical sorting of object keys
  • Array Formatting: Inline short arrays, break long arrays
  • Theme: Light, Dark, System
  • Font Size: Adjust text size

Each of these settings requires an appropriate and accessible input control.

Building Accessible Input Controls

The foundation of accessible forms lies in using semantic HTML elements correctly and ensuring that every input has a clearly associated label.

1. Text Inputs (e.g., Indentation Size)

For settings requiring a number or text input, use the standard <input> tag with appropriate type and a linked <label>.

Example: Indentation Size

&lt;div&gt;
  &lt;label htmlFor="indent-size" className="block text-sm font-medium text-gray-700 dark:text-gray-200"&gt;
    Indentation Size
  &lt;/label&gt;
  &lt;input
    type="number"
    id="indent-size"
    name="indent-size"
    min="0"
    max="10" // Set reasonable limits
    defaultValue={2} // Use defaultValue as state is not allowed
    className="mt-1 block w-full rounded-md border-gray-300 shadow-sm focus:border-blue-500 focus:ring-blue-500 sm:text-sm dark:bg-gray-700 dark:border-gray-600 dark:text-white"
    aria-describedby="indent-size-hint"
  /&gt;
  &lt;p id="indent-size-hint" className="mt-2 text-sm text-gray-500 dark:text-gray-400"&gt;
    Number of spaces or tabs for indentation.
  &lt;/p&gt;
&lt;/div&gt;

Using htmlFor on the <label> linked to the id of the <input> is crucial for screen readers. aria-describedby links the input to additional descriptive text.

2. Select Menus (e.g., Indentation Type, Theme)

Use the <select> and <option> elements. Again, a linked <label> is essential.

Example: Indentation Type

&lt;div&gt;
  &lt;label htmlFor="indent-type" className="block text-sm font-medium text-gray-700 dark:text-gray-200"&gt;
    Indentation Type
  &lt;/label&gt;
  &lt;select
    id="indent-type"
    name="indent-type"
    defaultValue="spaces" // Use defaultValue
    className="mt-1 block w-full rounded-md border-gray-300 py-2 pl-3 pr-10 text-base focus:border-blue-500 focus:outline-none focus:ring-blue-500 sm:text-sm dark:bg-gray-700 dark:border-gray-600 dark:text-white"
  &gt;
    &lt;option value="spaces"&gt;Spaces&lt;/option&gt;
    &lt;option value="tabs"&gt;Tabs&lt;/option&gt;
  &lt;/select&gt;
&lt;/div&gt;

Native <select> elements are generally well-supported by assistive technologies. Avoid building custom dropdowns unless absolutely necessary and ensure they follow ARIA Authoring Practices.

3. Checkboxes (e.g., Key Sorting)

Use the standard <input type="checkbox"> with a linked <label>.

Example: Sort Keys

&lt;div className="relative flex items-start"&gt;
  &lt;div className="flex h-6 items-center"&gt;
    &lt;input
      id="sort-keys"
      name="sort-keys"
      type="checkbox"
      defaultChecked={true} // Use defaultChecked
      className="h-4 w-4 rounded border-gray-300 text-blue-600 focus:ring-blue-500 dark:border-gray-600 dark:bg-gray-700 dark:checked:bg-blue-600"
    /&gt;
  &lt;/div&gt;
  &lt;div className="ml-3 text-sm leading-6"&gt;
    &lt;label htmlFor="sort-keys" className="font-medium text-gray-900 dark:text-gray-100"&gt;
      Sort Object Keys Alphabetically
    &lt;/label&gt;
    &lt;p className="text-gray-500 dark:text-gray-400"&gt;Organize keys in objects for consistent output.&lt;/p&gt;
  &lt;/div&gt;
&lt;/div&gt;

Ensure the clickable area for the checkbox includes the label text. Clicking the label should toggle the checkbox.

Keyboard Navigation and Focus Management

Keyboard users (including those using screen readers or who cannot use a mouse) must be able to navigate through all settings controls using standard keys like Tab, Shift+Tab, Space, and Enter.

  • Tab Order: Ensure the logical order of controls in your HTML matches the visual order. Native HTML elements handle this correctly by default.
  • Focus Indicators: Make sure the browser's default focus outline (or a custom one with sufficient contrast) is clearly visible on the currently focused element.
  • Interact with Keys: Checkboxes should toggle with Space. Select menus should open and change options with Space, Enter, and Arrow keys. Text inputs should be editable. Native controls provide this automatically.

Using standard semantic HTML form elements is the best way to get correct keyboard support out-of-the-box.

ARIA Attributes

While semantic HTML and labels cover most basic form accessibility, ARIA (Accessible Rich Internet Applications) attributes can provide additional context or handle more complex scenarios, such as:

  • aria-label / aria-labelledby: Provide an accessible name if a visual label isn't suitable (less common for simple settings).
  • aria-describedby: Link an input to additional descriptive text, hints, or error messages (as shown in the text input example).
  • aria-invalid="true": Indicate that an input's current value is invalid.
  • aria-hidden="true": Hide decorative elements from screen readers.

Rule of Thumb: Use semantic HTML first. Only use ARIA when HTML doesn't provide the necessary semantics or for complex widgets (which settings panels usually aren't). The ARIA Authoring Practices Guide is an excellent resource.

Visual Design Considerations

Accessibility isn't just for screen readers; it's also about visual clarity.

  • Color Contrast: Ensure sufficient contrast between text and background for labels, input values, and helper text. Use WCAG 2.1 guidelines (AA or AAA level).
  • Font Size and Spacing: Use readable font sizes (at least 16px for body text is a good baseline) and provide adequate spacing between form elements.
  • Error Indication: Clearly indicate validation errors visually (e.g., red border) and programmatically (e.g., using aria-invalid and associating an error message via aria-describedby).
  • Responsiveness: Settings panels should be usable on different screen sizes.

Putting It Together (Static Example)

Here's a simplified, static representation of how a collection of accessible settings controls might be structured in TSX. Remember, this example uses defaultValue and defaultChecked because state management (`useState`) is not allowed in this context. A real application would manage these values dynamically.

Static Settings Panel Structure

&lt;div className="space-y-6"&gt;
  {/* Indentation Type */}
  &lt;div&gt;
    &lt;label htmlFor="indent-type-static" className="block text-sm font-medium text-gray-700 dark:text-gray-200"&gt;
      Indentation Type
    &lt;/label&gt;
    &lt;select
      id="indent-type-static"
      name="indent-type-static"
      defaultValue="spaces"
      className="mt-1 block w-full rounded-md border-gray-300 py-2 pl-3 pr-10 text-base focus:border-blue-500 focus:outline-none focus:ring-blue-500 sm:text-sm dark:bg-gray-700 dark:border-gray-600 dark:text-white"
    &gt;
      &lt;option value="spaces"&gt;Spaces&lt;/option&gt;
      &lt;option value="tabs"&gt;Tabs&lt;/option&gt;
    &lt;/select&gt;
  &lt;/div&gt;

  {/* Indentation Size */}
  &lt;div&gt;
    &lt;label htmlFor="indent-size-static" className="block text-sm font-medium text-gray-700 dark:text-gray-200"&gt;
      Indentation Size
    &lt;/label&gt;
    &lt;input
      type="number"
      id="indent-size-static"
      name="indent-size-static"
      min="0"
      max="10"
      defaultValue={2}
      className="mt-1 block w-full rounded-md border-gray-300 shadow-sm focus:border-blue-500 focus:ring-blue-500 sm:text-sm dark:bg-gray-700 dark:border-gray-600 dark:text-white"
      aria-describedby="indent-size-static-hint"
    /&gt;
    &lt;p id="indent-size-static-hint" className="mt-2 text-sm text-gray-500 dark:text-gray-400"&gt;
      Number of spaces or tabs.
    &lt;/p&gt;
  &lt;/div&gt;

  {/* Sort Keys */}
  &lt;div className="relative flex items-start"&gt;
    &lt;div className="flex h-6 items-center"&gt;
      &lt;input
        id="sort-keys-static"
        name="sort-keys-static"
        type="checkbox"
        defaultChecked={true}
        className="h-4 w-4 rounded border-gray-300 text-blue-600 focus:ring-blue-500 dark:border-gray-600 dark:bg-gray-700 dark:checked:bg-blue-600"
      /&gt;
    &lt;/div&gt;
    &lt;div className="ml-3 text-sm leading-6"&gt;
      &lt;label htmlFor="sort-keys-static" className="font-medium text-gray-900 dark:text-gray-100"&gt;
        Sort Object Keys Alphabetically
      &lt;/label&gt;
    &lt;/div&gt;
  &lt;/div&gt;

  {/* Example of another setting */}
  &lt;div&gt;
    &lt;label htmlFor="theme-static" className="block text-sm font-medium text-gray-700 dark:text-gray-200"&gt;
      Application Theme
    &lt;/label&gt;
    &lt;select
      id="theme-static"
      name="theme-static"
      defaultValue="system"
      className="mt-1 block w-full rounded-md border-gray-300 py-2 pl-3 pr-10 text-base focus:border-blue-500 focus:outline-none focus:ring-blue-500 sm:text-sm dark:bg-gray-700 dark:border-gray-600 dark:text-white"
    &gt;
      &lt;option value="light"&gt;Light&lt;/option&gt;
      &lt;option value="dark"&gt;Dark&lt;/option&gt;
      &lt;option value="system"&gt;System&lt;/option&gt;
    &lt;/select&gt;
  &lt;/div&gt;

&lt;/div&gt;

Notice the use of unique id attributes for each input, linked via htmlFor in the corresponding <label>. This is the cornerstone of accessible form controls.

Testing Accessibility

Building accessible interfaces requires testing.

  • Keyboard Test: Can you navigate through all settings using only the Tab and Shift+Tab keys? Can you interact with each control (change values, check boxes) using Space, Enter, and Arrow keys?
  • Screen Reader Test: Use a screen reader (like VoiceOver on macOS, NVDA or JAWS on Windows, or TalkBack on Android) to navigate the panel. Do labels correctly announce the purpose of each control? Is helper text read out?
  • Automated Tools: Use browser extensions (Axe DevTools, WAVE) or build tools (eslint-plugin-jsx-a11y) to catch common accessibility issues.
  • Color Contrast Analyzers: Verify sufficient color contrast.
Regular testing is key to ensuring and maintaining accessibility.

Conclusion

Implementing accessible settings panels for your JSON formatter is a crucial step towards creating an inclusive and user-friendly tool. By focusing on semantic HTML, correct labeling, keyboard navigation, and thoughtful visual design, you can ensure that all users, regardless of their abilities, can easily configure the formatter to suit their needs. Start with the basics: a linked <label> for every input, and build from there.

Need help with your JSON?

Try our JSON Formatter tool to automatically identify and fix syntax errors in your JSON. JSON Formatter tool