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

Feature: Enhance a11y #596

Open
mlmoravek opened this issue Sep 22, 2023 · 6 comments
Open

Feature: Enhance a11y #596

mlmoravek opened this issue Sep 22, 2023 · 6 comments
Labels
a11y Accessibility contributions welcome Any contribution and help is welcome

Comments

@mlmoravek
Copy link
Member

Description

Why Oruga need this feature

Accessibility is a big topic and a component library should implement a11y support by default as good as they can.

@mmazanec22
Copy link
Contributor

mmazanec22 commented Mar 6, 2024

I'm using Deque's axe for integration and e2e tests on a project that uses oruga (jest-axe for integration, axe via nightwatch for e2e). We recently bumped a few (edit: oruga) versions from 0.5.10 to 0.8.3. The change created several accessibility problems that jest-axe is catching, including:

  • incorrect aria in the steps component
  • incorrect aria in the switch component
  • nested interactive controls in the switch component

Adding axe to the tests for this project in addition to the recommendations above could help prevent future breaking updates.

@mlmoravek
Copy link
Member Author

@mmazanec22 I have no experience with axe. Would you like to make a PR with an example of how to use it?
However, you are always welcome to add some a11y improvements to the codebase :)

@mmazanec22
Copy link
Contributor

@mlmoravek I made an attempt with #846 and fixed an a11y issue in the steps component. If this looks like an ok approach, I'd be happy to continue with the other components that were flagged.

@mlmoravek
Copy link
Member Author

@mmazanec22 Since the axe setup is now merged, you are welcome to add more tests and suggest a11y improvements if you can :)

@mlmoravek mlmoravek added the contributions welcome Any contribution and help is welcome label Jun 13, 2024
@mlmoravek mlmoravek removed their assignment Jun 21, 2024
@jh0ker
Copy link

jh0ker commented Nov 13, 2024

Not sure if this belongs here or in a separate issue, but the Dropdown component can't be controlled using the keyboard.

According to https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-select-only/ users should be able to use the arrow keys to highlight items and scroll through the list, and select items using Enter or the spacebar. I believe this would require tracking the currently highlighted item using state.

A quick and "dirty" but simple solution could be to register a @keypress handler on the dropdown item like this:

function onKeyPress(event: KeyboardEvent): void {
    if (!isClickable.value) return;
    if (event.key === "Enter" || event.key === " ") {
        event.preventDefault();
        parent.value.selectItem(itemValue as T);
        emits("click", itemValue as T, event);
    }
}

This would at least allow using the dropdown using keyboard only, since it is currently possible to tab through the items (not following spec either, but well).

@mlmoravek
Copy link
Member Author

@jh0ker You are always welcome to make such a11y suggestions. And I think a new issue for each is better. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a11y Accessibility contributions welcome Any contribution and help is welcome
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants