New issue
Advanced search Search tips

Issue 606937 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: May 2016
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 2
Type: Bug
Team-Accessibility



Sign in to add a comment

ChromeVox does not honor WAI-ARIA roles

Reported by johannes...@flachware.com, Apr 26 2016

Issue description

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

Steps to reproduce the problem:
1. Create a HTML document.
2. Add <h1 role="presentation"> Sample Content </h1> to the body.
3. Let ChromeVox read the content and/or navigate to the headline using the jump command

What is the expected behavior?
According to the WAI-ARIA specification (https://www.w3.org/TR/wai-aria/roles#presentation), role="presentation" should negate the implicit 'heading' role semantics.

What went wrong?
The heading is still verbalized as heading and is reachable using a heading jump command

Did this work before? N/A 

Chrome version: 50.0.2661.86  Channel: stable
OS Version: OS X 10.9.5
Flash Version: Shockwave Flash 21.0 r0
 
Components: -UI UI>Accessibility
Labels: OS-Chrome OS-Linux OS-Windows
Status: Untriaged (was: Unconfirmed)
Confirmed on Chrome 50.0.2661.86 and 51.0.2704.29.
Status: WontFix (was: Untriaged)
This is fixed in ChromeVox Next, which is in beta now. See here for more info:

http://www.chromevox.com/next.html

Marking this as WontFix since that version will be coming to all users as soon as possible.

Thank you for your confirmation.

Sign in to add a comment