The Forest Service worked with 18F on this Open Forest project to enable people to buy Christmas tree permits online, which uses United States Web Design System components: https://openforest.fs.usda.gov/christmas-trees/forests
https://openforest.fs.usda.gov/christmas-trees/forests has a pretty heavy dependency on Javascript (read: there's no fallback to anything non-javascript, so I get a white page). It feels like that goes against some of the things that 18F is about.
Pages don't need a fallback to non-Javascript in 2019. Accessibility technologies now fully support a JS enabled web, with accessibility standards following suit.
That leaves only those who have voluntarily disabled JavaScript (<1% of users), but fortunately those users are typically aware of how to resolve the issue of their own creation.
I've worked on public facing government websites (not 18F). We simply don't support this edge case, and our legal department supports our legal right to do so (in particular in relation to ADA requirements).
I wholeheartedly disagree. This is a public-facing government website. It ought to degrade gracefully in order to reach the broadest possible audience. Or, write a decent site to start with, and you wouldn't have to worry about degrading. The entire page is nothing but a shell for a web app written in JavaScript that doesn't need to be a web app written entirely in JavaScript.
> It ought to degrade gracefully in order to reach the broadest possible audience.
You mean under 1% of users that intentionally broke their browser?
Seems unreasonable to dedicate resources to that, that could be better spent on 99% of our users. Why should the 1% get special treatment? And what other parts of their browser can they disable that we need to support, perhaps no CSS? Maybe IE5? Maybe they only render XHTML? Etc.
> You mean under 1% of users that intentionally broke their browser?
I'd say: configured their browser to work like a browser instead of like a platform to run arbitrary code from the Internet.
Ideally we should be able to trust most of the web sites we visit. The last few years have shown us this is a bad idea, here are my two top reasons:
- security: while I'm personally less concerned with reasonable ads there are a number of problems with ad technology, like infectious ads and creepy tracking.
- a bigger problem for now IMO: poorly written web apps that makes the machine noticably slower.
There is still one important scenario that benefits from supporting a fallback to "classic" HTML for web sites (and apps): Bandwidth constrained environments. GMail's plain HTML version is an existing example (a link to it shows up if the JS version takes too long to load).
Anyway, for public facing sites and apps, you may already be doing most of the necessary work for SEO purposes. Letting humans access the version that you're showing to search engine spiders shouldn't be a huge burden.
> Pages don't need a fallback to non-Javascript in 2019.
Strongly disagree. Having your page completely break instead of degrading gracefully puts up a barrier to those who cannot run JavaScript (for example, users with older, weaker computers).
People on "older, weaker computers" are likely running a browser we also don't support (<IE10) on an Operating System we don't support, and they'll likely see a TLS error before even hitting the load balancer (we don't support SSL or TLS 1.0).
It is unlikely that there exists a subset of users with a modern enough computer to even hit our web servers that is under-powered to the point of not handling JavaScript. Our analytics definitely don't show this.
> It is unlikely that there exists a subset of users with a modern enough computer to even hit our web servers that is under-powered to the point of not handling JavaScript. Our analytics definitely don't show this.
Does your analytics correctly register hits from clients that doesn't support Javascript (I'm thinking about survivorship bias).
Thank you for the response. I wasn't trying to suggest that it was a requirement, simply that it seemed odd that there would be no fallback whatsoever. I guess I'm behind the times.
> Pages don't need a fallback to non-Javascript in 2019. Accessibility technologies now fully support a JS enabled web, with accessibility standards following suit.
I think we should broaden the definition of accessibility to make websites aren't unneccesarily annoying or invasive for normal users either ;-)
(And yes, making web applications is part of my job.)
> Pages don't need a fallback to non-Javascript in 2019. Accessibility technologies now fully support a JS enabled web, with accessibility standards following suit.
This is wrong, of course, because it requires that people buy expensive hardware to use the latest accessibility technology, which is not generally available. It's like demanding that people buy electric-powered wheelchairs instead of making your building accessible to normal wheelchairs.
> We simply don't support this edge case, and our legal department supports our legal right to do so (in particular in relation to ADA requirements).
And I'm sure that ignoring poor people enables you to sleep very well at night.
If you disable a tool which you know is used to build many websites nowadays then you really should expect a deprecated experience. You're in the minority and honestly I don't know why you should expect web developers to cater for you.
Because things like blogger and Google groups shouldn't require js to just view text. There is a large, large, enormously large body of work out there that doesn't need JavaScript to achieve its goal like showing text or images, but are more-or-leas broken without JavaScript. That's the tragedy. I don't expect a web app, such as Google maps or Google docs to work without js, but I should be able to read blogs and newsgroups.
First, as a person who makes web sites and apps, I believe it's unprofessional to fail to account for users who can't or won't run JS. JS abuse is rampant. I choose not to let sites run JS by default because I don't trust most sites not to have some sort of compromise or malware.
Second, it's fine with me if some site wants to forgo my patronage, or provide "a deprecated experience", but not the government.
I certainly do expect my federal, state and local government to follow best practices and provide working websites that I can use without running JS.
I can't think of a single function of government that requires JS, thank God.
At this point, there is no reason to support <IE11 style JS, but JavaScript-less browsers are still A Thing and always will be. Search engines, Opera Mini, various accessibility thing, people with extremely low bandwidth, and weirdos who choose to disable JS are all factors.
Yes, if you're making a webapp, there's no good way to do it without JS and you can just be upfront about that. Also, people who can't use ES6+ are going to zero over time, so it's fine to just write ES6. But you should also have a no-JS fallback version of an information page (anything that's not a webapp) because that's an important usecase that won't drop to zero over time.
You can learn more about that project here, including the open source code: https://18f.gsa.gov/what-we-deliver/forest-service/ - and a few blog posts about it: https://18f.gsa.gov/tags/forest-service/
Both that Forest Service project and Federalist run on cloud.gov, which is a Platform as a Service operated by 18F.
(I work for 18F but don't officially represent it here.)