Also repros in Chrome OS, totally independent of any screen reader. 

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

This seems more like a usability bug than an accessibility bug?

Perhaps the accessibility bug would be best described as that the user does not know the search has been cancelled by that action.

I expected the search to work like a filter where the sub folders, once switched to, would present results specific to that folder.

Expected:
All Bookmarks:
Folder a: all about dogs
    All about cats
Folder b: 101 things dogs like to do
    101 things cats like to do

Search: 'cats'
Search results:
Folder a: All about cats
Folder b: 101 things cats like to do

Actual:
Search: 'cats'
(don't change folders or search silently cancelled)
Folder a:
Folder b:

Search results appear to screen reader users to be under the top folder a, but in reality are just bookmarks without any associated folder.
All about cats
101 things cats like to do

Ideas:
1. Nice to have: When there are search results, the folder list focuses an option named 'search results for cats'

2. Announce that search cleared when changing folders or pressing the clear search button
Then it's clear that when I change folders, my results are gone

In any case, there should be a way that a screen reader knows that the page state has changed.

I am able to reproduce this on Version 68.0.3440.106 (Official Build) (64-bit).
I also found this behavior to be surprising.

It looks to be that 'search' is always global and not folder specific.
If I am already within one of the folders, say "Other bookmarks", and I enter a search for "cats" then I can see that the UI removes focus from "Other bookmarks".

It appears that any usage of search or folders will reset the other.

I definitely agree this is problematic for accessibility, apologies for the wording of my comment which made it seem otherwise.

I think David's proposed solution in Comment 4 is a good start, although I'm uneasy about adding a "folder" which will be strictly ephemeral.

I think as a minimum, announcing when the search bar is cleared would help work around the underlying usability issue.

A nicer solution might be to filter the folders as per David's original suggestion, such that only explicitly clearing the search field will revert to the non-search folders. However, this is a more involved change that would probably need more UX input.

hcarmona@ recommends hiding the folder tree when searching.

Deleted: wide.png 32.1 KB

	wide.png 32.1 KB View Download

Deleted: medium.png 30.1 KB

	medium.png 30.1 KB View Download

Deleted: narrow.png 28.1 KB

	narrow.png 28.1 KB View Download

Tried this locally from https://chromium-review.googlesource.com/c/chromium/src/+/1300422, and it feels a bit awkward. The search box is moving under my cursor after I start searching.

Adding Namrata for guidance. Also, what other alternatives are there, besides hiding the folder tree?

The original suggestion was to announce that the search box has been cleared. This could be done all the time or only when it is cleared due to selecting a folder.

https://chromium-review.googlesource.com/c/chromium/src/+/1299835

Announcing that the search term is cleared is not good for our users since we've lost the results in an unexpected manner. The folder structure doesn't provide any help while searching and instead clears navigation and shows just the folder contents (without filter applied) which is unexpected even from a non-a11y standpoint.

The right solution here IMO is to remove the folder structure or disable it so it isn't part of the tab order and cannot be clicked when searching.

Another option (more complicated) would be to only show results from the selected subtree (This is what David proposed in #4). This would make the folder picker on the left work as an additional filter on the search which would be good overall.

Discussed offline. A few suggestions have been raised, and no decision has been made. This is planned to be discussed early next week.

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

commit 2013046dec2139e1ee1b9e7bee665e4dded3d495
Author: Esmael El-Moslimany <aee@chromium.org>
Date: Tue Nov 13 23:41:37 2018

Bookmarks WebUI: announce when search is cleared

Bug:  854673 
Change-Id: I139764a243ebf1d6c4209e124e6a8cf328985053
Reviewed-on: https://chromium-review.googlesource.com/c/1299835
Reviewed-by: Hector Carmona <hcarmona@chromium.org>
Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org>
Commit-Queue: Esmael El-Moslimany <aee@chromium.org>
Cr-Commit-Position: refs/heads/master@{#607808}
[modify] https://crrev.com/2013046dec2139e1ee1b9e7bee665e4dded3d495/chrome/app/generated_resources.grd
[modify] https://crrev.com/2013046dec2139e1ee1b9e7bee665e4dded3d495/chrome/browser/resources/md_bookmarks/app.js
[modify] https://crrev.com/2013046dec2139e1ee1b9e7bee665e4dded3d495/chrome/browser/ui/webui/md_bookmarks/md_bookmarks_ui.cc

After discussing offline, a decision was made to announce that the search is cleared as an interim solution.

As a follow-up, there a few potential things that can be done. As a general rule, the search box should not move after it has focus. The text input could move when gaining focus. With that in mind, here are some of the options.

 - Hide the tree with a transition when search begins.
 - Hide all unnecessary UI elements with a transition when the search gains focus.
 - Have the search input be hidden until focus and expand to part or all of the screen. This can be done in combination with hiding the tree.
 - Change the tree keyboard interaction such that focusing and selecting a folder are distinct. Up/down arrow keys can be used only for focus. Then a suitable selection key would be necessary. Note that enter is used for renaming in MacOS. Left/right are used for collapsing/expanding folders with child folders as well as navigating to the first child of an open parent folder or to the parent. Space is already bound to selecting a folder, which currently is only possible to invoke by first starting a search then focusing on the focus. In all other situations, at least one folder is selected. If space is a suitable key for selecting a folder, then to do this, only two lines of code need to be deleted.

If I'm missing any options that were discussed, I think adding them here makes sense. If there is a particular direction we want to take, add a comment here or ping me directly. The level of effort is low for all the options that were discussed.

The first three options would require UX to take a look at the transitions before taking the call. Plus the search box behavior on this screen would end up being different from search on other WebUI

For specifically improving accessibility , I would prefer option 4 vs the first three options, unless using space for selection is something which is unexpected in our interface. It seems to be common way to indicate selection otherwise: https://webaim.org/techniques/keyboard/ 

Sounds good. I can start on option 4.

When focusing on a folder, what should we announce?

On focus:
"Folder 'name of folder' focused. Press <Space> to show the contents of the folder."

On select:
"Showing contents of 'name of folder'."

+lpalmaro to weigh in on A11y

We should avoid announcing on every focus since that would cause noise for people w/ screen readers without providing too much help. Maybe only announce if search is cleared when a folder is focused. (similar to what we have now, except that up/down wouldn't clear search)

We could use aria-describedby instead and have a hidden element with instructions if we feel that the folder needs the additional description since this is read separately and a11y tools have ways for people to handle the description better than an announcement.

If there are no objections, I'm going to create a CL to separate the select and focus. We can figure out whether to change what we announce separate from that.

https://chromium-review.googlesource.com/c/chromium/src/+/1341082

In a tangentially related issue, is the context menu on the folder sufficiently obvious for users? I find custom-context menus often surprising. Elsewhere in the UI, a three dot action menu is shown. Any thoughts to the advantages/disadvantages of custom-context menu versus an action menu that is displayed when an action menu button is pressed?

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

commit 08dbb44e81454b6d67c3b6f4989e7e58e88f4b0b
Author: Esmael El-Moslimany <aee@chromium.org>
Date: Mon Nov 19 22:30:47 2018

Bookmarks WebUI: arrows change which folder has focus, space/enter selects

Pressing enter on Mac will open a rename folder dialog (F2 on other
platforms).

Bug:  854673 
Change-Id: I659cfcedc42aec04c47f696df9c71edc7201ce0c
Reviewed-on: https://chromium-review.googlesource.com/c/1341082
Commit-Queue: Esmael El-Moslimany <aee@chromium.org>
Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org>
Cr-Commit-Position: refs/heads/master@{#609473}
[modify] https://crrev.com/08dbb44e81454b6d67c3b6f4989e7e58e88f4b0b/chrome/browser/resources/md_bookmarks/folder_node.js
[modify] https://crrev.com/08dbb44e81454b6d67c3b6f4989e7e58e88f4b0b/chrome/test/data/webui/md_bookmarks/md_bookmarks_focus_test.js

I'm going to mark this as fixed for now. If we need to add or update the announcements, please reassign this issue back to me with the requirements.

Retested and not able to repro the above issue:

Google Chrome:72.0.3618.0 (Official Build) canary (64-bit)
Revision: 473cb3615ccd757dbfd816963e699299a0732b59-refs/branch-heads/3618@{#1}
Platform: 11298.0.0 (Official Build) canary-channel samus
Firmware Version: Google_Samus.6300.276.0
ARC:5143797

Marking it as Verified.