Open Bug 1780081 Opened 3 years ago Updated 2 years ago

NVDA (or any screen readers) does not specify when a Fx's menu buttons have sub-menu buttons

Categories

(Firefox :: Menus, defect, P3)

Desktop
All
defect

Tracking

()

Accessibility Severity s3

People

(Reporter: danibodea, Unassigned, NeedInfo)

Details

(Keywords: access)

Attachments

(1 file)

Note

  • When the user navigates through the menu buttons, he might not notice that some buttons have sub-menu buttons.

** Found in**

  • Nightly v104.0a1

Affected versions

  • Nightly v104.0a1

Affected platforms

  • all

Steps to reproduce

  1. Have NVDA running in the background.
  2. Navigate to the "Hamburger menu"/"main menu" button and open it.
  3. Navigate through the menu and observe how NVDA reads "Bookmarks", History, More tools and Help.

Expected result

  • Notice that there is no reference to the fact that the button opens a sub-menu.

Actual result

  • The screen readers only read the button text and its position in its group of buttons.

Regression range

  • Not a recent regression.

Additional notes

  • This issue occurs the same in any of the screen readers/OSes tested.

Visual representations of button locations.

I'm assuming this requires some aria-markup - do we just need aria-expanded="false" and aria-haspopup=true or is that insufficient?

Type: enhancement → defect
Flags: needinfo?(jteh)

aria-haspopup="true" is sufficient. Strictly speaking, we could also add aria-expanded="false", but I don't think it provides any benefit to the user here, while it does add extra verbosity for screen reader users.

Flags: needinfo?(jteh)

(In reply to James Teh [:Jamie] from comment #3)

aria-haspopup="true" is sufficient. Strictly speaking, we could also add aria-expanded="false", but I don't think it provides any benefit to the user here, while it does add extra verbosity for screen reader users.

Thanks. And, sorry, should have thought of this immediately - for webextension buttons in the overflow panel, we don't really know if they will open a subview or not. This is also a problem for sighted users - bug 1403666. Visually, we never show an arrow on them, which would normally indicate a subview would open - but it might not, we don't know until the user clicks on it and the webextension tells us. The other visual option would be to always show an error, while in some cases then no subview would open. I assume it is OK that, given we don't know, we'd err in the same direction for webextension buttons (ie not having aria-haspopup=true) ?

Flags: needinfo?(jteh)
Whiteboard: [access-s3]

(In reply to :Gijs (he/him) from comment #4)

I assume it is OK that, given we don't know, we'd err in the same direction for webextension buttons (ie not having aria-haspopup=true) ?

Agreed. Ideal or not, sighted and a11y API users get the same experience here.

Flags: needinfo?(jteh)
Flags: needinfo?(gijskruitbosch+bugs)
Priority: -- → P3
Accessibility Severity: --- → s3
Whiteboard: [access-s3]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: