[A11y Assessment - NTP] when screen is magnified, hard to undo deletion of tile |
|||||||||||||
Issue descriptionGoogle Chrome 64.0.3251.0 (Official Build) canary (64-bit) (cohort: Clang-64) ZoomText Private Beta - 11.7.11.410 Since there isn't a way to intentionally add tiles to the NTP, I am filing this bug there isn't much chance to undo the accidental deletion of a tile as a screen magnifier user. Please try these steps to repro: # Load ZoomText then Chrome - that order is important # Navigate to the tiles on the bottom of the NTP # Click on the x in the upper right corner to close a tile # Tile immediately closes A dialog then opens at the bottom of the page giving users a chance to undo the deletion. However, the dialog closes on its own in just a few seconds. If you have magnified the screen around a tile, you will not see the dialog. There is no additional notification that the dialog has appeared, it hasn't received focus, etc. I'm not sure if it SHOULD be getting focus, I'm just listing the behavior as I see it. Unable to test on JAWS or NVDA because another bug is completely preventing me from closing these tiles at all: 696272
,
Nov 7 2017
,
Nov 17 2017
Any updates? How did we handle this issue in other products?
,
Nov 17 2017
+ lpalmaro who can give you insight about how to solve this issue. Thanks!
,
Nov 29 2017
Ping! Any guidance on how this could be solved?
,
Dec 12 2017
lpalmaro@: friendly ping, thanks.
,
Dec 14 2017
Sorry for the delay on this! I would say that this shouldn't steal focus for the user. So, I believe you should be able to tell when certain assistive technology is being used, see: https://cs.chromium.org/chromium/src/content/browser/accessibility/browser_accessibility_state_impl_win.cc?type=cs&q=Accessibility.WinZoomText&sq=package:chromium&l=71 From there, we can perhaps decide that if a magnifier (e.g. Zoomtext) is on, then we should extend the amount of time that this UI with steps to undo appears on screen instead of the default amount of seconds it appears now. Would it be at all possible to make Ctrl Z undo this action, as well?
,
Dec 14 2017
,
Dec 14 2017
Thanks! It looks like the detailed information on exactly which a11y helper is running isn't exposed, so we can't easily check that. Would simply BrowserAccessibilityState::IsAccessibleBrowser() be sufficient for showing the message longer? Good idea about Ctrl-Z, but I'm not sure if it's possible - my guess is that the browser itself intercepts that command before the page gets a chance to handle it. If Ctrl-Z indeed turns out to be impossible, could we use some other key combo, or would that be too obscure to be helpful?
,
Dec 15 2017
,
Dec 15 2017
Yes, it'd be fine to check BrowserAccessibilityState::IsAccessibleBrowser() as a clue to show the message longer. It will have some false positives, but that should be fine. I'd like to see if we made the "Thumbnail removed" message into an alert (add role="alert" to the element). I think that might make ZoomText announce it and/or zoom to it, worth a try at least.
,
Dec 18 2017
Thanks! Adding role="alert" is trivial and at least shouldn't hurt; I'll get right on that. Is BrowserAccessibilityState::IsAccessibleBrowser() (or something similar) already exposed to the web page? If not, then it'll require a bit of plumbing.
,
Dec 18 2017
,
Dec 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e8c7004022192affc7a82e1d6c929a2ef54de81b commit e8c7004022192affc7a82e1d6c929a2ef54de81b Author: Marc Treib <treib@chromium.org> Date: Thu Dec 21 09:13:58 2017 Local NTP: Increase 'MV item was removed' timeout in a11y mode Bug: 779262 Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation Change-Id: Ib569b7a3dbd96b84e47b53dd6eec0a2230295165 Reviewed-on: https://chromium-review.googlesource.com/831947 Commit-Queue: Marc Treib <treib@chromium.org> Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org> Cr-Commit-Position: refs/heads/master@{#525652} [modify] https://crrev.com/e8c7004022192affc7a82e1d6c929a2ef54de81b/chrome/browser/resources/local_ntp/local_ntp.css [modify] https://crrev.com/e8c7004022192affc7a82e1d6c929a2ef54de81b/chrome/browser/resources/local_ntp/local_ntp.js [modify] https://crrev.com/e8c7004022192affc7a82e1d6c929a2ef54de81b/chrome/browser/search/local_ntp_source.cc
,
Dec 21 2017
That should do it :) +dmazzoni,leberly to verify that this is all good now.
,
Dec 21 2017
Actually there's one more CL coming in here...
,
Dec 21 2017
,
Dec 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4b513b8da3fbcfa195414ef5ec9d7af54ac4f083 commit 4b513b8da3fbcfa195414ef5ec9d7af54ac4f083 Author: Marc Treib <treib@chromium.org> Date: Thu Dec 21 11:40:23 2017 Local NTP: Add role=alert to the 'MV item was removed' notification This should make the notification more discoverable via a11y tools such as screen readers or magnifiers. Bug: 779262 Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation Change-Id: I5061af8009de5a9c92fdf2aad75edcefad979c45 Reviewed-on: https://chromium-review.googlesource.com/831872 Commit-Queue: Marc Treib <treib@chromium.org> Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org> Cr-Commit-Position: refs/heads/master@{#525668} [modify] https://crrev.com/4b513b8da3fbcfa195414ef5ec9d7af54ac4f083/chrome/browser/resources/local_ntp/local_ntp.html [modify] https://crrev.com/4b513b8da3fbcfa195414ef5ec9d7af54ac4f083/chrome/browser/resources/local_ntp/local_ntp.js
,
Dec 21 2017
NOW it should be done :) |
|||||||||||||
►
Sign in to add a comment |
|||||||||||||
Comment 1 by treib@chromium.org
, Nov 3 2017Components: UI>Browser>NewTabPage