Issue metadata
Sign in to add a comment
|
Chrome Privacy error screen inaccessible |
||||||||||||||||||||||||||
Issue descriptionChrome Version: 61.0.3122.0 (Official Build) canary(64-bit) OS: Windows 10 Version 1703 (OS Build 16199.1000) 64-bit What steps will reproduce the problem? (1) Start the NVDA screen reader. (2) Start Chrome. (3) Open this address: https://revoked.grc.com/ (4) Tab through the controls on the resulting "Privacy error" screen. What is the expected result? The controls on the screen should be reported by NVDA. What happens instead? NVDA reports only "unknown". Additional info: Accessible focus events are being fired. The child ids are negative numbers, which suggests that they're unique ids and that there is actually an accessibility implementation there somewhere. However, WM_GETOBJECT returns 0 for OBJID_CLIENT. At a guess, I'd say the window proc needs to be fixed to handle WM_GETOBJECT for that window. Related NVDA issue: https://github.com/nvaccess/nvda/issues/6541
,
Jun 12 2017
Eh, sorry. This is the SSL interstitial, not the SB one.
,
Aug 2 2017
Assigning to estark@ to get this sorted out.
,
Aug 4 2017
,
Aug 4 2017
,
Aug 8 2017
@estark, can you add any notes on how this might be fixed, that you know of? As I tab into the window with NVDA, I hear "Chrome Legacy Window" and "unknown" as I move between links. We really shouldn't have any black holes in our access -- it becomes a compliance issue and is disheartening for screen reader users when they have no idea what it says.
,
Aug 8 2017
Not accessible in JAWS either.
,
Aug 8 2017
I think the issue here is that WebContentsImpl is showing an interstitial, but it's not accessing the accessibility tree for the interstitial page instead of the RFHI that's underneath it.
,
Sep 4 2017
I'm very sorry for missing this bug. We have a refactor in progress for how interstitials work that should fix this (see issue 448486). For SSL certificate errors, I estimate that this will be done sometime in mid-Q4 or so. Since this bug is marked P3, I'm going to assume that it's okay to wait for that to work to fix this -- but if anyone feels that we should prioritize a fix for this before then, happy to discuss more.
,
Nov 10 2017
,
Nov 15 2017
@dmazzoni, would you like to take on this bug? Seems to be unrelated to the bug I fixed recently with dialogs. Feel free to assign to me or Aaron if you don't have time.
,
Nov 17 2017
I would like to see this issue fixed ASAP. For a blind person who tests websites or does system admin work, being able to read these security notices is critical. I'm currently building a new server. Since I'm using self-signed certs initially, Chrome is completely unusable to me.
,
Dec 4 2017
I completely agree with comment #12. In my case I do need to have access to content under unsigned certificates, tso it becomes necessary to interact with this windows in a daily basis. At this point I simply cannot use chrome for these purposes. Each time the browser considers a certificate to be unsecure, we're done as blind users since there is nothing we can do to add an exception that lets us get into the content. I think this fix should be of a maximum priority if we want chrome to be a serious and reliable alternative, both at a personal and at a proffessional levels.
,
Dec 14 2017
,
Dec 14 2017
Upping priority
,
Dec 15 2017
,
Dec 15 2017
Issue 793875 has been merged into this issue.
,
Dec 15 2017
This isn't actually a dialog. I'm working on this now.
,
Dec 15 2017
Issue 678603 has been merged into this issue.
,
Dec 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/efb5f9e3bfda6dd47f186ba731b9fc7428ab626f commit efb5f9e3bfda6dd47f186ba731b9fc7428ab626f Author: Dominic Mazzoni <dmazzoni@chromium.org> Date: Thu Dec 21 01:08:22 2017 Make interstitial pages accessible. WebContentsImpl maintains both a real page, and also optionally an interstitial page that's shown instead of the main page if the site isn't safe. The interstitial wasn't accessible, we were still exposing the main page via accessibility APIs even if an interstitial was showing visually. This change modifies WebContentsImpl so that if an interstitial is visible, that interstitial is exposed instead of the main page, matching what's shown visually. When an interstitial is attached or detached, ensure that focus events are fired, and ensure that the page hidden by the interstitial can't fire any accessibility events. Adds a browser test to ensure this works. Bug: 730910 Change-Id: I471ca92c0563fb803ada182edd96675d0a9a0cad Reviewed-on: https://chromium-review.googlesource.com/830619 Reviewed-by: Jochen Eisinger <jochen@chromium.org> Reviewed-by: Nektarios Paisios <nektar@chromium.org> Reviewed-by: Emily Stark <estark@chromium.org> Commit-Queue: Dominic Mazzoni <dmazzoni@chromium.org> Cr-Commit-Position: refs/heads/master@{#525545} [add] https://crrev.com/efb5f9e3bfda6dd47f186ba731b9fc7428ab626f/chrome/browser/accessibility/interstitial_accessibility_browsertest.cc [modify] https://crrev.com/efb5f9e3bfda6dd47f186ba731b9fc7428ab626f/chrome/browser/ssl/ssl_blocking_page.h [modify] https://crrev.com/efb5f9e3bfda6dd47f186ba731b9fc7428ab626f/chrome/test/BUILD.gn [modify] https://crrev.com/efb5f9e3bfda6dd47f186ba731b9fc7428ab626f/content/browser/accessibility/browser_accessibility_manager.cc [modify] https://crrev.com/efb5f9e3bfda6dd47f186ba731b9fc7428ab626f/content/browser/accessibility/browser_accessibility_manager.h [modify] https://crrev.com/efb5f9e3bfda6dd47f186ba731b9fc7428ab626f/content/browser/frame_host/interstitial_page_impl.cc [modify] https://crrev.com/efb5f9e3bfda6dd47f186ba731b9fc7428ab626f/content/browser/frame_host/interstitial_page_impl.h [modify] https://crrev.com/efb5f9e3bfda6dd47f186ba731b9fc7428ab626f/content/browser/web_contents/web_contents_impl.cc
,
Dec 21 2017
Please verify!
,
Dec 27 2017
It seems to be working fine now. Thanks so much guys for this.
,
Jan 11 2018
,
Mar 12 2018
|
|||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||
Comment 1 by msramek@chromium.org
, Jun 12 2017