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!
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!
Timothy Wynn
in reply to André Polykanine • • •github.com/jcsteh/axSGrease/bl…
axSGrease/GitHubA11yFixes.user.js at master · jcsteh/axSGrease
GitHubJamie Teh
in reply to Timothy Wynn • • •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.
Jamie Teh
in reply to Jamie Teh • • •André Polykanine
in reply to Jamie Teh • • •Steve
in reply to André Polykanine • • •Drew Mochak
in reply to André Polykanine • • •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!
victor tsaran
in reply to Drew Mochak • • •André Polykanine
in reply to victor tsaran • • •James Scholes
in reply to André Polykanine • • •Jamie Teh
in reply to James Scholes • • •victor tsaran
in reply to Jamie Teh • • •Jamie Teh
in reply to victor tsaran • • •victor tsaran
in reply to Jamie Teh • • •André Polykanine
in reply to Jamie Teh • • •victor tsaran
in reply to André Polykanine • • •André Polykanine
in reply to victor tsaran • • •Svenja
in reply to André Polykanine • • •André Polykanine
in reply to Svenja • • •the esoteric programmer
in reply to André Polykanine • • •* 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
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.
André Polykanine
in reply to the esoteric programmer • • •