w3c / w3c/edit-context

How should canvas EditContext be made accessible?

Open
#139 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

a11y-tracker Agenda+
Dominant language
HTML
Stars
48
Forks
13
PR merge metrics
No merged PRs in 30d

Description

See also: #136. It's not clear how exactly canvas-based EditContext editors should be made accessible to assistive technologies such as screen readers.
In theory, the EditContext.text could be exposed to screen readers, however, I don't know if that's a good idea since it's missing information about formatting and structure (paragraphs, links, etc.). So some kind of alternative content is needed. However, screen readers often announce the selected text, so that information needs to be exposed somehow. Web apps could use the SpeechSynthesis API to announce things directly, but that requires a lot of extra work to rebuild all the functionality that already exists (using arrow keys to change what is being announced, etc.) and wouldn't necessarily work the same as the software the user is used to.

So I'm thinking, perhaps the best solution is to synchronize the DOM selection in the alternative content with the selection in the EditContext, while keeping the EditContext focused. Something like this: https://ltenmoz.github.io/editcontext-canvas/index.html. However, this seems to have some issues. For example, when using NVDA on Windows, the selection isn't announced when new text is selected. Also, if PageUp/PageDown is pressed, the DOM selection leaves the editor (on Chromium) since it's not preventDefaulted. So if this is the correct approach, browsers need to

  • Ensure that screen readers interact well with the selection being moved by scripts with an EditContext editor focused.
  • Disable selection moving shortcuts for canvas EditContext, in case there are some that the web app doesn't preventDefault (so that the selection in the alternative content doesn't get out of sync with the selection in the EditContext)

Another potential issue: WebKit and Chromium don't lay out canvas fallback content, which is an issue for assistive technologies which need to know the position of the text. Not sure what the best solution is there.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the related issue #136 and testing the linked EditContext canvas example with NVDA on Windows. Investigate how scripted DOM selection, PageUp/PageDown, and canvas fallback content behave for assistive technologies; done should be a documented browser behavior or agreed implementation direction.

Written by the indexing model from the issue text.

Assessment

Tech stack
html
Domain
accessibility, frontend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.