Skip to content

feat(a11y): Add focus to model select and improve visibility in submenus #6645

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

derekjackson-das
Copy link
Collaborator

Summary

With the new model select component focus was no longer visible when it was the active element because there were multiple focus-visible styles with more specificity than the applications global style. I removed the styles so the focus-visible style matches the applications overall style and in light and dark modes.

Further improved the visibility of menu and sub-menu options so that contrast meets new Web Content Accessibility Guidelines and older non-text contrast requirements.

Please review the submenu items as it does effect the visual style.

Files touched:

  • client/src/styles.css
  • client/src/components/Chat/Menus/Endpoints/CustomMenu.tsx
  • client/src/components/Chat/Menus/Endpoints/ModelSelector.tsx

Screen recording of the focus change: https://share.zight.com/v1uz68vy

Screenshot 2025-03-31 at 3 16 10 PM Screenshot 2025-03-31 at 3 00 42 PM Screenshot 2025-03-31 at 3 16 04 PM Screenshot 2025-03-31 at 3 00 56 PM

Change Type

Accessibility

  • Bug fix (non-breaking change which fixes an issue)

Testing

Please describe your test process and include instructions so that we can reproduce your test. If there are any important variables for your testing configuration, list them here.

Manual Keyboard and Automated (axe dev tools) accessibility testing.

Test Configuration:

Chrome/MacOS
Firefox/MacOS

Checklist

Please delete any irrelevant options.

  • My code adheres to this project's style guidelines
  • I have performed a self-review of my own code
  • My changes do not introduce new warnings

@derekjackson-das derekjackson-das linked an issue Mar 31, 2025 that may be closed by this pull request
@berry-13 berry-13 marked this pull request as draft April 11, 2025 16:58
@berry-13
Copy link
Collaborator

Hey @derekjackson-das, with ARIA comboboxes/listboxes, dropdown items never get real DOM focus, focus stays on the input, and the options just use aria-activedescendant. Because of this, we can’t show a focus ring (like :focus-visible) only for keyboard users on the options. WCAG (see this issue) says it’s fine to always show a visible highlight (like a background or border) for the active item, as long as it’s big enough and has good contrast, that counts as the “focus indicator”. So, it’s actually correct that it shows up for both mouse and keyboard without a focus ring

let me know your thoughts on this

@derekjackson-das
Copy link
Collaborator Author

derekjackson-das commented Apr 15, 2025

Hey @berry-13! Thanks for reviewing this PR! And apologies, I did not describe the root of the issue well. I wasn't thinking of this as a technical issue and meeting Success Criteria (SC) in WCAG but rather making sure important UI is visible.

The issue I meant to address in this PR was that the indicator for the current active element in the new LLM menu, the highlight color, did not provide enough contrast. While we can probably say we technically meet the Success Criteria outlined in WCAG 2.1, I think of those as the bare minimum. There is often a lot of room for improvement still. Because the guidelines for non-text contrast of important elements is a minimum of 3:1 and we also have user testing that demonstrates people with low vision could not identify the LLM they were choosing due to the low contrast I suggested this update. So I approached this thinking about usability and best practice. I find the updates in WCAG 2.2 on focus requirements and the WCAG 2.1 non-text contrast criteria point us in good direction of having the indicator meet the 3:1 contrast at a minimum.

You are right about focus in the browser and the :focus pseudo-classes not fitting this component exactly ... the outline indicator is not available on elements that don’t get proper browser focus so I added the outline to an active element, but it is not the only way to indicate the currently active element and there are definitely other good solutions.

For example, using the highlight as the focus indicator on its own is a good solution but some users need it to be more visibly apparent. One good example of this type of indicator are the menus we see in operating systems.
Mac OS showing the operating system menu and a submenu. A blue highlight with white text on a grey background clearly indicates the current active item in the sub menu.

Another approach could be an icon or graphic that indicates the current, active element, like a line or symbol.
The LibreChat LLM menu is expanded showing a solid, vertical black line along the left side of a menu item indicated which options are currently active.

What do you think? Could we improve the visibility of these options in the menus? And do you have another preference that we should use to make them more visible? If the outline is not ideal I could work on something else. This was just the solution I immediately gravitated to.

However, the focus is missing from the main "select a model" menu button in light mode so we should at least fix that, yes? I could also separate the PR into two, one for focus on the main menu and one for navigation in the sub-menu while looking at other ways to improve contrast/visibility in the sub-menus.

@derekjackson-das derekjackson-das added the ♿ a11y Accessibility label Apr 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
♿ a11y Accessibility
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Focus visible on model menu selection
2 participants