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

Outline structure is unparsable by screen readers #11274

Open
2 tasks done
wiresong opened this issue Apr 28, 2024 · 0 comments
Open
2 tasks done

Outline structure is unparsable by screen readers #11274

wiresong opened this issue Apr 28, 2024 · 0 comments

Comments

@wiresong
Copy link

wiresong commented Apr 28, 2024

Search first

  • I searched and no similar issues were found

What Happened?

I use Logseq with the NVDA screen reader. While there is visual outline structure to blocks, which makes blocks/subblocks distinct, there is no such structure for my screen reader to use. Given something like the following:

  • a1
  • a2
    • a3
    • a4
      • a5
      • a6
  • a7

The screen reader reads blocks a1 to a7 in order, without informing me about the indentation of any block. For me, this makes Logseq mostly unusable for its principle job as an outliner.

Reproduce the Bug

  1. Open Logseq (either the web interface or the desktop app) using JAWS/NVDA/your screen reader of choice
  2. Create the following structure:
  • outdented block
    • Indented block
  • Another outdented block
  1. Read through the page with the typical screen reader navigation keys

Expected Behavior

The screen reader has structure which it can use to (1) announce the relative indentation of blocks, and (2) let me navigate through the structure with the keys that the screen reader assigns for me.

Screenshots

No response

Desktop or Mobile Platform Information

No response

Additional Context

Ideally, the easiest way to solve this would be to make each block a <li>...</li>, and allow the structure to be represented as nested <ul>...</ul>s. Using semantic HTML like this is all that is required-screen readers can then use that information to offer rich speech and navigation facilities. I'm not sure how that would play with the CSS, though, so further work might be required there?

Another option would be to use ARIA to annotate specific blocks with list information, and that would probably play better with the CSS, but ideally we only do that if doing lists in HTML isn't feasible.

I'm willing to do a PR, as long as we end up using nested lists for this, and as long as someone can verify that my code doesn't break visual structure. I've made small accessibility tweaks to my local Logseq codebase, so adding this shouldn't be too much work (hopefully).

Are you willing to submit a PR? If you know how to fix the bug.

  • I'm willing to submit a PR (Thank you!)
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

2 participants