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

[a11y] Navigation between internal hyperlinks #47

Open
gregoriopellegrino opened this issue May 31, 2018 · 7 comments
Open

[a11y] Navigation between internal hyperlinks #47

gregoriopellegrino opened this issue May 31, 2018 · 7 comments
Assignees

Comments

@gregoriopellegrino
Copy link

OS: Windows 10
Assistive technology: NVDA 2018.1.1

When click on a link in the text the focus doesn't change, so NVDA remains to the origin content.

@danielweck
Copy link
Member

Thank you for reporting the bug.
When you say "click", do you mean "mouse click" or keyboard-activated hyperlink? (e.g. tab + enter key user interaction)

@danielweck
Copy link
Member

Related issue: edrlab/thorium-reader#156

@danielweck
Copy link
Member

TODO: fix in navigator (force keyboard focus via HTML / web API), so assigned to me.

@danielweck danielweck self-assigned this Jun 11, 2018
@gregoriopellegrino
Copy link
Author

Dear Daniel,
we tested both (click and tab+enter) and found the same problem.

@danielweck
Copy link
Member

This is the default Electron v3 Chromium behaviour, we will need to find a workaround in r2-navigator-js.
There is no proper keyboard focus on non-focusable elements inside EPUB documents. Some screen readers pick-up the URL hash fragment identifier redirection (window location), others don't. The same problem exists on the web with vertically-scrolling documents, the only difference here is that we apply CSS columns to layout the reflowable markup content.

@llemeurfr
Copy link

Would it be solved when we move to Electron 5 (you say default Electron 3 behavior, is there an implicit notion of change?).
Shouldn't we move this issue to the navigator repo?

@danielweck
Copy link
Member

I have not tried this particular use-case yet (i.e. screen readers following the window.location hash fragment identifier in scroll/paginated HTML documents inside iframe/webview)
Yes, this is purely a r2-navigator-js issue.

@danielweck danielweck transferred this issue from edrlab/thorium-reader Sep 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants