Google Chrome: Label not rendered in browse mode for radio buttons and check boxes

[nvaccessAuto]

Reported by ateu on 2011-06-13 00:22
Hello,

I know all Google Chrome accessibility problems. But thise which here I'll describe, I think it ccan be fixed, becose I have been compared using others screen readers, like system Access and Jaws 12.
NVDA anounce headins twice when h is pressed in brows mode.
This is an older problem.
It's not possible read the typed content in the adressbar and some editfields.
When navigating using arrow keys, NVDA doesn't reads the text of checkboxes.
forgive me if i'm wrong and it cannot be fixed.
Blocking #3569

[nvaccessAuto]

Comment 1 by ateu on 2011-07-30 14:46
Since chrome 14 was released, it is possible read editfields.
But it's not possible read adress bar content.
In some chekboxes it's not possible read their texts.
Also persists the problem where headins are announced twices when h is pressed in brows mode.
Just one defect no longer exists.

[nvaccessAuto]

Comment 2 by ateu on 2011-10-24 17:16
In Google Chrome canary 17, now it is possible read the tiped content in adress bar, and NVDA automatically switch to focus mode in combo boxes.
For now, Google Chrome is almost 100% accessible with NVDA.
The problems that persists is the double announce of headings when pressing h in browse mode and in some chec boxes, content is not announced.

[nvaccessAuto]

Comment 3 by Ahiiron (in reply to comment 2) on 2011-10-24 19:47
Replying to ateu:

In Google Chrome canary 17, now it is possible read the tiped content in adress bar, and NVDA automatically switch to focus mode in combo boxes.

For now, Google Chrome is almost 100% accessible with NVDA.

The problems that persists is the double announce of headings when pressing h in browse mode and in some chec boxes, content is not announced.

These bugs are known, have a look at the following and please comment and vote so they gain higher priority.
headings double reading:
http://crbug.com/100491

Not all text on webpages seen by NVDA:
http://crbug.com/99246

[nvaccessAuto]

Comment 4 by ateu on 2011-11-11 18:08
Hi,

I'd really like hear Mick or Jamie about it: Are they really problems due to a chrome bug?
headings double reading;
Content in checkboxes is not announced.

[nvaccessAuto]

Comment 5 by ateu on 2012-03-07 16:38
Hi,

I'd like you investigate the problem with reading chekbox content and announce of title.
Although is not possible read the title, when using read corrent navigator object command in chrome, this information is spoken.
With respect the chekboxes, activating focus mode, their content is announced. Therefore, I think this feature may be implemented.

Furgive me if I am wrong.

Thanks

[nvaccessAuto]

Comment 6 by ateu on 2012-08-03 22:52
Corrently, testing with jaws, the headings are not announced twices. Also, the content in checkboxes are spoken. This means such problems can also be fixed in NVDA?

[nvaccessAuto]

Comment 7 by jteh on 2012-08-04 10:23
JAWS uses a different API to access both Chrome and Firefox. We might be able to work around these issues/differences in Chrome, but debugging and doing this is low priority for us given other work. It's worth noting that we use the same code for Firefox and Chrome and it works correctly in Firefox.

[nvaccessAuto]

Comment 8 by ateu on 2012-08-19 14:16
Hi,

In chrome 16 was possible read the title with NVDA+T.
After chrome 17, this command has stoped working.
What may be specifically changed in chrome to cause this?

[nvaccessAuto]

Comment 9 by jteh (in reply to comment 8) on 2012-08-19 23:01
Replying to ateu:

In chrome 16 was possible read the title with NVDA+T.

After chrome 17, this command has stoped working.

What may be specifically changed in chrome to cause this?

Technical: IAccessible::accName on the Chrome application accessible no longer includes the title of the document, even though its window accessible still does.

[nvaccessAuto]

Comment 10 by jteh on 2012-08-31 06:18
Headings no longer read twice as of 5f3402e.

[nvaccessAuto]

Comment 11 by ateu on 2012-09-25 10:21
Jamie, a question:

Is it possible use MSHTML or Webkit instead of geckoIa2 in chrome app module?

[nvaccessAuto]

Comment 12 by jteh on 2012-09-25 10:31
No. The !WebKit buffer only uses MSAA and therefore doesn't provide a lot of functionality. It's also very specific to !WebKit's idiosyncrasies. Chrome doesn't implement the MSHTML interfaces. IA2 is the best way to access it. Also, Chrome have mostly modelled Gecko anyway.

[nvaccessAuto]

Comment 14 by jteh on 2012-10-15 04:18
Iirc, the only issue left from this ticket is rendering of checkboxes and radio buttons in browse mode. This is due to the fact that Chrome doesn't include label elements in its accessibility tree, but Firefox does. We prefer to render the actual label element because then we get formatting, etc. However, this is probably a !WebKit decision that isn't likely to be changed, so I'm leaving this open for now.

I'm narrowing the scope of this ticket to just this one issue. Regarding further Chrome issues, Chrome uses IAccessible2, as does Firefox, so it should be exposing content in pretty much the same way. Therefore, any remaining issues are almost certainly due to issues in Chrome, not NVDA. Unless you have reason to suspect otherwise, please file these as bugs against Chrome.
Changes:
Changed title from "Problems With Google Chrome" to "Google Chrome: Label not rendered in browse mode for radio buttons and check boxes"

[nvaccessAuto]

Comment 15 by ateu on 2012-10-16 15:17
Changing from defect to enhancement as this is not a regression.

[nvaccessAuto]

Comment 16 by jteh on 2012-10-16 23:16
Doesn't have to be a regression to be a defect. :)

[nvaccessAuto]

Comment 17 by ateu (in reply to comment 7) on 2013-02-23 18:41
Replying to jteh:

JAWS uses a different API to access both Chrome and Firefox. We might be able to work around these issues/differences in Chrome, but debugging and doing this is low priority for us given other work. It's worth noting that we use the same code for Firefox and Chrome and it works correctly in Firefox.

Are you sure jaws uses different APIs for chrome and firefox?
See this:

1. When I press insert+q, jaws announces: firefox settings are loaded.
2. The code that makes chrome to work are incide files for firefox, e.g., firefox.jsb, firefox.jsm, etc.

[nvaccessAuto]

Comment 18 by jteh on 2013-02-24 00:59
I said "JAWS uses a different API to access both Chrome and Firefox". To word it another way, JAWS uses ISimpleDOM to access both Firefox and Chrome, whereas NVDA uses IAccessible2 to access both Firefox and Chrome. There are advantages to using IAccessible2 which are beyond the scope of this ticket, but suffice to say that we won't be changing to ISimpleDOM for this ticket. I do know of another way to work around this, but it'll have to wait for now.

[nvaccessAuto]

Comment 19 by ateu (in reply to comment 18) on 2013-02-24 01:21
Replying to jteh:

I said "JAWS uses a different API to access both Chrome and Firefox". To word it another way, JAWS uses ISimpleDOM to access both Firefox and Chrome, whereas NVDA uses IAccessible2 to access both Firefox and Chrome. There are advantages to using IAccessible2 which are beyond the scope of this ticket, but suffice to say that we won't be changing to ISimpleDOM for this ticket. I do know of another way to work around this, but it'll have to wait for now.

I'm sorry. Now I understud.
Although is not part of this ticket, do you know the way used by system access?
I'm asking you about this, as interestingly, system access works fine with all chrome based browsers, including BlackHawk, Rockmelt, Comodo Dragon, SRWare Iron, Coolnovo, etc.

[nvaccessAuto]

Comment 22 by jteh on 2013-11-06 05:41
Changes:
Milestone changed from None to next

[nvaccessAuto]

Comment 23 by James Teh <jamie@... on 2013-11-06 05:42
In [d0e41b9]:

In browse mode in Google Chrome, the labels of check boxes and radio buttons are now rendered correctly.

The Gecko vbuf backend now uses the name as the content for these controls if their labels aren't visible.
Re #1562.

[nvaccessAuto]

Comment 24 by James Teh <jamie@... on 2013-11-06 05:43
In [41453b3]:

Merge branch 't1562' into next

Incubates #1562.

Changes:
Added labels: incubating

[nvaccessAuto]

Comment 25 by James Teh <jamie@... on 2013-11-26 22:44
In [3b2bd36]:

In browse mode in Google Chrome, the labels of check boxes and radio buttons are now rendered correctly.

The Gecko vbuf backend now uses the name as the content for these controls if their labels aren't visible.
Fixes #1562.

Changes:
Removed labels: incubating
State: closed

[nvaccessAuto]

Comment 26 by jteh on 2013-11-26 23:04
Changes:
Milestone changed from next to 2014.1

[nvaccessAuto]

Attachment home-icon.gif added by reanim888 on 2014-10-26 12:02
Description:
Sam O'neal