New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 730910 link

Starred by 6 users

Issue metadata

Status: Verified
Owner:
Closed: Dec 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug
Team-Security-UX
Team-Accessibility

Blocked on:
issue 448486


Show other hotlists

Hotlists containing this issue:
EnamelAndFriendsFixIt


Sign in to add a comment

Chrome Privacy error screen inaccessible

Project Member Reported by ja...@nvaccess.org, Jun 8 2017

Issue description

Chrome 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
 
Components: UI>Browser>SafeBrowsing
Components: -UI>Browser>SafeBrowsing UI>Browser>Interstitials
Eh, sorry. This is the SSL interstitial, not the SB one.
Cc: nek...@chromium.org
Owner: est...@chromium.org
Status: Assigned (was: Untriaged)
Assigning to estark@ to get this sorted out.
Labels: triage-nektar
Labels: triage-aaron
Labels: -triage-aaron -triage-nektar
@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.
Not accessible in JAWS either.
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.

Blockedon: 448486
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.
Labels: Hotlist-EnamelAndFriendsFixIt
Owner: dmazz...@chromium.org
@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.

Comment 12 by jfa...@gmail.com, 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.
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.
Labels: win-a11y
Labels: -Pri-3 Pri-1
Upping priority
Labels: dialogs
Owner: nek...@chromium.org
Status: Available (was: Assigned)
 Issue 793875  has been merged into this issue.
Labels: -dialogs
Owner: dmazz...@chromium.org
Status: Started (was: Available)
This isn't actually a dialog. I'm working on this now.

Issue 678603 has been merged into this issue.
Project Member

Comment 20 by bugdroid1@chromium.org, 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

Labels: a11y-testers
Status: Fixed (was: Started)
Please verify!
It seems to be working fine now. Thanks so much guys for this.
Status: Verified (was: Fixed)
Labels: -a11y-testers

Sign in to add a comment