I'm not sure about this. It's my personal belief, that screenreader users wouldn't like us very much if a popup was read for every single link. Now the accessibility cursor isn't equal to the focus cursor, but the focus cursor does tend to follow the accessibility cursor. Quick testing with VoiceOver suggests that for this browser+Screenreader combo, would mean that if you stop upon a link and stop interacting with the browser, you would get a popup after 200ms..

Very much advice extensive testing with multiple screenreader systems and users on this one, as a highly obtrusive popup is way more annoying than a non-accessible one which already has a method to access the same information (follow the link).

Oh and it might be that aria-describedby requires the id to be present in the dom before you are on the element. Not sure if that is still the case for all browsers, but that used to be a common limitation.

@Volker_E thoughts?

@TheDJ In my understanding it's better to provide the ability to focus in on the excerpts for screenreaders than not to, which is exactly what aria-describedby is intended for.

The point about the id being available before focussing the element is more crucial. This and the general acceptance are both things we need to test.

I've created the branch named aria-testing for this feature.

could also be used to test T195718: Cannot dismiss page preview with keyboard navigation

To my delight, I think this approach -- i.e. adding aria-describedby dynamically -- actually works, at least for VoiceOver on a Mac.
https://drive.google.com/file/d/1dEwRbzQfGtDaDos15s8MngJTROsGr-ZR/view?usp=sharing

Change 439937 had a related patch set uploaded (by Jdrewniak; owner: Jdrewniak):
[mediawiki/extensions/Popups@master] [WIP] Adds aria-describedby attribute to popups

https://gerrit.wikimedia.org/r/439937

@Volker_E although the above patch is a WIP it should help you run any user tests you need. What do you need from us to make that happen? Do you have or need a test environment?

@Jdlrobson We don't have NVDA nor Jaws setup somewhere officially, both are costly. This is a high-profile enough problem to make this a topic (again).

@Jdrewniak will set up a meeting with volker and I to work out next steps.

I've setup a meeting for Thursday, just waiting for @Volker_E to confirm time.

Risk – Benefits
Risks:

• Breaking reading workflow for screenreader users by overexposure to aria-describedby attribute, connected to inability to change setting as settings aren't exposed either.
• Not being able to expose popup setting
• Inability to QA one of most popular screenreaders JAWS currently

Benefits:

• Improving reading experience for blind users as aria-describedby per definition should come after link text and let them decide to keep focus on element or go further in the text. Everybody's happy.

We're going to host this and @Volker_E will collect some feedback from some users.
The server must have Monobook, Popups and this patch installed.
Ideally we'd want to get this tested by some real blind users. We're leave it the patch live on the machine for the whole July.

Per https://phabricator.wikimedia.org/T192627#4312963 this is unblocked. We just need to get this hosted somewhere and hand over to Volker.
@Jdrewniak are you happy to own getting this on a labs instance or would you rather I took over making that happen?

@Volker_E The initial patch with screen-reader support has been posted on http://a11y.wmflabs.org/
Currently it just features the initial patch that enables screen-readers to read the previews.
Does not yet feature:

• closing popups via keyboard
• accessing popups settings via keyboard
• monobook skin

@Volker_E we've setup http://a11y.wmflabs.org/wiki/Main_Page
It has the patch on it. It has Monobook.
I tried to add you as a member but not sure if you have an account - adding VolkerE gives me errors.

Got everything you need to begin user testing? If so please resolve this! Thanks!

@Volker_E , please review this when you can! We're eager to close this task! https://a11y.wmflabs.org/wiki/Main_Page

This is ready for signoff pending @Volker_E's approval!

Just to complete above: Currently awaiting screen reader users feedback.

\o/

@Volker_E, are you done with a11y.wmflabs.org or should we keep that up?

Naaaaah, I'm not a fan of this at all. On Windows, at least (with both NVDA and JAWS), it only works in FF, not IE (which many screen readers still use). It also doesn't work with these screen reader's accessibility cursors and only works when tabbing over the links, which screen reader users would never do. When it does work I don't like it ... it's just way too verbose and I just want to cut it off.

@Niedzielski No, please keep it a bit longer… I'll give feedback as soon as it's ready to be switched off.

@Graham87 just to double check. You don't like having this popup information to begin with, because it is too much info and/or too many any interactions ? And you would not tab through the page to open them.
But it's not less accessible then it is was before right ? If you actively decided to ignore them, at all cost, you wouldn't run into them ?

Would there be a scenario, where you would like to have popups with a subset of the information attached to the link ? I'm thinking for instance user cards, that would show basic information about the user page being linked. If so, how would you expect to trigger such a popup interaction, and how would you then expect to follow the link itself. Have you ever experienced websites that have presented meaningful 'link' popup dialogs for you ?

If you don't have good answers, that is fine too, just want to make sure all angles are being considered.

Yes, that's correct. I could ignore it at all costs if it was added, but I still see it as completely counterintuitive to have different behaviour when links are tabbed to versus when they are cursored over with the virtual cursor. I'd think beginners would be more likely to try to tab over links too.

I can't think of any scenarios where I would want a popup link. With user pages, if I want to know more info about a user (e.g. their edit count), I have ways of doing that quickly.

I haven't noticed any websites that use meaningful popup links. Not counting Facebook, which uses modal dialogues, which are different.

Change 439937 abandoned by Jdrewniak:
[WIP] Adds aria-describedby attribute to popups

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Popups/ /439937