Skip to main content

Hi #blind folks, especially software developers! I'm taking part in a #GitHub research meeting and I hope to raise as many #accessibility points as I can. I was told this fact is not at all confidential, so I may gather feedback.
Here's what I remember: multiline comments are inaccessible (eternal story); sometimes menu roles are used where they shouldn't be (watching repos, reactions etc.). Anything else that really bugs you at GitHub? Thanks!
#Accessibility #blind #github
in reply to André Polykanine

Timothy Wynn
Timothy Wynn
• •
Pinging @jcsteh since you're responsible for the GitHub Greasemonkey script:
github.com/jcsteh/axSGrease/bl…

axSGrease/GitHubA11yFixes.user.js at master · jcsteh/axSGrease

Greasemonkey scripts to improve the accessibility of various websites (e.g. Pandora) and to solve common web accessibility problems (e.g. windowless Flash). - jcsteh/axSGrease
GitHub
@Jamie Teh
in reply to Timothy Wynn

Jamie Teh
Jamie Teh
• •
@twynn Thanks for the ping. I can't function efficiently on GitHub without the AxSGrease script I wrote for GitHub. Here is what it does:
1. Puts the "add line comment" button logically *after* the line of code instead of before, which makes code reviews a lot faster for screen reader users.
2. Makes non-comment events into headings; e.g. closing/referencing an issue, approving/requesting changes to a PR, merging a PR.
3. Turns issue listing tables into tables so you can navigate between issues by row, rather than having to skip through a bunch of stuff for each issue.
Something i haven't added yet (but really need to because it drives me absolutely wild) is removing the headings on *every single file!* in the folders/files table. It completely clutters heading navigation for no good reason.
Finally, blame is completely inaccessible for screen reader users right now, which is really problematic.
@Timothy Wynn
in reply to Jamie Teh

Jamie Teh
Jamie Teh
• •
@twynn Oh, and when you choose "Finish your review" in a pull request, a dialog appears, but it doesn't get focus. That is pretty annoying for me, but might be even more problematic for a less experienced GitHub user who doesn't even realise the dialog appeared.
@Timothy Wynn
in reply to André Polykanine

Steve
Steve
• •
@aardrian The button for toggling the visible details of any premerge checks has a hard-coded attribute of "aria-expanded=true." It's driving me batshit crazy that nobody there has fixed it.
@Adrian Roselli
in reply to André Polykanine

Drew Mochak
Drew Mochak
• •

A lot of my friends avoid github because they don't know how to download software from it. They look for "download" rather than releases and end up downloading the repo, which of course is not what they are looking for. They also have difficulty determine how to find the specific package to download since there are a lot of different releases, binaries, etc.

The fastest way I've found to get to the list of artifacts is to find the second H2 on the page, then move by button to the list of "assets," then (if necessary) expand it, then explore the list of artifacts to find the right one. Apart from this being generally unintuitive and requiring a fair bit of prior knowledge, it is just way too many button-presses and cognitive load for something as simple as downloading a file!

This entry was edited (3 months ago)
in reply to Drew Mochak

victor tsaran
victor tsaran
• •
@drew Github UI is messy although, technically, could even be called accessible?
@Drew Mochak
in reply to victor tsaran

André Polykanine
André Polykanine
• •
@vick21 @drew Why not? I wouldn't call it inaccessible, some parts, especially newer ones, are weirder though.
@victor tsaran @Drew Mochak
in reply to André Polykanine

James Scholes
James Scholes
• •
Trying to declare accessibility as a binary flag is an exclusionary practice and, more importantly, a waste of everybody's time. Even if you decide that the flag is true for your use case and scenarios, it will be false for somebody else's. @vick21 @drew
@victor tsaran @Drew Mochak
This entry was edited (3 months ago)
in reply to James Scholes

Jamie Teh
Jamie Teh
• •
@jscholes @vick21 @drew It also gives companies an excuse to barely tick the box for accessibility and have users just put up with it, despite how inefficient it might make them. I would struggle to get much done efficiently on GitHub without my AxSGrease script. And there are absolutely parts of GitHub that are still completely inaccessible and are in fact far worse than they used to be, notably "blame".
@James Scholes @victor tsaran @Drew Mochak
in reply to Jamie Teh

André Polykanine
André Polykanine
• •
@jcsteh @jscholes @vick21 @drew Either I'm bad at expressing my opinions or what. I've never said that accessibility is a boolean flag. Anyway, I'll meet with them next week, and they promised me a dedicated breakout room just for me and my accessibility needs.
@James Scholes @Jamie Teh @victor tsaran @Drew Mochak
in reply to André Polykanine

victor tsaran
victor tsaran
• •
@drew That’s kind of what I said. It is accessible but probably not the most usable. :) I mean, of course, many things are doable, but others are not!
@Drew Mochak
in reply to André Polykanine

Svenja
Svenja
• •
They put Headings everywhere and I can't brows Files on Github any longer because of that, it was nicer when it was a simple Table with Links
in reply to André Polykanine

the esoteric programmer
the esoteric programmer
• •

* conflicts editor is very clumzy to use, it sometimes reads only blank lines, and it's not as nice to use as, say, vscode, which has options for keep mine, keep theirs and keep both, in a context menu

  • the files table after opening a repository, when it opens in the code view, is in headings, so I can't press h anymore to arrive to the readme as quickly. That's also probably a wcag violation, something about nesting semantics, but either way it's infuriating sometimes
  • when github actions has a yaml error, it only shows waiting for status to be reported for all workflows, the actual sintax error is berried deep in a couple workflow related menus
  • when making a pr review, the submit review button is inconveniently placed near the top of the page, where there are a lot of other controls. Perhaps space those controls out a bit semantically for one, but also, can that be moved somewhere where it's easier to find it, near the bottom or somewhere more obvious?
  • the top bar of a repository, where you get to code, issues, pull requests, etc should be actual tabs, not only links, and also should be easier to find, for example, a heading level 2 or so, straight after the header part of the page
  • the focus can sometimes eratically jump when viewing workflow jobs
  • when expanding a job, we're moved to the bottom of the log, instead of having our previous focus position be remembered, because those sections have nothing to jump to which could mark their beginning, so we have to repeatedly hit up arrow and hope we'll get to the beginning of the logs soon enough
  • not strictly accessibility related, but in my opinion at least, the process of making a pull request is tedious, especially if one doesn't only do it on their own repos. There's forking involved, branches, etc etc. What if, instead, can patches sent via email or attached to an issue comment in the web UI automatically transform into a pull request, linked to that issue, and fixes to that pr would be done by subsequently reuploading patches of the changed commit history, similar to sourcehut and the kernel mailing list?

That's probably all for now, but if those would be fixed, the whole contribution flow would be greatly enhanced, and we need that in foss, now, more than ever.

⇧