[META] Review Paragraphs widget accessibility

To be identified, only for assistive technologies, no visual changes expected.

Just a note that this is a bit restrictive, as currently worded.

1. Accessibility is a broader topic than assistive technology. For example, sighted keyboard-only users will not necessarily be using any assistive technology at all.
2. Some improvements may need visual changes, for example focus should be indicated visually to meet WCAG 2 SC 2.4.7 Focus Visible

I always recommend that folks start with the easy accessibility tools to catch the low hanging fruit.

1) Using something like the Wave Toolbar Extension (which works for FF & Chrome) what errors do you see? There usually are some that these tools bring up. There are of course others, but this one is super simple to get started with.

2) Try to tab through the site without using a mouse. Your browser might need to be configured so that it works, but you should be able to tab between links and jump into form elements and do everything without a mouse or trackpad.

You're probably pretty good if you can do those things. There's way more that is needed for other assistive technology, but I definitely recommend starting here with what the developers and users of this great module can identify.

Automated tools like this might only get you 40% of the way, but it's a good start.

A big issue is when you edit an entity that has paragraphs, there are dynamic changes to the form, without a page reload. Visually impaired users may be unaware that the form has changed after pressing a button:

Edit an existing node with paragraphs. The paragraph entities are shown as a summary/preview, with an edit/remove dropbutton.

1. Pressing "edit" makes the paragraph preview get replaced with a paragraph bundle form, and the "edit" control becomes "collapse".
   • Screen reader users should be informed what has happened. A brief Drupal.announce() message will suffice here. Call it in JS after the ajax response. What do we announce? Unsure - maybe use the paragraph bundle and weight? "Edit form now showing for Call-to-action at position 1". Note we are in a tabledrag so match the numbers, say.
   • The dropbutton operations change, and focus is lost. Keyboard users could become lost, confused, or frustrated by this (sighted or not, with assistive tech or not). Ideally focus wants to stay on the dropbutton, but in this case the "edit" control appears to be removed from the DOM, so it's a tricky case. Maybe focus could be programatically moved to the new "collapse" control after the AJAX response? If so do this before making the Drupal.announce() call.
2. Pressing "collapse" makes the paragraph bundle form get replaced with a paragraph preview, and the "collapse" control becomes "edit". The same problems and solution as pressing the "edit" control.
3. Using the "remove" control results in it becoming a "confirm removal" button.
   • As above, give focus to the new "confirm removal" control.
   • The fact that additional action is required should be conveyed. We don't want to leave a screen reader user with the impression that a paragraph has been removed, when in fact it hasn't been. I'm unsure what the best approach would be here, but let's say we move focus to the new "confirm removal" control, then Drupal.announce("Confirmation required to remove this Call-to-Action from position 1").
   • But what if you want to cancel this action? A "restore" button is available, but hidden in the dropbutton. I don't think this is very discoverable. At this critical point, I think that "cancel" would be clearer. I'd also avoid hiding it in the dropbutton, because that takes a keyboard user several keypresses to find. Make it visible, and right after the confirm button (just one tab press away).

@andrewmacpherson - absolutely! I do appreciate you spelling out the next steps, particularly with Drupal.announce().

@miro_dietiker - do you think you can break these up into child items and start working on them.

Ultimately I think we should pick off the issues we know need to be done before we wade into the more complicated issues (like cancelling an action).

Nobody wants to get stuck, but let's try and make sure those issues are hived off away from the ones that should be relatively straight forward to identify & fix. We're not needing for perfection, just incremental improvement moving that direction.

Added a subtask #3443457: Inform screen readers about paragraph actions (WCAG 4.1.3).

Hi, I added a new related issue : #3452997