A11y: Accessibility in general and minimal keyboard usability

[mariohamann]

General

In your (great!) documentation in the accessibility part you currently link to WCAG 3.0 in general but not to ATAG 2.0 (Authoring Tool Accessibility Guidelines) which would be the important part for an editor. Those guidelines should be added.

You write:

Currently, we don’t even provide an interface, so for now that’s totally up to you. But no worries, we’ll provide an interface soon and take accessibility into account early on.

I know that Tiptap's concept is to be headless and that the visual and semantical representation of the editor is not part of TipTap's core. But I think, that in the short run the demos in the docs (being best practices) should be as accessible as possible, because...

• ...devs use your examples in their projects and therefore lots of projects would be more accessible from the start
• ...people relying on good accessibility should be able to try your demos as well
• ...there are editors like CKEditor, that are a11y-proven – and we should show, that TipTap can provide best accessibility as well

Keyboard usability

One central part for accessibility is the usability with keyboard. I already opened https://github.com/ueberdosis/tiptap-next/issues/239 to provide focus styles but the demo editors should provide the following minimal functions, too:

1. The whole editor area (toolbar + editable content) should be selectable with keyboard (e. g. with tabindex="0" and an additional class to provide the needed focus styles) . Currently you can only select buttons in the toolbar and the content area. (This will be needed later for some ARIA stuff.)
2. While the editor or anything inside is being focused, the first button in the toolbar should be selectable with Alt-F10. (After checking TinyMCE, CKEditor and WordPress' Gutenberg Editor this seems to be industry standard). Important: The current selection in the editor should be untouched!
3. While using the toolbar clicking Esc should bring you back to the last selection in the content area.

Of course this is just as minimal starting point and there are lots of things to consider, e. g.:

• announcing the editor in tab list
• role="toolbar" aria-orientation="horizontal for the toolbar
• making bubble or floating menus usable with keyboards

...just to name a few. I hope to find more time to help out. :)

[mariohamann]

Just another thought: Instead of overloading the demos and still having them as clean and minimal as possible, it could be nice to have one full-blown "Accessibility example" in the docs + on the landing page. This could provide the needed "best practice for accessibility".

Nevertheless, to make the demos usable with keyboard, we still need the above mentioned minimal setup, especially the interaction to select the first button in the toolbar.

[philippkuehn]

Thank you for this research! We should really improve that. I think it’s pretty hard to integrate some of these tips in a headless editor but an accessibility example sounds like a great idea!

[cadars]

(Adding this here instead of creating another issue)

Since tiptap doesn't use a regular semantic <textarea> element, I believe it would be good to give the editable .ProseMirror div the following attributes by default:

role="textbox" aria-multiline="true"

I've been able to pass these attributes as editorProps for the time being.

Additionally, for the read-only state (contenteditable="false"), aria-readonly="true" needs to be added?

Is it an issue that should be reported to the Prosemirror project instead?
Reference: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/textbox_role

[hanspagel]

Thanks, grest suggestion! From reading the link, I’d say we should add aria-placeholder to the placeholder extension too.

@philippkuehn upstream issue, tiptap core default or tiptap default extension?

[cadars]

Update: after testing with AXE DevTools, aria-expanded="false" (from the bubble menu) isn't allowed for the textbox role…

Maybe the attributes described above could be added to the parent div instead?
(disclaimer: I'm no a11y expert, just trying to figure things out)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[LeslieCarr]

The issues are still occuring

[github-actions]

This issue is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 7 days

[cmawhorter]

the current documentation says that this is being worked on:

[...] Currently, we don’t provide an interface, so for now that’s totally up to you.
But no worries, we’ll provide an interface soon and take accessibility into account early on.

...but this issue says the opposite.

is accessibility officially not planned, or was that just a housekeeping close of this issue? or maybe i've missed something entirely?

[Serhansolo]

Just wanted to note for future reference, #5398 this PR fixes the floating bubble menu issue in AXE. It is, as of today, part of the v3.0.0-next.1 release