Comment by Timwi | Hacker News Reader

Comment by Timwi | Hacker News Reader

Parent Full thread

1. Make sure that the tree view control has screen reader support and that it has all the normal keyboard commands (such as right/left arrow for expanding/collapsing a parent node).

2. Make sure that the text box has a label that says “search” or “filter” and not just a magnifying glass icon. You can only get away with an icon if the GUI toolkit allows you to give it an alt text.

3. Make sure that this label has a hotkey (underlined letter) and that it's properly linked to the textbox so that pressing the hotkey actually focuses it.

4. Make sure that the tree view is next after the textbox in the tab order.

5. Make sure that it's obvious how to cancel a search. You've already assigned Enter to performing the search (as opposed to closing the dialog) which means you can't use Escape because that is already required for closing the dialog. I think one way is to let the user empty the textbox and press Enter to clear the search, but you can also have a separate button as long as it has a hotkey and an alt text if it's just an icon. This kind of button is allowed to sit between the textbox and the tree view in the tab order, but make sure it stays that way and you don't add 10 more buttons there so navigating to the tree view becomes arduous.

I think it's ironic that I can give all of this advice just by being a keyboard user. I'm not visually impaired and I don't use a screen reader.

Hm OK thanks for the pointers.

Point 1: I don't know whether tkinter's treeview has screen reader support. I will have to look into that. But what I did already do is to make it focusable, which it wasn't by default, I believe, and add controls like: up, down to select rows, pos1/home and end to go to first row or last row, space to select/highlight a row, I left right and left arrow key for opening and collapsing items, added enter and various other keys to trigger actions for focused row or all selected rows.

Point 2 I definitely have.

Point 3: I defined a shortcut (ctrl+f) that always focuses the text input widget of the filter, but I don't have a letter underlined in the label. The label is actually "Quick search" and not "Quick filter", which means I couldn't underline an "f". But also underlining any letter might indicate, that one could press ALT+letter to focus the input. Maybe I should add another shortcut to facilitate that and then truly underline the appropriate character. Maybe change the label to simply read "Filter" and use the "F".

Point 4 I have. The filter is directly under the treeview/table, and only one TAB away.

Point 5 I don't have, because as the user starts typing in the filter input field, the treeview/table is already being filtered concurrently. Pressing enter is just for when you want to repeat a search and not change the filter term. For example, when the words have changed concurrently due to other actions. There is no dialog to close, because this is all in the main window. I have been thinking about adding a dialog that displays a progress bar, or adding a progress bar in the bottom status bar of the application. There a stop button might be useful. But so far the searching/filtering finishes in milliseconds, so no one would have time to click that stop button.

> I defined a shortcut (ctrl+f) that...

Please leave standard shortcuts alone. Ctrl+f lets me search the page for content. It should never search anything other than the current page.

Edit: nvm, thought this was a web app / page. A native app having search this way is normal

Reply on news.ycombinator.com