[wp-trac] [WordPress Trac] #33031: Fix accessibility for the Keyboard Shortcuts help dialog

[WordPress Trac]

#33031: Fix accessibility for the Keyboard Shortcuts help dialog
--------------------------+------------------------------
 Reporter:  azaozz        |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  TinyMCE       |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:  accessibility
--------------------------+------------------------------

Comment (by afercia):

 Tested a bit the patch and yes it's an improvement. I'm all for having
 this in 4.3, there are some outstanding issues though. To recap:
 - using a screen reader (and the keyboard of course): users can now use
 the up arrow key to move back to the scrollable div and all the other
 keystrokes for reading content (h2, tables, arrows) seem to work correctly

 Outstanding issues:
 - using a keyboard only: when focus is on the Close button users can't
 move focus back and scroll the content, basically users can't read the
 content, the only chance is to close the modal and open it again
 - we should consider to add some descriptive screen reader text for the
 editor Text Patterns characters: symbols like `* - > #` get announced in a
 weird way or they don't get announced at all. Also `1. 1)` gets read out
 as "one one" most of the times, this may vary depending on screen readers
 punctuation and verbosity settings
 - the last `<h2>` should be just a `<p>` since headings are useful to mark
 the beginning of a content section

 > The only focusable element in that modal is the Close button.
 Well, we have just made the scrollable div focusable so there are two
 focusable elements. It's TinyMCE that has its own opinions about what is
 focusable and what is not :) Maybe, TinyMCE should include in its
 focusable elements index also all the natively focusable elements that may
 be used in a TinyMCE "container".

 Anyway, I wouldn't say it's a regression. What
 `tinymce.ui.KeyboardNavigation` does is strictly tied to what TinyMCE
 needs and assumes the presence of TinyMCE "controls". It just doesn't fit
 the case when the modal dialog content is just... content. For reference,
 this worked slightly better in WordPress 3.8 because the modal used a
 tabbed interface and "tabs" are TinyMCE focusable elements. Also, the
 Close button was inside the scrollable div so it was always possible to
 scroll the content:

 [[Image(https://cldup.com/xfWI6VrWSE.png)]]

--
Ticket URL: <https://core.trac.wordpress.org/ticket/33031#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform