3 ms·

While this used to be the common wisdom, it's not clear to me that it should still be. Designing a site which smoothly gains features as your browser does seem

While this used to be the common wisdom, it's not clear to me that it should still be. Designing a site which smoothly gains features as your browser does seems ideal, but often takes half again as long. Doing that for the tiny percentage of people who browse with JS off seems perverse when most of the modern web is broken or invisible to them anyway.

reustle 13y ago
The most common reason discussed was screen readers, which can now parse JS powered sites just fine.
- bphogan 13y ago
  "just fine" is not even close to true. Developers have to code it right or it doesn't work right. JavaScript-based sites are as accessible as Flash-based sites - the developer has to know how to make it accessible, or it isn't.
  - jonknee 13y ago
    > JavaScript-based sites are as accessible as Flash-based sites - the developer has to know how to make it accessible, or it isn't. How is that the case? The text is on the screen like any other website would be. It's not an image or in a binary format like it would be with Flash.
    - bphogan 13y ago
      Screen readers can read text in Flash movies if it's bade available as text. and with JavaScript, if it's injected after page load, rather than during, the screen reader may not get notified that the page has changed, so it doesn't know to read it. This is what WAI-ARIA and other things are about. Thankfully JAWS and WindowEyes have free trials, and NVDA is free, so we can actually test things instead of talking about them on HN.
matthewmacleod 13y ago
It really doesn't take that long. Sure, a modern web application, or a site with lots of interactivity, is never going to work without JS. But this is some static content on a page; it would not be hard to make this work without it. Although the time would probably be better spent optimising the page somewhat. 3MB of assets and 85 HTTP requests (including 24 individual stylesheets!) makes for an unpleasant experience.

reustle 13y ago

The most common reason discussed was screen readers, which can now parse JS powered sites just fine.

bphogan 13y ago
"just fine" is not even close to true. Developers have to code it right or it doesn't work right. JavaScript-based sites are as accessible as Flash-based sites - the developer has to know how to make it accessible, or it isn't.
- jonknee 13y ago
  > JavaScript-based sites are as accessible as Flash-based sites - the developer has to know how to make it accessible, or it isn't. How is that the case? The text is on the screen like any other website would be. It's not an image or in a binary format like it would be with Flash.
  - bphogan 13y ago
    Screen readers can read text in Flash movies if it's bade available as text. and with JavaScript, if it's injected after page load, rather than during, the screen reader may not get notified that the page has changed, so it doesn't know to read it. This is what WAI-ARIA and other things are about. Thankfully JAWS and WindowEyes have free trials, and NVDA is free, so we can actually test things instead of talking about them on HN.

matthewmacleod 13y ago

It really doesn't take that long. Sure, a modern web application, or a site with lots of interactivity, is never going to work without JS. But this is some static content on a page; it would not be hard to make this work without it. Although the time would probably be better spent optimising the page somewhat. 3MB of assets and 85 HTTP requests (including 24 individual stylesheets!) makes for an unpleasant experience.