Thank you for testing the Hovercards Beta Feature!
You can use this thread to write down any bugs or issues you've encountered with Hovercards. If you'd prefer to start your own thread, please feel free to do so.
Topic on Talk:Page Previews/Flow
Don't forget to turn off "Navigation popups" from gadgets if you have it enabled, otherwise they'll get into fights.
This is another feature that when enabled by default would have significant accessiblity consequences due to floating/modal windows. This needs to be taken into account in any sort of deploy strategy.
TheDJ, I'm not 100% i understand your concern, can you explain further so we can make sure we address this issue?
Jaredzimmerman (WMF): I think TheDJ's point here is that, for example, the accessibility provided by screen readers may not interact very well with Hovercards popping up. Best case, the screen reader doesn't read the text on the card. Worst case, the card totally breaks the screen reader. We need to be considerate of this in future deployments, but we're fine for now due to the opt-in nature of the feature.
TheDJ: Thanks very much for raising this issue.
DGarry (WMF): Exactly. what happens if the user has a mouse that happens to hover a link (he would have no clue about this). The card is read if he is at the end of the page, and the links inside it would be interaction points for him. Best is usually to actually try this scenario (chromevox or voiceover) and listen to what is being read to you (but remember that screen readers are anything but consistent).
It's a bit of a complicated scenario as well. Normally if the popup is closed, you'd want the user to be able to open it using keyboard commands, but since the target is already a link, that will be difficult.
Some useful things here may be.
- role=dialog could be used (but you are out of dom order, so slightly confusing to the user)
- you need to handle transfer of keyboard focus if the user enters and leaves the dialog
- Explain the dialog with an aria-label [your mouse is hovering a link giving you a preview of the target's content. You can use keyboard key 'p' on any focused link to activate a preview).
- On the content, you could put aria-live (would start to read it after short period of inactivity).
- Don't use dialog, but aria-haspopup and aria-expanded (but how do you explain how to open the popup, without clicking the link?)
An alternative is to simply disable the popups altogether for disabled users, by putting aria-hidden on the entire block. It's not nice to hide functionality from users who don't use a mouse, but it might be an acceptable stopgap method.
See also: https://www.mediawiki.org/wiki/Accessibility_guide_for_developers
TheDJ: Thank you so much for the detailed description and solution. I've added a bug on Bugzilla - https://bugzilla.wikimedia.org/62948
Will read the page you've linked to and start work on a solution soon.
TheDJ: I went through the ARIA Techniques article on MDN and how to expose a custom dialog using aria on w3.org and I think I have some understanding of this now.
Based on an answer I recently saw on StackOverflow, asia-haspopup is used for submenus.
Aria Practices is on my reading list and I'll discuss our options with you once I am done reading :)
TheDJ: I believe if we can work out the popup into the tab-index order for screenreaders, (Obviously, I need to investigate it more thoroughly) this would be great for accessibility. Going off to a whole other page just to get context isn't the best thing for a user with a visual impairment.
TheDJ: To my surprise, there was a whole section on dialog/tooltips in the Aria Practices document. I feel this is more of a tooltip than a dialog box. There are no controls within the Hovercard except a link to open the relevant page. This is the same as the link that the user has given focus to, thus we don't need bring focus to the Hovercard–at least for now (see open questions).
I have submitted a few patches that you can find links to on bugzilla. Do you mind reviewing them? Please point out any mistakes in the approach taken.
Sometimes it seems there are empty dialogs. Can we avoid showing the hover cards in these situations or fix this? http://imgur.com/o1qwenP
Jdlrobson, I think that Prtksxna has a patch to start blacklisting unsupported page types and namespace types, and if not, its on the roadmap, just didn't make the first release/
Jdlrobson: There is no patch as of now. I am trying to decide where the problem lies, whether its Extension:TextExtracts not returning anything or something wrong with Extension:Popups. If its in TextExtracts should we not show the Hovercard at all if its empty? What should we do if it returns an image but no text?
IP User Hovercards - If you look around this Talk page, probably near the top, there are a few comments by anonymous users, represented by their IPs. My issue is that every user has a hover card, except for IP users. Obviously, it'd be unrealistic for them to have a proper hover card as they lack a user page. Despite this, I would at least like a card for consistency's sake. Perhaps just a card saying "This user isn't logged in or doesn't have a Wikipedia account." or something similar.
Just a little thing that bothered me when I noticed it.
Nicereddy: IP addresses link to [Special:Contributions/IP] (in both Flow and in normal signatures and in History/RC/etc pages), hence this is expected behaviour.
However, as you suggest, a custom card for that type of link might be interesting. (?) Long-term feature enhancement though.