62.0.3200.0 (Official Build) canary (64-bit) (cohort: 64-Bit)
Windows 10 14393.1593

I can reproduce the following behavior. 
(1) Open a NTP
(2) Use Tab key to focus on a tile to remove it
Entire tile is focusable, no way to close. 

Thanks,

Laura 

Friendly ping - any updates on who can own this? 

treib@: does the local NTP fix this problem? is the close-X its own tabstop, or is there some other way to access this?

No, the local NTP behaves in the same way. AFAIK there's no way to access the "x" with the keyboard.

What's the desired behavior here? Currently the "x" only appears when you hover the mouse over it, so just making it tabbable would be kinda weird/surprising. Seems like we need a more fundamental redesign to really fix this. WDYT?

Write https://crrev.com/c/725659, which would be a fix for this if the design of it is acceptable.

Interesting discovery: you can remove tiles with the keyboard, by highlighting and using delete. This isn't discoverable, though.

The hidden key 'Delete' seems nice to have. Additionally I recommend the following. 

Recommended fixex within the current design:

1. Reveal [X] when a tile is focused with keyboard
2. Make [X] focusable so the next Tab key moves the focus from the current tile to the current tile's [x]


2 is similar to the tile's overflow menu on "Manage people" window (even that UI can reveal the overflow menu on focus on a tile, but it's out of scope of this bug.)


 

That sounds reasonable to me. I attached a quick mock to illustrate what the focus travel would look like.

Deleted: Focus.png 42.4 KB

	Focus.png 42.4 KB View Download

Well, since I've already implemented this, I might as well take the bug.

Attached images of what I have. The focus rings are a little bit larger than your mock, because they go around the clickable area, and I didn't want to reduce the size of the clickable target.

Aside from the appearance of the focus, there's also the transitions. What I've implemented is:
* On focus tile: fade in X after half second delay (this matches hover)
* On focus X: appear immediately with no fade (if not faded in from tile focus)
* On blur tile or X: fade out X immediately.
All fades last 150ms.

Deleted: Screen Shot 2017-10-20 at 13.38.50.png 325 KB

	Screen Shot 2017-10-20 at 13.38.50.png 325 KB View Download

Deleted: Screen Shot 2017-10-20 at 13.39.01.png 321 KB

	Screen Shot 2017-10-20 at 13.39.01.png 321 KB View Download

SGTM, thank you!

treib@ pointed out that I had shrunk the gradient, so I grew it again, but that changes the focus ring.

Today, the gradient has two stops: 100% at 24px from the end of the tile, and 0% at 40px from the end, with a midpoint of 50% at 32px from the end. The X is centered within a 32x32 square. Currently, the X is clickable out to the 0% stop, so there's a 40x32 clickable area.

We have three options for this change:
1.  Shrink the clickable area to the 50% stop and use a square focus ring.
2.  Keep the rectangular clickable area and use a rectangular focus ring.
3.  Have a rectangular clickable area and a square focus ring.

I don't think (3) is a good idea, and I'm not sure how to go about (1), so I'm going to proceed with (2) for now (image attached).

Deleted: Screen Shot 2017-10-20 at 15.55.59.png 76.2 KB

	Screen Shot 2017-10-20 at 15.55.59.png 76.2 KB View Download

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3ebe7b184b8b60fb7fdf57fea1b4868f7676614e

commit 3ebe7b184b8b60fb7fdf57fea1b4868f7676614e
Author: Chris Pickel <sfiera@chromium.org>
Date: Mon Oct 23 17:58:21 2017

Local NTP: allow tab to "remove tile" button

Make the .mv-x elements real buttons. When a tile is focused, fade its X
in (same as with :hover). When the X is focused, make it appear (without
transition or delay).

Bug:  696272 
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: I8f59f3f1e343c4dc2ff8c8c2c0de140c841e8056
Reviewed-on: https://chromium-review.googlesource.com/725659
Reviewed-by: Marc Treib <treib@chromium.org>
Commit-Queue: Chris Pickel <sfiera@chromium.org>
Cr-Commit-Position: refs/heads/master@{#510841}
[modify] https://crrev.com/3ebe7b184b8b60fb7fdf57fea1b4868f7676614e/chrome/browser/resources/local_ntp/most_visited_single.css
[modify] https://crrev.com/3ebe7b184b8b60fb7fdf57fea1b4868f7676614e/chrome/browser/resources/local_ntp/most_visited_single.js

Tested the issue on Windows 10, Mac 10.12.6 & Ubuntu 14.04 using Chrome version M64 - 64.0.3248.0 as per the issue mentioned in original comment. Observed that issue is working as intended (In the NTP, a tile can be removed by using the 'Tab' button. Tabbing on the NTP will shift focus to thumbnail first and then to the 'X' on the thumbnail). Hence adding TE-Verified label. Attached the screencast for reference.

Deleted: 696272.mp4 960 KB

	696272.mp4 960 KB View Download

The test engineer who worked on this posted valid results but they did not include screen reader tests. I have run those additional tests as part of Windows GAR eval and have found that this bug is not resolved. 

Google Chrome 64.0.3251.0 (Official Build) canary (64-bit) (cohort: Clang-64) 
Windows 10 Enterprise Version 1607 Build 14393.1770
NVDA 2017.3
JAWS 2018.1710.42 private preview release
ZoomText Private Beta -  11.7.11.410

Though the X is now in the tab order and received focus highlight, it cannot actually be selected by screen reader users. However, it does work for ZoomText and for keyboard only. Please try these steps to reproduce:

# Load the AT under test (JAWS, NVDA) and Chrome 
# Open NTP page and navigate to a tile, tab one more time to put the focus rectangle on the X in the upper right corner of the tile.
# Press space or enter to invoke the X button

Expected: tile is removed from the NTP page
Actual: the URL associated with that tile is opened in a new window

This reproduces with JAWS and NVDA. 
For ZoomText and keyboard only, the x button works as expected. 

Another issue is that the X button is not labeled/verbalized correctly, it says "Search for : visited Link" 

This is weird. The "x" is a <button> element with a 'click' event listener, which removes the tile and prevents the event from bubbling up to the tile (where it would cause a navigation to that tile). I guess JAWS and NVDA mess with that somehow?! Any ideas on how to prevent that?

I also have no idea where the "Search for : visited Link" label comes from, AFAIK we don't set anything like that anywhere. I guess the button just needs an explicit 'aria-label'?

This bug is related to https://bugs.chromium.org/p/chromium/issues/detail?id=699688

That  bug 699688  is left open for the remaining polish (count and "i of n" announcement).

This bug, 696272, is for being able to remove tiles using the keyboard.

Both bugs are cross platform. 

Setting to p2 since this was found during our assessment

My suspicion is that screen readers are confused by a button inside of a link.

They probably shouldn't be - it's perfectly valid HTML - but it's not common and I can see how it could be slightly ambiguous.

Would it be possible to restructure the HTML slightly so that the close button is a sibling to the link, rather than a child?

So, summary of current state: Keyboard works fine now, but screen readers get confused for some reason, possibly the <button> inside of <a>.

(not working on client-side Chrome any more)

 Issue 853045  may have captured comment #c28 - leaving this open for Kristi to evaluate when she looks at 853045.

Fixed in latest Canary

Google Chrome	70.0.3524.2 (Official Build) dev (64-bit)
Firmware Version	Google_Lulu.6301.136.57

Verified using steps above, able to tab to the X button not show that tile again.

I verified this as part of our accessibility assessment.