We tried to communicate w/ #GitHub re: #Copilot; they have outright refused to answer community questions on Copilot & took it for-profit. Copilot ignores copyleft requirements; so it's time to #GiveUpGitHub GiveUpGitHub.org

We can no longer in good conscience stay silent about problems w/#GitHub's products. This latest effort to capitalize on the corpus of #copyleft code hosted on GitHub is merely the latest of their many ethical and moral lapses.

We call on people in positions of power in their FOSS communities to stop using GitHub and stop recommending it. GitHub, as a proprietary, trade-secret platform cannot be the singular development community for FOSS projects.

Gratis resources often entice & trap FOSS developers into a proprietary gated community — the walled garden of @GitHub. Remember: FOSS faced similar before — triumphantly. We'll do so again if take action now to protect our communities.

Over the coming months @conservancy will release guides and stories from projects that have moved away from GitHub. Let's shed light on the damage that is caused by centralizing community development on proprietary platforms.

Please join us and #GiveUpGitHub by visiting GiveUpGitHub.org/ and while you are still on #GitHub, adding information to your README that you do not agree with GitHub's policies and monopolized place in our community.

@conservancy I might drop GitHub mirrors for new projects, but I worry that this could disproportionately cause friction among disabled users.

The main reason I currently mirror to GitHub is accessibility. The only other forge I know of that’s usable with assistive technologies is Sourcehut, my primary forge. Many feel uncomfortable with Sourcehut’s style of contribution and the other FOSS forges are severely lacking, so that leaves GitHub.

GitLab requires JavaScript for basic functionality, which itself is a little problematic from a FOSS perspective and very problematic from a privacy perspective: there’s a reason why the Tor Browser disables JavaScript on its “Safest” mode.

“the GitLab Enterprise Edition, which is provided to the public on gitlab.com, is (like GitHub) trade-secret, proprietary, vendor-lock-in software”

I agree with this statement except for the “trade-secret” choice of words. The “Enterprise Edition” is source-available proprietary software.

Some things I think you should consider adding:

Notes on CI solutions. While SourceHut and GitLab provide excellent CI, Gitea does not. Codeberg offers CI in the form of Woodpecker CI. I don’t know how good Woodpecker is from an accessibility perspective, but Sourcehut’s “builds” service is excellent.
Notes on measures taken by forges to escape vendor lock-in through the network effect (I like to call this “user domestication”). Sourcehut uses mailing lists and does not require making an account.

#POSSE note from https://seirdy.one/notes/2022/06/30/give-up-github/


@Seirdy FWIW SourceHut is pretty poor accessibility-wise too. Little attention has been paid to it from what I can see.

@jookia I won't pretend that the Sourcehut accessibility situation ideal, but it's usable for the most part with assistive technologies IME. From what I can tell, it doesn't have critical issues like hidden/un-focusable items, interactive widgets that don't change states, keyboard traps, etc. The only other forge that generally passes that is GitHub.

Core functionality all works, but ancillary functionality and quality-of-life could use some significant improvements. I'll file some tickets later today; they're generally easy to fix. Some that come to mind are using additional `<nav>` elements with different labels, and naming in-page heading anchors.

#POSSE note from https://seirdy.one/notes/2022/06/30/sourcehut-accessibility/

@Seirdy it's inaccessible in ways that almost seem like they tried to make it broken: it has a hard to navigate maze-like site layout for one

@jookia Just saw your thread on the matter, updated my website's copy of that post with a link.
@jookia Ok you're def right about sourcehut's navigation issues. No way to go from a project's repo/list/tickets to the parent project page is concerning; think there's a ticket for that. I wanted to tackle it last year, I think I should give it another look.

Would love to know how I can make my site's nav better. Right now: I use labelled navigation, make the source/DOM/visual order identical, use headings and sections to break up content, and test it with multiple browser/screen-reader combinations regularly.

The only major issue I think is that I broke the first rule of ARIA for heading permalinks to make reading modes and assistive technology happy: these two agents receive different semantics for the permalinks.

I think another issue would be a lack of navigation context (e.g. breadcrumbs) for pages that aren't direct descendants of the sections listed in the navbar. My fediverse greeting (linked in my profile and "about" page) and my site design standards (linked in the footer) come to mind.

I have multiple blind readers who regularly give feedback, so I'm really interested in this.

@jookia I made full conformance with the AA level and partial conformance with AAA a goal in my site’s accessibility statement, the first sub-section of my “site design standards” page. I’ve been writing about my progress in meeting each SC in WCAG 2.2 for a while now, and plan on publishing it when finished. Here’s an excerpt of the WIP document containing every SC under Guideline 2.4:

SC 2.4.1: I use navigation landmarks and headings to bypass blocks. This includes sufficient techniques ARIA11 and H69. I also follow advisory techniques C6 and H97.
SC 2.4.2: All pages use the title element, which is sufficient technique H25. Automated checkers will flag any exceptions; I regularly crawl my entire site with HTML-Proofer.
SC 2.4.3: My source, visual, and DOM order are identical (assuming you read top-to-bottom, left-to-right). Sufficient technique C27.
SC 2.4.4 and SC 2.4.9: I’m not aware of any ambiguous link names in context; I’m open to hearing about exceptions. I try to make links comprehensible without context; this is a WIP.
SC 2.4.5: Pages can be reached through the search bar in the footer of every page (sufficient technique G161), and either my archive pages (“posts” and “notes”) listing all subpages (sufficient technique…G126 I think?), or by following in-page links on other pages (sufficient technique G125?); all posts and notes also have a next/prev link.
SC 2.4.6: I use sufficient techniques G130 and G131. I generally prefer using aria-labelledby over aria-label because the latter doesn’t translate well using machine-translation, and because I usually want assistive technologies to report content that’s similar to what sighted users see.
SC 2.4.7, SC 2.4.11, SC 2.4.12, SC 2.4.13: my focus indicators should exceed all of these requirements. They aren’t obscured, are at least 3px thick, and use both AAA contrast ratios and the APCA contrast ratios. Focus indicators for non-interactive elements (necessary for VoiceOver compatibility) use the browser default styles.
SC 2.4.8: I make correct use of aria-current in the global navigation. For subpages of each section listed in the global navigation, I emphasize the relevant section by making it a <strong> element. This represents sufficient techniques G128. As I mentioned in the grandparent post: I should do more than the bare minimum, perhaps by adding a breadcrumb list. Screen readers don’t usually pronounce <strong>.
SC 2.4.10: All sections have headings. No heading levels are skipped. Automated checkers will flag any exceptions: I regularly crawl my entire site with both axe-core and IBM Equal Access Checker.
SC 2.4.14: Not applicable; I do not have any page breaks.

Conclusion: For AAA conformance I haven’t fully met SC 2.4.9. While I do the bare minimum to meet SC 2.4.8, I should do more by adding a breadcrumb trail. I don’t think my website “fail[s] section 2.4” unless you look for strict AAA conformance, but it could certainly improve in these aspects.

@Seirdy It says clearly under benefits here:

"People who use only the keyboard or a keyboard interface can reach content with fewer keystrokes. Otherwise, they might have to make dozens of keystrokes before reaching a link in the main content area. This can take a long time and may cause severe physical pain for some users."

How have you addressed this point?

@jookia I spent a long timw evaluating skip links, and even included one at one point!

Skip links are not required for guideline 2.4; they make for one of many possible techniques to conform to it.

Regarding skipping the nav links:

1. I asked multiple blind people who read my site, and none of them used skip links; they use headings and landmarks.
2. Heading-based navigation will let you skip the navigation bar since every page follows the navigation bar immediately with a heading level 1
3. Landmark-based navigation should let you skip the navigation bar because I use a `nav` and `main` element.

Furthermore, the navigation bar is...really minimal. It's six elements in a single row, one of which is a link to the homepage. The usability gain for skipping it is far too low. It's not worth picking one of these tradeoffs:

1. dealing with hidden/visible elements that can overlap with others
2. Adding a seventh navigation link before the rest with a different functionality than the other six
3. Adding an empty space above the navbar for a persistent and/or non-overlapping skip link, decreasing the odds of the page heading showing up in the viewport (tiny mobile screens with spatial navigation, e.g. KaiOS Devices)

I personally think "skip links" make sense on a great number of sites, but they should't be cargo-culted for sites with very little skippable content that already use a semantic approach to skippable content.

@Mayana shared similar thoughts on Fedi. Let me see if I can dig up the relevant thread…

@Seirdy @Mayana

No it's fine, untag me from this convo if you're going to have logic like that

@jookia My bad, sorry for that callout. Just recognized your username. :ms_facepalm:

@Seirdy I don't recall talking about this specifically, so it must've been some time back (in which case the auto-post-delete took care of it). I could write something up again in the morning, but for now let me just say that I entirely agree with all of this.
Also, this may be of interest, as it directly asks about skip links: webaim.org/projects/screenread
Edit: Keeping for clarity, but untagging the other participant as requested.

@Mayana @Seirdy this is a really interesting discussion! I might not have realized (although obvious in hindsight) that GitHib alternatives might be much worse for accessibility reasons. ❤️💔

Thank you for participating in the original Conservancy thread where more of us could find it.

@Seirdy @jookia

Is there a good guide anywhere on what to do, and not do, to make software accessible?

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!