Adding in Stefan, who spent good time at FB on this issue.

Stefan, if you have a few minutes, would love some guidance here if you have any.

Although this works, you might find with this implementation that you're going to be duplicating a lot of things just to get text readable to a screen reader. Instead you might consider just labeling the existing elements better so they seem less confusing to a blind user. For instance, instead of just hiding your alerts, give them labels so that they have meaning.

<a href="/notification/" class="sprite-menu alert-notifications message-unread">
  <span class="sprite-menu phabricator-main-menu-alert-icon"></span>
  <span class="phabricator-main-menu-alert-count">0</span>
</a>

This can become:

<a href="/notification/" class="sprite-menu alert-notifications message-unread">
  <span class="sprite-menu phabricator-main-menu-alert-icon">
    <span class="aural-only">Alerts: </span>
  </span>
  <span class="phabricator-main-menu-alert-count">0</span>
</a>

In this specific case, the action on the visible links is (I think?) bad for screen readers, since it pops open a dropdown that shows up in a totally different part of the document. That is, if you "click" the existing element, you don't navigate anywhere, but instead affect a visually related but aurally disconnected part of the document body. I'm not actually sure if this is a problem, but it's difficult for me to imagine it works well.

ARIA has standards to enable the understanding of these drop-downs with screen readers. You can give your link aria-haspopup="true" and aria-expanded="false". Then, when the popup opens, you should set focus within it and return focus to the link when the popup closes. Ideally you should also trap focus within the popup while it is open and give your link a role="button".

I should probably move it, I was internally conflicted over whether "aural" or "z-index" is a more specialized state.