4 ms·

Javascript isn't an accessibility issue. Modern screen readers work by interacting with a standard web browser, not by implementing their own browser engine. Ja

Javascript 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 ago
interesting, 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 ago
  On the other hand, people complain about my "old-fashioned" web sites that are just html and css. But they load really fast :-)
csande17 5y ago
It 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.

alphabet9000 5y ago

interesting, 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 ago
On the other hand, people complain about my "old-fashioned" web sites that are just html and css. But they load really fast :-)

csande17 5y ago

It 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.