A11y: Accessibility in general and minimal keyboard usability

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. 😃

[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?