Improper use of aria-description for hover card links

[sclower]

Select Topic Area

Product Feedback

Body

Today, Github rolled out a change to the markup rendered for hover cards. In particular, they all now include the aria-description attribute whose value is set to "Hovercard. Press Alt+Up to activate."

The problem is that (a) these are links, and Enter should be the only key to activate them. More critical, however, is that this added text is interjected every single time one of these link/card elements are encountered (whether they refer to profiles, issues, pull requests, etc), and interacting with Github with NVDA, for instance, is horrible. The same problem is easily reproduceable on this very page, in fact.

Please remove this attribute and, if possible, actually test such changes with screen readers. This seemingly minor change has essentially wrecked my productivity.

[jscholes]

Thanks @sclower for writing this up. My thoughts (which are completely aligned with the original post) can be found in this Mastodon thread:

https://dragonscave.space/@jscholes/112571117184455472

[aardrian]

I had also noticed this while doing unrelated testing. I made a recording while on a merged PR that has no comments and very little activity.

I found 38 non-hidden instances of this announcement on the page. 28 were on links:

//a[@aria-description="Hovercard. Press Alt+Up to activate"]

4 were on images (within different links):

//img[@aria-description="Hovercard. Press Alt+Up to activate"]

And 4 were on spans without roles:

//span[@aria-description="Hovercard. Press Alt+Up to activate"][not(@role)]

I did not record all those in the video.

GitHub-link-aria-desc.mp4

The first 22 seconds are me navigating by link (not how I normally use a screen reader, but there was audio interference so I started in the middle of my second pass). At 0:06 I hear the instructions on the avatar image so I press Alt+↑ at 0:08 and 0:10, but nothing happens.

I hear the instructions on my profile name at 0:14 and successfully trigger the non-modal container (I think it needs a role: //*[@aria-label="User Hovercard"][@role]) as my focus is moved into it. Then I leave it by pressing Esc (and my focus shifts back).

At 0:25 I Tab to the avatar image, hear the instructions and am again unable to activate it at 0:29.

Finally, I use the virtual cursor at 0:38, hear the instructions, and am again unable to activate the non-modal container as instructed.

I agree with @sclower and @jscholes this is verbose. It is also broken in some cases, some of the triggers should not be triggers, and the container itself may be lacking necessary properties.

[alexstine]

Upvote. Please let's revert this and go back to the drawing board. This has made GitHub a useability nightmare to the point where I might just disable descriptions being read on GitHub.com.

[brunoprietog]

I don't need to be told all the time that I have to press alt up arrow to see the overcard. There are so many more important things to do to improve accesibility... What a pity

[j0siepy]

Hi folks, I'm a new PM working on accessibility.

Thank you everyone for this feedback - we hear you. We have reverted the aria-description for hover card links. While we intend to be iterative when releasing new features, we understand that this may have caused more friction and frustration.

Additionally, your comments have informed us that getting feedback from the community before we ship changes would be a great step to add in our release process. We'll be evaluating upcoming opportunities so stay tuned in the community if you'd like to help. We sincerely appreciate our community helping us improve our product and our processes.

[jscholes]

@j0siepy Thank you for reverting the change! The quick turnaround is appreciated.

I do want to raise one concern about something you wrote:

Additionally, your comments have informed us that getting feedback from the community before we ship changes would be a great step to add in our release process.

While undeniably important, I don't see that as the primary takeaway from this incident. You highlighted that this "... may have caused more friction and frustration," while I would claim it caused multiple GitHub users to experience a significant amount of disruption.

Fundamentally, this was a deployment of an ARIA attribute that is not present in the current W3C recommendation of the spec (WAI-ARIA 1.2), but only in WAI-ARIA 1.3 at the First Public Working Draft phase. It is critical that support for experimental techniques is tested internally, with multiple screen readers and browsers, or that expert external assistance is employed (for money). Had such testing been performed in this case, I feel quite hopeful that the unacceptable level of verbosity would have been detected.

Note that I don't aim to downplay the importance of testing changes that are not seen as experimental, nor community outreach. But I also think the swift, strong community response on this one highlights that this was a "miss" on GitHub's part, and community labour is not the only (or most) appropriate means of preventing this in the future.

[ludwick]

I do not use voiceover regularly at the moment but am low vision so my text size (and mouse pointer) is somewhat large. The hovercards popping up everywhere is a major distraction and often makes it hard for me to distinguish page elements (or I will be moving my mouse around and then suddenly there's a big square covering what I was trying to read). Is there a way to just turn hovercards off? I almost never want them. If I want to know what is at the other end of a link, I will open the page.

[sclower]

+1 to James’s comments. I, like probably everyone else on this thread, have work to do; providing free labor because Github is inadequately staffed to perform critical accessibility testing is not something I’m interested in, nor have the time to spare. You guys have plenty of money to hire experts to help you avoid missteps like this in the future. I hope you will.

[jage9]

Thank you for the quick fix and taking ownership of the issue. You are definitely right to say that new accessibility features should be tested, and I know Github has done some of this in the past. Hopefully those processes can be refined to provide the best possible experience going forward.

[alexstine]

Thanks for the fix. Others have already said the rest. 👍

[brunoprietog]

Thanksfor the solution. I'm relieved. And sorry for the abrupt message. The frustration was getting too much as I had to keep using GitHub, but I also understand that after all, there was no ill intent either. I just wish there was more direct communication with users who need assistive technology. There are bugs that have been posted in this discussion forum a while back and they don't seem to be taken into account. There are a lot of things to improve actually.

I'd love to see accessibility improvements in other areas, I happy to help as I have on several other sites. I have reported problems with the new commits view for example.

In the projects view it would be great if the announcements were more helpful when moving through the cards with the arrows.

In the new repository view you seem to be hijacking pressing the enter key. If I press ctrl + enter to open a repository in a new tab, it navigates to it in the same tab anyway.

I'd like to be able to check PRs more efficiently as well.

In the code editor, I'd like to be able to share a link that highlights line ranges, but currently, as far as I know, it can't be done in an accessible way. I have to read the line numbers and assemble the link manually.

Thanks again for the fix

[alexstine]

@brunoprietog Somewhat off subject but this used to be possible. You could select the line numbers in the read-only view and it would generate a working skip link.

In the code editor, I'd like to be able to share a link that highlights line ranges, but currently, as far as I know, it can't be done in an accessible way. I have to read the line numbers and assemble the link manually.

It seems like when GitHub brought over the code editor that looks like it was out of Azure DevOps, they forgot to bring the accessible features with it. In ADO, the option existed I believe via the context menu.

[ahicks92]

I too will say that in general GH accessibility rates as "can operate", but it's not pleasant and not necessarily efficient. I appreciate the rollback. Since a new PM is monitoring, I figured I'd post to say that NVAccess, the authors of NVDA itself, use GitHub. If you're looking for people to talk to, you might want to reach out to them for feedback and possibly suggested improvements--crucially they do have mailing lists with lots of devs etc on them, and I imagine that the absolute worst case is they let you drop some sort of feedback thing out to their mailing lists.

I'm not sure what it says that neither I nor anyone I know particularly likes GH accessibility but we use it because Jira and GitLab are worse. Please please do better. I'm a staff software engineer and it's ridiculous I don't have a single option that doesn't come with the suck. Installing Greasemonkey scripts just to get rid of "add line comment" in PRs because we can't read lines quickly without it, and that script is maintained by one of the two creators of NVDA...

I myself don't have a lot of spare time, but if you want to chat I'm also open to that, and while I'm not able to cite standards and necessarily mandate the correct Aria I do literally go into the debugger to remove it sometimes (admittedly not on GH but if you use aria-hidden wrong someday, you will get your turn at that). In other words I'm kinda halfway the next best thing if what you need is free.

[j0siepy]

Thank you for taking the time to share your concerns with us. I'd like to affirm that we employ and engage with both accessibility experts and users with lived experiences, including screen reader users, and that their input is an integral part of our process. At the same time, we recognize that we would be doing our users a disservice in believing that we are able to account for all use cases and perspectives through only those who happen to be employed by GitHub, which is why we also value feedback from outside our inner loops of development.

While our intention with this change was to improve the user experience, we realize we should have proactively requested feedback on whether that incremental change represented a net improvement, being willing to revert should the response be no, along with feedback on what your ideal state would be if you have one. We will leave the change rolled back for the time being, and we apologize for the disruption and appreciate your thoughtful feedback.

We recognize that we can be more proactive with communications and integrate additional feedback periods and are updating our processes to do so moving forward. ❤️