GitHub have the gall talking about accessibility while flinging their octotentacles, dragging users screaming down to the firey pits of JavaScript hell.
I would suppose the above user is referring, rather snidely, to GitHub not loading commit information without JavaScript. GitHub's JavaScript use is really quite minimal, and certainly nothing like GitLab.
Github uses web-components which are not supported by
old browsers. All dynamic menus don't work without
polyfill extension(which takes 100% CPU due some bug after awhile), basic functionality like creating/modifying files works right now but there is no guarantee github wouldn't break it.
I don't understand that to be honest, commit information is fairly static, and we've been building semi-dynamic pages server-side for decades now. At their size they could probably - and probably do - have an in-memory cache for commits + basic information for super fast access.
The fact that it used to work perfectly fine without JS is proof enough that it don't need it. But I guess the average web deviloper is more concerned with stuffing one's resume with the latest fads than real accessibility and efficiency.
There's a lot of hostility on HN towards web developers. "Real accessibility" doesn't really have much to do with Javascript or not, it has everything to do with ensuring the site is screen reader accessible, ensuring the site is available for low-vision users, and ensuring that the site is available at slow bandwidths. Given that the site caters to those already (good kb navigation, stated future support for color-blindness, and the site is ~300kb/page) I think that they're in pretty good shape.
Ultimately, choosing not to run JS is your decision—but a vanishingly small percentage of users choose to do that, and as a company your focus is on providing features for the product, and not supporting every single user and their unique configurations. Should Github explicitly support terminal-based browsers like Lynx as well?
Plus, you can avoid 99% of the github website just by using git from the command line (or your favorite client) and using their CLI tool for repo creation/etc.
I really don't understand the glorification of no-js websites on HN. Like, I'd get it if it was Flash or something ('cause that definitely has some real accessibility issues, and required a plugin to be installed), but the web platform is HTML, CSS and JS. Why artificially limit yourself to just two? It seems to have become a matter of pride to say "works without JS", for absolutely no practical reason (it's not like removing JS is some silver bullet for accessibility, no-js sites can and do still absolutely have problems with accessibility)
> There's a lot of hostility on HN towards web developers.
You're conflating different types of web developers here.
There's only hostility towards the sub-set of web developers that focus only on what is expedient while sacrificing user-friendliness. The ones that hop on the latest and greatest buzzword technologies in order to pad their resumes.
There's a lot of hostility on HN towards web developers.
Why shouldn't there be, when they're the ones breaking things that used to work perfectly fine, and then reimplementing them half-bakedly while consuming an order of magnitude more resources than before?
Should Github explicitly support terminal-based browsers like Lynx as well?
Why does it have to be "explicitly support"? Whatever happened to using the simplest technology possible for the task? That way you'll end up with a page that will work to the best possible extent for any given user-agent. That is ture accessibility.
I'm not asking for them to go out of their way to try to show images in Lynx or whatever. I'm asking for a sane approach to making sites that does not require running arbitrary code on the client just to show some static text that should've come along directly in the page, something that literally all browsers would be able to, but is being needlessly restricted.
Plus, you can avoid 99% of the github website just by using git from the command line (or your favorite client) and using their CLI tool for repo creation/etc.
Please take a step back for a moment and imagine that you're one of the blind users of HN running into this comment. Reading that GitHub devs who took the time to actually support some assistive technology on their website (not sure how well, but see the existing aria attributes in the source) and track their support (https://government.github.com/accessibility/) don't care about "real accessibility" by not catering to what technology choices you prefer.
That's not true. The idea that the web should gracefully degrade and continue to display content in browsers of all types has been live for... the entire existence of the web.
There is a new trend to expect all clients to run js, yes, but that is a bad assumption.
"real accessibility" predominantly involves making it possible for people with disabilities to use a website, it's not about accommodating people who put a blindfold on and complain that it's difficult to see.
Accessibility doesn't really mean catering to people who choose to disable JS in their browser. There's whole set of standards for providing accessibility with dynamic web https://www.w3.org/WAI/standards-guidelines/aria/
And every common description of web accessibility. From WAI to Wikipedia to common courses. I'm not saying it's good design or the right direction for GitHub. Just that accessibility is important and disabling-js is not really it.
Specifically: disabling JS - your choice; having a disability - not your choice.
No, accessibility is already defined as a legal concept that has been around since before the advent of the Internet, because it also applies to our physical infrastructure.
It wasn't always like this. Look at WCAG version 1.0 [0] section 6.3. It's very sensible advice. Then through the magic of "Web 2.0" and bigco work on "Accessible Rich Internet Applications" the advice was made to disappear [1].
Nowadays when you mention the issue on the web, instead of trying to understand and imagine low-powered devices, limited browsers, restricted environments, or maybe just security-concious people who are effectively disabled by this "Web 2.0" bullshit, people claim that you're using the term "accessibility" wrong.