[wp-trac] [WordPress Trac] #42110: Keyboard focus in Heads up! modal dialog under Appearance >> Editor

[WordPress Trac]

#42110: Keyboard focus in Heads up! modal dialog under Appearance >> Editor
---------------------------+----------------------------
 Reporter:  sami.keijonen  |       Owner:  afercia
     Type:  defect (bug)   |      Status:  assigned
 Priority:  normal         |   Milestone:  4.9
Component:  Customize      |     Version:  trunk
 Severity:  normal         |  Resolution:
 Keywords:  has-patch      |     Focuses:  accessibility
---------------------------+----------------------------
Changes (by afercia):

 * keywords:  needs-patch => has-patch


Comment:

 Spent an insane amount of time trying all the possible variations of ARIA
 roles (dialog, alertdialog, and also alert), properly targeting elements
 within the modal with `aria-labelledby` and `aria-describedby` but wasn't
 able to get consistent results across different combinations of browsers
 and screen readers. Tested all the variations with Firefox + NVDA, Firefox
 + JAWS 17, IE 11 + JAWS 17, IE11 + NVDA,  Safari 11 and VoiceOver.

 There are a couple reasons that might explain this. First of all, this is
 not exactly a dialog (not as intended in ARIA) because it gets displayed
 on page load and it's not activated by an user action. It looks like a
 modal dialog, but it's just page content rendered during page load.

 Secondarily, there's a lot going on in the background including a full
 instantiation of the editor. That's a lot of DOM manipulation that happens
 at the same time the modal gets displayed and could easily confuse screen
 readers.

 Long story short, I'd propose to not use ARIA in this very peculiar case
 and just ensure the warning text is available to all users.

 [attachment:42110.diff] does the following:
 - hides all the page content from assistive technologies using `aria-
 hidden="true"`, except the modal
 - uses `wp.a11y.speak()` to make screen readers announce the modal message
 - constrain tabbing within the modal

 This way, even if users miss the `speak` message, the modal content is
 actually the only perceivable content in the page. When closing the modal,
 `aria-hidden="true"` gets removed, making the page content available again
 to assistive technologies.

 Also, when closing the modal, focus is not moved within the editor any
 longer. I'd propose to don't do anything with focus. Content navigation
 should start from the document root to match the native behavior when
 normally visiting the plugin/theme editor pages.

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