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

A11y keyboard focus control for Menu Component #3601

Closed
DaveBest99 opened this issue Mar 14, 2017 · 1 comment
Closed

A11y keyboard focus control for Menu Component #3601

DaveBest99 opened this issue Mar 14, 2017 · 1 comment
Labels
Accessibility This issue is related to accessibility (a11y) needs: verification A member of the team needs to verify whether this issue is fixed P2 The issue is important to a large percentage of users, with a workaround

Comments

@DaveBest99
Copy link

Bug, feature request, or proposal:

Bug:
Some keys do not function as expected, and compound words are not capitalized for screen reader pronunciation.

What is the expected behavior?

Escape key should close the Menu, and letter keys should move focus to the next item that starts with that letter.

What is the current behavior?

Currently Escape and letter keys do nothing.

What are the steps to reproduce?

See below.

Providing a Plunker (or similar) is the best way to get the team to see your issue.
Plunker template: https://goo.gl/DlHd6U

What is the use-case or motivation for changing an existing behavior?

Creating a standard user experience.

Which versions of Angular, Material, OS, browsers are affected?

Using screen reader JAWS17 with browsers Firefox, Internet Explorer, and Google Chrome.

Is there anything else we should know?

The screen reader user experience follows:

  1. Press Tab key to move focus to the "more_vert" element.
    JAWS says "more_vert button menu", and the braille display shows "more_vert bmnu".
    This Menu component is a basic Menu with no subMenus for testing.
    This Menu component is identified as a Button Menu, and is expected to give a list of Buttons upon opening.
    Note, developers should be encouraged to use meaningful text labels. Although this is just an example "More_vert" is not explanatory. Also, if possible symbols should not be used in text labels, as "_" breaks up the speech. This is not an accessibility criteria, but rather a design guideline to establish a brand.

  2. Pressing Spacebar or Enter key will open the Menu.
    JAWS says "dialpad Redial to move through items press up and down arrows", and the braille display shows "mnu dialpad Redial".
    There are 3 Menu Items in the list identified as "role=menuitem", and 1 item is Disabled. The expected behaviour of these Menu list items when activated will be to update web page content. If identified as Buttons an action would be expected, and if identified as Links a new web page would be loaded. Developers should be encouraged to include text to describe purpose of the Menu.

  3. With the Menu open and the focus on the first list item.
    Press Up and Down arrow keys. JAWS rotates through the list of items as expected, but only announces those items that are not disabled.
    Since "voicemail Check voicemail" item "posinset=2" has "aria-disabled=true" and "tabindex=-1" it never gets focus, and thus the screen reader user will never know that it exists. This is a design specification, and many prefer to know that it is there and that it is Disabled.
    JAWS says and displays "dialpad Redial" and "notifications_off Disable alerts" as the user rotates through the list.
    Pressing Home key will move focus to the first item in the list, and pressing End key will move focus to the last item in the list.
    Pressing Tab and Shift+Tab key will collapse the Menu and move focus to the next and previous page element, as expected.
    However, pressing Escape key does nothing. Escape should close the Menu and leave the focus on the Menu element.
    Also, pressing a letter key does not move the focus to an item starting with that letter. That is, pressing "d" should move the focus to "dialpad Redial".
    Finally, developers should be encouraged to use proper words with capitalization to allow the screen reader speech pronunciation. This is a best practice and determined by the design specifications;
    The item "dialpad Redial" is hard to understand and should be "DialPad Redial".
    The item "notifications_off Disable alerts" should be "Notifications_Off Disable Alerts".

  4. When using Internet Explorer 11 the focus lands on the image of the Menu element.
    Press Tab key to move focus to the Menu element.
    JAWS says "more_vert button menu", but the braille display shows "more_vert img". This is due to the diference in the browser/screenReader API.
    MD-ICON aria-label=more_vert role=img class="material-icons mat-icon"

Resources: WAI-ARIA Authoring Practices 1.1
2.14 Menu or Menu bar
https://www.w3.org/TR/wai-aria-practices-1.1/#menu#h-menu
2.15 Menu Button
https://www.w3.org/TR/wai-aria-practices-1.1/#menu#h-menubutton

@mmalerba mmalerba added P2 The issue is important to a large percentage of users, with a workaround Accessibility This issue is related to accessibility (a11y) labels Mar 14, 2017
jelbourn added a commit to jelbourn/components that referenced this issue May 19, 2017
tinayuangao pushed a commit that referenced this issue May 22, 2017
@jelbourn jelbourn added the needs: verification A member of the team needs to verify whether this issue is fixed label Sep 19, 2017
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators May 29, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Accessibility This issue is related to accessibility (a11y) needs: verification A member of the team needs to verify whether this issue is fixed P2 The issue is important to a large percentage of users, with a workaround
Projects
None yet
Development

No branches or pull requests

4 participants