Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TOC closes on HTML access key, but not on keyboard shortcut #175

Open
AndreasJRudolph opened this issue Aug 25, 2014 · 3 comments
Open

TOC closes on HTML access key, but not on keyboard shortcut #175

AndreasJRudolph opened this issue Aug 25, 2014 · 3 comments

Comments

@AndreasJRudolph
Copy link

Just a small detail regarding the usability: It seems inconsistent to me that the accesskey does open but not close the TOC. Since it is connected with the TOC button in the navbar, shouldn´t it toggle the visibility of the TOC the same way that the button does?

@danielweck danielweck added this to the v1+ milestone Sep 1, 2014
@danielweck danielweck changed the title TOC does not close on accesskey TOC closes on HTML access key, but not on keyboard shortcut Sep 1, 2014
@danielweck
Copy link
Member

Actually, the bug report is slightly inaccurate, please allow me to reformulate:

(1) The HTML access key does toggle the TOC (e.g. on OSX: CTRL ALT T)

(2) The keyboard shortcut (i.e. single key T) does show the TOC when it is invisible, but puts the focus at the top of the TOC pane (i.e. the "close" button) when the TOC is already visible. Therefore, one extra step is required to actually close the TOC (space bar or enter key).

You are absolutely correct that this is inconsistent. Originally, the intent was to enable keyboard users to quickly move keyboard focus on the TOC (top landmark, "close" button), after they navigate to a heading and associated XHTML content (or anywhere else, for that matter). HTML access keys work very differently, as they activate a command directly (link, button click). Thus the discrepancy.

So, one alternative approach would be to make the keyboard shortcut and access key consistent (i.e. actually "toggle" the TOC), and this way users would need to hide+show the TOC in order to re-focus the keyboard onto the top of the list of headings. This however may lead to an awkward user experience, so perhaps an additional keyboard shortcut is needed to re-focus at the top of the headings list. Unfortunately there are not many "safe" keyboard shortcuts available (from a cross-platform web browser / screen reader perspective), so generally-speaking we should be cautious when deciding to expand the existing list.

Food for thoughts.

@AndreasJRudolph
Copy link
Author

I understand what you mean with the need to jump back from Epub content or a TOC heading to the top of the TOC which now blocks the use of T for closing the TOC.

I have the idea that we could define a keyboard shortcut which cycles through "home" points of the different regions (toolbar, content, TOC). So with open TOC this key would jump to the first heading ("home" point of TOC), when pressed again to the top of the content, then to the first button ("About") of the toolbar. As a nice sideeffect that would resolve the problem that it is sometimes slow to move the focus from one region to another via or shift+. Although one more keyboard shortcut would be used it would not have only one benefit.

Another idea that I have is if it could be convenient to toggle the visibility of the settings modal via keyboard shortcut and so to free the SettingsModalClose keyboard shortcut . In future when other modals are made accessible on keyboard shortcut (which I tried in PR #161), to close them on the same shortcut seems to me a solution to have a fast way of closing them and not to "waste" shortcuts.

@danielweck
Copy link
Member

Thanks for the suggestions!
@becka11y did a great job setting-up landmarks, but they are probably only accessible to some screen readers right now. We could somehow bind those landmarked areas to Readium's generic keyboard shortcut framework, in order to cycle through important regions, just like screen readers do?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants