3 ms·
The vaccines.gov website's Vaccine Finder requires javascript to run. It could have been served using HTML and a <form>.
by alphabet9000 5y ago
The vaccines.gov website's Vaccine Finder requires javascript to run. It could have been served using HTML and a <form>.
- duskwuff 5y agoJavascript isn't an accessibility issue. Modern screen readers work by interacting with a standard web browser, not by implementing their own browser engine. Javascript doesn't inherently interfere with this in any way. The issue at hand is that these web sites lack accessibility information on some of their controls, making them difficult or impossible for a non-sighted user to interact with. This isn't a problem unique to Javascript; back in the day, one common cause of accessibility woes was the use of unlabelled imagemaps for navigation.
- alphabet9000 5y agointeresting, i didn't know that - thanks. My comment about the site requiring javascript stems from my thinking how needlessly complicated the entire site seemed in general, beyond accessibility. Last year, I would try and open the Louisiana department of health website to look at covid statistics, and it would require about 70MB to load a small little box that displayed some numbers. The popular ArcGIS covid dashboard by Johns Hopkins was the same situation - a single page app that took tens of megabytes to load and was very slow - to the point where it would crash on my computer. It's made me think that specifically for issues of public health and public safety, a priority should be placed on making sure those websites load quickly and run smoothly. Edit - I misspoke when I said it needed 70MB to load - it was 9+ MB of data transferred, 70+ MB resources. Here's a video I saved of the page loading from last year [0] [0] http://telnet.asia/arcgisla.mp4 http://telnet.asia/arcgisla.mp4
- WalterBright 5y agoOn the other hand, people complain about my "old-fashioned" web sites that are just html and css. But they load really fast :-)
- csande17 5y agoIt is possible, with great effort, to create JavaScript-driven UI elements that work correctly when used with accessibility technology. But if you stick to standard form elements, that support often comes by default. For example, if the county dropdown box in the article had been a <select>, it would have automatically worked in the screen-reader without needing to write any additional code.
- userbinator 5y agoIt's ridiculous that you're even being downvoted for what I think is a perfectly valid complaint, and one that I'm increasingly faced with these days. Scheduling appointments and such has been a solved problem for several decades; what are the chances that if this pandemic happened 20 years ago, sites for vaccinations would be usable with only basic HTML, and everyone, even the blind, can use? Instead, today we get sites that need to load dozens of MB of JS that's reinventing the wheel (and forgetting to reinvent accessibility), are hard to use even for sighted people thanks to stupid UI trends like hidden scrollbars and whitespace everywhere, and fail completely if your browser is even slightly older or otherwise unusual. There's really no reason for overcomplicating things other than web developers trying to justify their salary --- or Google attempting to make its effective browser monopoly even stronger. The continual churn of the web and the "doing less with more" direction that things are going is a horrible disease. This isn't progress; it's a regression. A very related discussion from not long ago: https://news.ycombinator.com/item?id=25915313 https://news.ycombinator.com/item?id=25915313