Using Arrow Keys in New Object Wizard Resulted in DOM Reload

[GraysonPeddie]

Issue Description
In Cockpit's New Object wizard, using arrow keys to select which type of object to create resulted in a change of context. A "change of context" simply means that if an up or down arrow key is pressed to select a previous or next option, the focus changes over to the close button; thus a "change of context" disorients users who must rely on keyboard for navigation. This is impactful for those who have motor impairments and can affect users who have mental or memory disabilities. This fails Web Content Accessibility Guidelines 2.2 Success Criterion 2.4.3 Focus Order. This also affects 3.2.2 On Input which is affected by DOM reload.

Package Version and Platform:

• Platform: Arch Linux rolling release
• Package and version: cockpit 364-1, 389-ds-base 3.3.0-1
• Browser Firefox

Steps to Reproduce

1. Login to Cockpit, open 389 Directory Server, and in an opened instance, navigate to LDAP Browser.
2. Navigate to any of the objects in the LDAP database.
3. Navigate to the menu next to the Distinguished Name and navigate to New.
4. Navigate to the radio buttons by using the TAB key. The focus outline does not seem to be visible in the dark theme (2.4.7, Level AA Focus Visible)
5. Press the down arrow key. Instead of selecting "Create a New Group", a "Create a new Organization Unit" is selected.
6. Observe the location of the focus outline. The focus is now in the Close button.
7. Navigate back to the set of radio buttons. "Create a new Organization Unit" should be selected.
8. Repeat the process by pressing the down arrow key to select "Create a new Role".
9. The "Close" button is now in focus.
10. Repeat this again with both the down and up arrow keys. Each time the arrow keys is pressed, the Close button always receives focus.
11. If any of the radio buttons are clicked other than what is selected, the close button may not receive the focus outline, but by activating the context menu FROM the keyboard (not the mouse) by pressing the menu key or by Shift+F10, the context menu shows up near the close button, which does receive focus, but again, no focus outline is shown because a pointing device such as a mouse is used.

Expected results
The focus must stay as they are within a group of radio buttons until the user presses the TAB or Shift+Tab key to get out of the group of radio buttons.

Screenshots

Additional Notes

While contemplating my thoughts and while preparing myself to get some sleep at the time of writing, I must have realized that the DOM within the dialog must have reloaded the radio buttons which causes the focus to redirect to Close button. I confirmed the entire dialog just flashed when using the down arrow key and sure enough, the DOM for the dialog got reloaded. Now to get some sleep because I have work tomorrow... (sigh)

[mreynolds389]

Thanks for the report! I reproduced it and fixed it:

diff --git a/src/cockpit/389-console/src/lib/ldap_editor/wizards/newEntry.jsx b/src/cockpit/389-console/src/lib/ldap_editor/wizards/newEntry.jsx
index 1fb95fdd4..ccddbb0c2 100644
--- a/src/cockpit/389-console/src/lib/ldap_editor/wizards/newEntry.jsx
+++ b/src/cockpit/389-console/src/lib/ldap_editor/wizards/newEntry.jsx
@@ -85,7 +85,7 @@ variant="custom" isInline
                             onChange={(event, _) => this.handleOnChange(_, event)}
                             label={_("Create a new User")}
                             description={_("Add a new User (inetOrgPerson objectClass)")}
-                            name="radio-new-step-start"
+                            name="user"
                             id="radio-new-step-start-1"
                         />
                         <Radio
@@ -105,7 +105,7 @@ variant="custom" isInline
                             onChange={(event, _) => this.handleOnChange(_, event)}
                             label={_("Create a new Organizational Unit")}
                             description={_("Add a new Organizational Unit")}
-                            name="radio-new-step-start"
+                            name="ou"
                             id="radio-new-step-start-3"
                         />
                         <Radio
@@ -115,7 +115,7 @@ variant="custom" isInline
                           onChange={(event, _) => this.handleOnChange(_, event)}
                           label={_("Create a new Role")}
                           description={_("Add a new Role (Filtered / Managed / Nested)")}
-                          name="radio-new-step-start"
+                          name="role"
                           id="radio-new-step-start-4"
                         />
                         <Radio
@@ -125,7 +125,7 @@ variant="custom" isInline
                             onChange={(event, _) => this.handleOnChange(_, event)}
                             label={_("Create a new custom Entry")}
                             description={_("Add a new entry by selecting ObjectClasses and Attributes")}
-                            name="radio-new-step-start"
+                            name="other"
                             id="radio-new-step-start-7"
                         />
                     </div>

I'll file a PR for this, and double check we aren't making this same mistake in other places...

[mreynolds389]

HMmm arrow keys don't work at all for me, but this fixes the Tab key behavior

[GraysonPeddie]

Can you test with a screen reader such as Orca in Linux? I believe speech output should tell you if you are in a group of radio buttons.

Update: Ah, I see what's happening with the name attributes in radio buttons:

name="user"
name="ou"
name="role" 
name="other"

Radio buttons that are part of the same group must have the same name. Without it, I can click in all the radio buttons and everything will be checked. The name of "radio-new-step-start" is fine. The issues with DOM reload is much deeper than just changing the name attribute for all the radio buttons. So the name change actually breaks the WCAG 1.3.1 Info and Relationships.

[mreynolds389]

Can you test with a screen reader such as Orca in Linux? I believe speech output should tell you if you are in a group of radio buttons.

Update: Ah, I see what you did there with the name attributes in radio buttons:

name="user"
name="ou"
name="role"
name="other"
Radio buttons that are part of the same group must have the same name. Without it, I can click in all the radio buttons and everything will be checked. The name of "radio-new-step-start" is fine. The issues with DOM reload is much deeper than just changing the name attribute for all the radio buttons. So the name change actually breaks the WCAG 1.3.1 Info and Relationships.

Previously the names were a mix of values, some being the same while Group was unique. For me it fixed the Tab issue with skipping items. If I set the name to be the same then "Tab" skips over all the radio buttons. I can not reproduce the DOM reload though. Again the arrow keys do nothing for me - not sure what is going on there. I'll try and look at this later today...

[GraysonPeddie]

Thank you for investigating, but I need to clarify that both Tab AND Arrow key navigation are accessibility requirements, not optional.

WCAG Standards for Radio Buttons:

• WCAG 1.3.1 Info and Relationships: Radio buttons must be semantically related (same name)
• WCAG 2.1.1 Keyboard: All functionality must be accessible via keyboard
• WCAG 2.4.3 Focus Order: Logical navigation patterns must be maintained

Standard Radio Button Behavior:

• TAB: Focuses the radio button group (first option)
• Arrow Keys: Navigate within the radio button group
• Screen readers rely on arrow keys for radio button navigation

The arrow keys not working for your test environment:

• This may indicate focus management or event handling issue
• I've observed the DOM reload which causes focus to jump to the Close button

Debugging Suggestion:
If you open DevTools (right-click on radio buttons → Inspect) and then interact with the radio buttons using arrow keys, you should be able to observe the DOM changes in real-time. This would help you see if the elements are being re-rendered and how focus behaves during interaction.

Recommendation:
The fix should properly implement radio button semantics and focus management, not choose between Tab vs Arrow keys. Both must work for accessibility compliance.

[mreynolds389]

Ok, well changing the Radio buttons to use the same name fixes the Tab issue. Sorry at first I thought Tab should move within the Radio group.

Now we do use Patternfly for all these components, so I wonder if the reload issue is related to PF ? Anyway I'll try and look into this deeper soon. I already have other tasks I need to work on first.

[GraysonPeddie]

While looking into this issue, I checked the Patternfly documentation for radio button keyboard behavior, and it states:

Standard keyboard navigation can be used to navigate between radios within a group. Right Arrow and Down Arrow moves focus to the next radio within the radio group, or to the first radio if focus is currently on the last one in the group, and checks the newly focused radio.

This suggests that Patternfly's radio component should support proper arrow key navigation without requiring DOM re-renders. The DOM reload I'm observing might be related to how the Patternfly component is being implemented in the Cockpit code rather than an issue with Patternfly itself.

[GraysonPeddie]

For those who may not be familiar with HTML and for those who are new to web development and accessibility, I created a simple HTML demonstration that shows the difference between properly and improperly configured radio buttons. It uses the same questions we're dealing with, but demonstrates why the name attribute matters.

You can test it yourself - it shows:

• Proper radio button group (all have same name="objecttype")
• Improper radio buttons (each has unique name attribute)

When testing with keyboard navigation, you'll see why the single name attribute is essential for accessibility and proper behavior.

howradiobuttonswork.html

This demonstrates why radio buttons need the same name attribute to form a proper group, not just for accessibility but for the expected behavior users expect.

[mreynolds389]

So the arrow keys do work for me, but what I see is that once I use an arrow key it changes the focus to a different component. So you can't seamlessly go up and down through the buttons without having to re-focus on the radio button group. This appears to be by design, but I need to confirm that...

[GraysonPeddie]

Thanks for testing! What you're describing - arrow keys moving focus out of the radio group - actually confirms this is a focus management issue, not intended behavior.

Standard radio button keyboard behavior is:

• Arrow keys: Navigate WITHIN the radio button group (seamlessly move up/down)
• Tab key: Enter or EXIT the radio button group

What you're observing:

• Arrow keys are moving focus OUT of the radio group
• This forces users to constantly re-find the radio button group
• This breaks the standard navigation pattern keyboard users expect

Why this matters:

• Screen readers expect arrow key navigation within radio groups
• Power users expect efficient movement between options
• This creates unnecessary steps for keyboard users

WCAG 2.4.3 Focus Order requires logical, predictable navigation, and having arrow keys exit the radio group is the opposite of expected behavior.

Could we investigate why the arrow key events are causing focus to leave the radio button group?

[mreynolds389]

Yes we will work on this, but TBH it's low priority at the moment. It will probably get triaged next week, and we'll go from there.