New issue
Advanced search Search tips

Issue 873111 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 820351
Owner:
Closed: Aug 10
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome , Mac
Pri: 2
Type: Bug



Sign in to add a comment

web-bluetooth API chooser does not meet WCAG standards

Reported by t...@nyu.edu, Aug 10

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36

Steps to reproduce the problem:
1. instantiate the web-bluetooth   navigator.bluetooth.requestDevice() command
2. turn on a screen reader for blind users
3. attempt to access the popup window that results from the requestDevice() call.

What is the expected behavior?
The screen reader should be able to read a list of available devices. However, the web-bluetooth chooser's main component is an empty table, and screen readers cannot access the content inside (I am testing with the MacOS built-in screen reader at the moment)

What went wrong?
The screen reader in use could not access the list of bluetooth peripherals returned. 

Did this work before? No 

Does this work in other browsers? N/A

Chrome version: 68.0.3440.106  Channel: stable
OS Version: OS X 10.12.6
Flash Version: 

the web-bluetooth API.
 
Components: Internals>Views
Labels: Needs-Feedback
Thanks for your report. Do you have a test page?

Comment 2 by t...@nyu.edu, Aug 10

Sure, here you go. Clicking the connect button in chromium will trigger the
chooser in question:


https://htmlpreview.github.io/?https://raw.githubusercontent.com/tigoe/TS04-Bluetooth-Meter/master/index.html


sent in transit, please excuse brevity or typos.
Project Member

Comment 3 by sheriffbot@chromium.org, Aug 10

Cc: ellyjo...@chromium.org
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Cc: reillyg@chromium.org
The Web Bluetooth and WebUSB APIs share the same chooser UI. Both can be exercised on https://permission.site.
Status: Untriaged (was: Unconfirmed)
Confirmed that despite there being entries in the chooser prompt VoiceOver sees the table is empty.

Elly, should this be in the Internals>Views component or UI>Accessibility?
Labels: M-71 Target-71
Owner: lgrey@chromium.org
Status: Assigned (was: Untriaged)
Internals>Views and it should go to lgrey@.
Labels: OS-Chrome
Tried in ChromeVox and it while it offers an option to navigate the table by cell (it doesn't say the table is entry) that doesn't seem to actually work. Clicking on a cell or navigating with the regular arrow keys does speak the table rows.
Mergedinto: 820351
Status: Duplicate (was: Assigned)
Checking in to see if there has been any progress on this issue in the past few months. Web-bluetooth is still inaccessible to readers using the MacOS screen reader, and probably others as well (I've only had the chance to test MacOS, see my comments above).

While I realize security is important, so is accessibility.
Work on the underlying issue in the UI framework (issue 811277) is underway.

Sign in to add a comment