WIP: Bricks form accessibility issues - Radio and Checkbox

Browser: Chrome 120.0.6099.129
OS: Windows
URL: Daveden Test Page
Video:

I feel that the Bricks Form Element exhibits some accessibility issues, one of which is the Radio Field and Checkbox Field. Below is the current HTML output for the radio which is similar to the checkbox field:

<div class="form-group">
   <label>Radio Group</label>
   <ul class="options-wrapper">
      <li>
         <input type="radio" id="form-field-khlmly-0" name="form-field-khlmly[]" required="" value="David">
         <label for="form-field-khlmly-0">David</label>
      </li>
      <li>
         <input type="radio" id="form-field-khlmly-1" name="form-field-khlmly[]" required="" value="John">
         <label for="form-field-khlmly-1">John</label>
      </li>
   </ul>
</div>

This structure doesn’t align with recommended HTML patterns outlined in MDN and W3C.

I believe we should either use <fieldset> and <legend>
or <div role=radiogroup aria-labelledby="label id">, and the <label> should be using a different HTML tag like an <h3>.

Otherwise, the group name is not announced to screen readers.

@Daveden2 Thank you for your report and you’re right again. I created a task so we can tackle this.

1 Like

Hi David,
We’ve fixed this issue in Bricks 1.9.5, now available as a one-click update in your WordPress Dashboard.

Changelog: Bricks 1.9.5 Changelog – Bricks
Please let us know if you are still experiencing issues.

I’m still uncertain that the radio field and checkbox have been properly solved.

Radio Field Issues

Here’s the current markup for the radio field when the “show labels” toggle is not active:

and here’s how it looks when we toggle show labels on:

Here are a couple of issues noticed:

  1. We should not be using ul > li and label HTML tags. Instead, we should use <fieldset> and <legend> or simple divs. See A11y Style Guide, Deque University and MDN
  2. The role=“radiogroup” should be on the wrapper enclosing both the label (ideally an h3, div or user-configurable) and the radio items. Currently, AxeDevTools is throwing an error because the role=“radiogroup” is applied to the <ul>

Checkbox Field Issues

We have a similar issue with Checkboxes.

  1. When we toggle “show label”, then the id is removed from the label.
  2. The role=“group” should be on the wrapper containing both the label and the checkboxes, not the <ul>. AxeDevTools is throwing a similar error about role=“group” is not allowed on a <ul>
  3. The best option is to use a <fieldset> and <legend> as shown on the A11y Style Guide.

Hi @Daveden2,

You’re right they’re not ideal yet. I’ve marked this as a WIP.

There’s also still an issue with the “form group” label, which should ideally not be a label.

1 Like

Hi David,
We’ve fixed this issue in Bricks 1.9.6, now available as a one-click update in your WordPress Dashboard.

Changelog: Bricks 1.9.6 Changelog – Bricks

Please let us know if you are still experiencing issues.

Best regards,
timmse

1 Like

I’ve the same problem with Bricks 1.12.3
Also the Honeypot Field shows a problem with Axe Dev Tools.

Fixed both with a JS Snippet below the form:

// Function to modify the aria-labelledby attribute and remove autocomplete="nope"
function modifyAttributes() {
  // Part 1: Modify aria-labelledby attributes
  // Find all elements in the document with an aria-labelledby attribute
  const labelledElements = document.querySelectorAll('[aria-labelledby^="label-"]');
  
  let labelledCount = 0;
  // Iterate through all found elements
  labelledElements.forEach(element => {
    // Get the current value
    const currentValue = element.getAttribute('aria-labelledby');
    
    // Replace "label-" with "form-field-" and append "-0" if not already present
    let newValue = currentValue.replace('label-', 'form-field-');
    if (!newValue.endsWith('-0')) {
      newValue = newValue + '-0';
    }
    
    // Set the new value
    element.setAttribute('aria-labelledby', newValue);
    
    labelledCount++;
  });
  
  // Part 2: Remove autocomplete="nope" from ALL text fields (it's added automatically to Honeypot fields)
  const textInputs = document.querySelectorAll('input[type="text"]');
  
  let autocompleteCount = 0;
  // Iterate through all found text inputs
  textInputs.forEach(input => {
    // Only remove if autocomplete="nope"
    if (input.getAttribute('autocomplete') === 'nope') {
      // Remove the autocomplete attribute
      input.removeAttribute('autocomplete');
      
      autocompleteCount++;
    }
  });
  
}

// Execute the function
modifyAttributes();

Hi,

I’ve added an internal task to improve that, and change the value from “nope” to “off”, when using a Honeypot field.

We will update the topic, once we release a fix.

Best regards,
Matej