[wp-trac] [WordPress Trac] #47053: Accessibility: Need to set proper 'tabindex' in 'Skip To Toolbar' HTML

[WordPress Trac]

#47053: Accessibility: Need to set proper 'tabindex' in 'Skip To Toolbar' HTML
-------------------------------------------------+-------------------------
 Reporter:  jankimoradiya                        |       Owner:  joedolson
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  5.4
Component:  Toolbar                              |     Version:
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-screenshots has-patch early      |     Focuses:  ui,
  commit has-dev-note fixed-major dev-reviewed   |  accessibility
-------------------------------------------------+-------------------------

Comment (by jadpm):

 Not sure if this would trigger a reopen for this ticket, but changes
 merged and released here about how (and when) the admin bar is printed do
 affect the functionality for some plugins using that admin bar. This
 happens in at least 3 of the premium plugins I manage.

 A shot description of the usage and the problem:
 - A plugin inserts some object into a post editor, be it a block, a
 shortcode, or anything else.
 - That object, when processed during the post content rendering, will
 generate an entry in the admin bar.

 We use this to offer edit links to some of our advanced elements when they
 get printed in post or page content. Imagine a map, or a list, or a form.
 Before this change, we could keep track of all such elements as they were
 requested. After this change, for themes using the "wp_body_open" hook,
 all our data is collected after the admin bar is already printed, hence
 useless, and the admin bar entry can not be included.

 I do not want to open a discussion about whether usability or developers
 safety should be considered first. Just leaving here a note to stress that
 changes in the order of execution of things have wild effects in the
 echosystem. I would call this a backwards compatibility problem, at least.

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