[wp-trac] [WordPress Trac] #50486: Improve the admin notices accessibility

[WordPress Trac]

#50486: Improve the admin notices accessibility
----------------------------+--------------------------------
 Reporter:  afercia         |       Owner:  joedolson
     Type:  defect (bug)    |      Status:  accepted
 Priority:  normal          |   Milestone:  7.1
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  needs-patch     |     Focuses:  ui, accessibility
----------------------------+--------------------------------

Comment (by sanket.parmar):

 Thank you for the feedback and for milestoning this for 7.1, @joedolson —
 great to have a concrete target!

 === On `<aside>` vs `<div role="complementary">` ===

 Completely agree — native HTML5 semantics are always preferable over ARIA
 role overrides. An `<aside>` with an `aria-label` gives the same landmark
 without depending on ARIA alone, and is more robust across different AT
 implementations. Happy to use that in the patch.

 === On the existing PR ===

 I had a look at [https://github.com/WordPress/wordpress-develop/pull/5225
 PR #5225] — the branch was deleted when it was closed in March 2024, so
 there's nothing to rebase from directly. That said, the PR diff is still
 visible and gives a clear picture of the direction and scope of the
 changes. My suggestion would be to start a fresh PR using the closed PR as
 a reference for which notices were covered and how they were approached,
 rather than trying to recover the old code.

  * Would you be taking the lead on that, or would it help if I put
 together a fresh PR based on what was in that old PR?
  * Are there any notices from that PR that you'd want to handle
 differently now, given the two years since it was closed?

 Happy to take on whichever part is most useful.

 === On inline / dynamic notices as a separate class ===

 This distinction makes a lot of sense. The way I read it, there would be
 two separate categories going forward:

  * '''Page-load notices''' — PHP-generated, rendered once after page load,
 covered by the landmark + skip link + title prefix approach
  * '''Dynamic/inline notices''' — JS-injected or triggered by user actions
 mid-page, each needing individual assessment, and delivering a spoken
 notification via `role="alert"` or `role="status"` depending on urgency

 The second category being treated individually is the right call given how
 varied the usages are across core. It also means the two tracks can
 progress independently without blocking each other.

 Would it make sense to open a child ticket specifically for the dynamic
 notices audit, so the two tracks can be tracked and reviewed separately?
 That would help keep this ticket focused on the page-load side and avoid
 it ballooning in scope again.

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