@dom_walden can you help me note down the current behavior of the popup. Looking at test.wiki on Chrome, I see:

• If you don't do anything the popup disappears in ~5 seconds
  • The popup disappears when hovering over it (I could swear it sometimes stays when you hover)
  • The popup disappears when the dropdown is open (I could swear it sometimes stays when the dropdown is open)
  • The popup disappears when a link or form element is in focus
• Clicking outside the popup doesn't dismiss it
• Clicking on the popup (anywhere but the link or the dropdown) dismisses it

Is this what you see too?

In T259647#6375064, @Prtksxna wrote:

@dom_walden can you help me note down the current behavior of the popup. Looking at test.wiki on Chrome, I see:

• If you don't do anything the popup disappears in ~5 seconds
  • The popup disappears when hovering over it (I could swear it sometimes stays when you hover)
  • The popup disappears when the dropdown is open (I could swear it sometimes stays when the dropdown is open)
  • The popup disappears when a link or form element is in focus

Yes. I think Harumi is working on it in T258662#6352761.

• Clicking outside the popup doesn't dismiss it

Hmm, I haven't checked. I am not sure what the desired behaviour should be.

• Clicking on the popup (anywhere but the link or the dropdown) dismisses it

I think this used to be the desired behaviour. I cannot remember if watchlist expiry is supposed to change this.

In T259647#6375256, @dom_walden wrote:

Yes. I think Harumi is working on it in T258662#6352761.

Thanks!

• Clicking outside the popup doesn't dismiss it

Hmm, I haven't checked. I am not sure what the desired behaviour should be.

• Clicking on the popup (anywhere but the link or the dropdown) dismisses it

I think this used to be the desired behaviour. I cannot remember if watchlist expiry is supposed to change this.

Just saw that you had noted it here T249259#6164636

Noting some of the resources I am looking at (so that I don't lose track of them):

• https://www.w3.org/TR/wai-aria-practices/#alertdialog
• https://www.w3.org/TR/wai-aria-practices/examples/dialog-modal/alertdialog.html
• https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_alert_role
• https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions
• https://www.w3.org/TR/WCAG20-TECHS/ARIA19.html
• https://www.w3.org/TR/wai-aria-practices-1.1/examples/alert/alert.html
• https://www.carbondesignsystem.com/components/notification/accessibility/
• https://inclusive-components.design/notifications/

The thing I am struggling to balance is giving focus to the popup so that its keyboard accessible, and it still disappearing after a certain amount of time if there is no interaction.

The watchlist popup’s elment isn’t added right after the star icon (in the DOM of the page). This means that there are several elements that the user has to tab through (in 5 seconds) to be able to reach the dropdown. This is not good for keyboard accessibility.

My first thought was that we should treat the popup as a non-modal dialog or alert. This meant we would move the focus to it as soon as the popup appears on the screen. But, this would mean that we wont close the popup till it has focus. And so, unless the user tabbed out of it, the popup would always be visible. This isn’t what we want.

It seems what we are looking for is the status role. Unlike dialogs, statuses need not be given focus, and since they inherit the aria-live and aria-flowto (see guideline) role the screen readers announce their presence to the user regardless of focus. We will however need to make sure to add aria-controls to the star and point it to the popup so that the users know that those two are related.

While this helps with the reading order we might still need to manually take care of the tabbing order in order to be compliant with the focus order criteria. I recently learnt that messing with tabindex is an anti-pattern, so I guess we’ll have to do this through JS.