Skip to content
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

Limit results by section is not accessible with tabkey navigation #4719

Closed
3 tasks
christinach opened this issue Jan 23, 2025 · 4 comments · Fixed by #4732
Closed
3 tasks

Limit results by section is not accessible with tabkey navigation #4719

christinach opened this issue Jan 23, 2025 · 4 comments · Fixed by #4732
Assignees
Labels
accessibility A Web Content Accessibility Guidelines (WCAG) - Level A is the minimum level high priority High priority work

Comments

@christinach
Copy link
Member

Steps to recreate

Go to https://catalog.princeton.edu/advanced
Use the tabkey to find the Limit results fields : Access, Format, Language, Holding Location
Press the up or down arrow. The list will not expand.
Press spacebar. The list will expand. Press the Up or Down arrow you cannot select an item from the list.

URL

https://catalog.princeton.edu/advanced

Issues

Cannot use the 'Limit results by' section with tabkey or voiceover

Severity

High

WCAG Conformance level (A, AA, AAA)

A
Success Criterion 2.1.1 Keyboard

User impact

Content cannot be operated through a keyboard

Recommended fix

Acceptance criteria

  • I can successfully use this feature with Voice Over in Safari.
  • I have checked this feature using one of the following browser extensions and confirmed that it does not add any level A or level AA issues:
    • axe dev tools
    • Lighthouse
    • Wave
  • ...

Notes

@christinach christinach added accessibility A Web Content Accessibility Guidelines (WCAG) - Level A is the minimum level high priority High priority work labels Jan 23, 2025
@maxkadel maxkadel self-assigned this Jan 24, 2025
@maxkadel
Copy link
Contributor

From what I've seen so far, it looks like the keyboard event listeners are not being added correctly. The keyup listener code is never reached, and the block inside this.inputElement.addEventListener is never reached.

One thing to note is that there are two addEventListener methods, one public and one private. The private one is the one in the class, the public one, which is called on the inputElement, is standard JavaScript.

@maxkadel
Copy link
Contributor

In the working commit (38d7442), which is still on Bootstrap 4, we're using the class "form-group", and it is firing the keyup event. We want to look at the javascript from this version of Bootstrap to see how it is querying the item and the class. It's possible it cannot add the event on the element in Bootstrap 5.

See also: Bootstrap 5 migration notes - dropdown breaking change.

@maxkadel
Copy link
Contributor

In the working version (Bootstrap 4), when you add an event listener breakpoint, you hit a jquery3.source.js, and we think we don't hit any jquery in the non-working (Bootstrap 5) version. Bootstrap 5 does not require jquery, but can be used with jquery.

return typeof jQuery !== "undefined" && jQuery.event.triggered !== e.type ?

@maxkadel
Copy link
Contributor

It appears that the change was in the dataApiKeydownHandler in Bootstrap 5, where it does not navigate using the arrow keys on inputs. See Bootstrap issue for discussion - it is not considered a bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accessibility A Web Content Accessibility Guidelines (WCAG) - Level A is the minimum level high priority High priority work
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants