What framework are you using that allows you to design interactive web apps without JS?
This is a Rails consultancy, so... Rails. We use Foundation for most things view-side (which, admittedly, involves some Javascript, but only for certain parts; said parts aren't used very often), but pretty much all the heavy lifting is done controller-side. We do like using AJAX here and there, mind you, but only when actually necessary.
Sure, it ain't Trello with its drag-and-drop doodads and such, but we've built plenty of rather excellent web apps without such gizmos. That degree of interactivity isn't strictly necessary, and - in fact - can often be a distraction.
For my personal projects, I've mostly been using Elixir lately (with the Sugar framework), and Pure instead of Foundation for CSS-related things.
So how do screenreaders handle jQuery? Because at the end of the day React and jQuery manipulate the DOM in the same way. React renders to a virtual DOM then diff's that with it's representation of the real DOM and applies only that diff in the same way you might do $('#myElement').css('color', 'red); Some frameworks like angular even have modules specially for screenreaders (https://docs.angularjs.org/api/ngAria).
Not as well as you'd think.
Screenreaders do read the DOM rather than directly from HTML documents, so a JS-only site that's otherwise static wouldn't have very many problems in all likelihood. The problems arise when the DOM is manipulated; screenreaders (including Aria) have tended to have rather pessimal behavior when encountering things like JQuery popups (for example), whether that means failing to read the popup entirely, reading only part of it, reading only an "OK" button, reading it but then reading everything after it even if said everything has already been read, etc. I mentioned these things in another comment on this thread [0].
This isn't to mention that JS-only apps tend to be very mouse and touch heavy. This is a non-starter for most blind users, who AFAIK tend to be very keyboard-centric.
Trello is a perfect example of what I would consider a "web app", it's simply not possible to recreate without JS.
Maybe not exactly, but all its functionality is arguably possible without any Javascript whatsoever.
Let's start with moving cards between lists. Currently, one has to drag-and-drop. There's little reason why that can't instead be implemented as left/right arrow buttons on each card, each resulting in a POST to the server telling it to move the card with the specified ID to the next list in whichever direction. The server then updates the card on its end and sends back the updated HTML.
Then, there's the reordering of cards. Again, totally possible; just put up/down arrow buttons on each card. Same deal as before; server performs the reorder and sends back the result.
For adding cards to lists (and adding new lists to boards), there are already links present to do those things; making them do the same thing as above (leave all the processing to the server, which then sends back the updated HTML) would work quite alright.
You then have the side menu. The pop-out would indeed be impossible without Javascript, but its functionality wouldn't; the "Add Members..." button could point to a separate member add page (or be replaced with the current result of clicking that button, which is simply a text box prompting for an email address to search for), while the member list and the activity feed can easily be rendered server-side.
Same story for the individual list menus; the pop-out requires Javascript, but the rest is trivial to render server-side as part of the list's div.
Then we have the card screen, which can easily be its own page. Like above, pretty much everything here can be done without Javascript with very little workflow difference - comments, labels, checklists, attachments, you name it. All the buttons you see on the right of the card window in current Trello can easily direct to screens for creating each thing.
Now, perhaps the above hypothetical no-JS Trello isn't as "interactive" as you'd like, but it would already be far more accessible, relying less on DOM updates and drag-and-drop operations while being much friendlier to keyboard users and - in all likelihood - performing just as well if not better (even with page loads factored in). And, of course, this would be a perfect candidate for progressive enhancement, layering Javascript on top of the HTML-only layer in order to add the more "interactive" things like drag-and-drop and popout menus and working as a "single-page" app.
While I fully agree that Trello could be js-free I don't think either of us would have known the name "Trello" to talk about today if it was. I understand that you can degrade your web app to the point it works without JS but at what (UI/UX) cost? I could, given time, recreate the entire platform I code on every day to be js-free but I'd be fired for pissing off clients. I could probably even reimplement our google map that you can draw a polygon on without JS but it would take a LOT more time and it would be so painful to use that it wouldn't matter.
I don't want to say people who rely on screen readers don't matter and I think it can be fixed for them. However people who disable JS really shouldn't matter to you unless you are Facebook, Google, Apple, Amazon, etc. Even then some of those sites don't work without JS which could (Like google drive). It's simply not worth the resources to support a small group of people who have knocked out the foundation of a house and are expecting it to stand up just fine. "Screen readers don't play nice with js frameworks" (which is not true across the board) are not an argument for no-js, it's an argument for building better screen readers.
When it comes to the web you need to optimise for the 98% not the 2% (I'm being generous with that 2% number BTW) especially when that 2% CHOOSE to create this problem for themselves.
While I fully agree that Trello could be js-free I don't think either of us would have known the name "Trello" to talk about today if it was.
I disagree. Very little (if any) actual functionality would be lost. The differences would be more-or-less cosmetic and (to a limited extent, though I think this would be positive rather than negative in many cases) ergonomic.
I understand that you can degrade your web app to the point it works without JS but at what (UI/UX) cost?
None if you design your app with progressive enhancement in mind. Drag-and-drop and other forms of "interactivity" could be added onto the non-JS version rather easily.
It's simply not worth the resources
It costs resources if it's not something you consider right from the get-go.
In other words, it only looks like it would use more resources because you're coming at this from the perspective of "okay, here's a JS-heavy app; how do we make it JS-free?" instead of the more efficient perspective of "okay, here's an app solely in HTML, CSS, and Rails; what JavaScript should we add to make this cooler?". The former is like trying to learn how to ride a motorcycle before learning how to ride a bicycle.
"Screen readers don't play nice with js frameworks" (which is not true across the board) are not an argument for no-js, it's an argument for building better screen readers.
I agree with this. That doesn't mean that the existence of Javascript can always be assumed.
Comments
This is a Rails consultancy, so... Rails. We use Foundation for most things view-side (which, admittedly, involves some Javascript, but only for certain parts; said parts aren't used very often), but pretty much all the heavy lifting is done controller-side. We do like using AJAX here and there, mind you, but only when actually necessary.
Sure, it ain't Trello with its drag-and-drop doodads and such, but we've built plenty of rather excellent web apps without such gizmos. That degree of interactivity isn't strictly necessary, and - in fact - can often be a distraction.
For my personal projects, I've mostly been using Elixir lately (with the Sugar framework), and Pure instead of Foundation for CSS-related things.
Not as well as you'd think.
Screenreaders do read the DOM rather than directly from HTML documents, so a JS-only site that's otherwise static wouldn't have very many problems in all likelihood. The problems arise when the DOM is manipulated; screenreaders (including Aria) have tended to have rather pessimal behavior when encountering things like JQuery popups (for example), whether that means failing to read the popup entirely, reading only part of it, reading only an "OK" button, reading it but then reading everything after it even if said everything has already been read, etc. I mentioned these things in another comment on this thread [0].
This isn't to mention that JS-only apps tend to be very mouse and touch heavy. This is a non-starter for most blind users, who AFAIK tend to be very keyboard-centric.
Maybe not exactly, but all its functionality is arguably possible without any Javascript whatsoever.
Let's start with moving cards between lists. Currently, one has to drag-and-drop. There's little reason why that can't instead be implemented as left/right arrow buttons on each card, each resulting in a POST to the server telling it to move the card with the specified ID to the next list in whichever direction. The server then updates the card on its end and sends back the updated HTML.
Then, there's the reordering of cards. Again, totally possible; just put up/down arrow buttons on each card. Same deal as before; server performs the reorder and sends back the result.
For adding cards to lists (and adding new lists to boards), there are already links present to do those things; making them do the same thing as above (leave all the processing to the server, which then sends back the updated HTML) would work quite alright.
You then have the side menu. The pop-out would indeed be impossible without Javascript, but its functionality wouldn't; the "Add Members..." button could point to a separate member add page (or be replaced with the current result of clicking that button, which is simply a text box prompting for an email address to search for), while the member list and the activity feed can easily be rendered server-side.
Same story for the individual list menus; the pop-out requires Javascript, but the rest is trivial to render server-side as part of the list's div.
Then we have the card screen, which can easily be its own page. Like above, pretty much everything here can be done without Javascript with very little workflow difference - comments, labels, checklists, attachments, you name it. All the buttons you see on the right of the card window in current Trello can easily direct to screens for creating each thing.
Now, perhaps the above hypothetical no-JS Trello isn't as "interactive" as you'd like, but it would already be far more accessible, relying less on DOM updates and drag-and-drop operations while being much friendlier to keyboard users and - in all likelihood - performing just as well if not better (even with page loads factored in). And, of course, this would be a perfect candidate for progressive enhancement, layering Javascript on top of the HTML-only layer in order to add the more "interactive" things like drag-and-drop and popout menus and working as a "single-page" app.
[0]: https://news.ycombinator.com/item?id=9815655
While I fully agree that Trello could be js-free I don't think either of us would have known the name "Trello" to talk about today if it was. I understand that you can degrade your web app to the point it works without JS but at what (UI/UX) cost? I could, given time, recreate the entire platform I code on every day to be js-free but I'd be fired for pissing off clients. I could probably even reimplement our google map that you can draw a polygon on without JS but it would take a LOT more time and it would be so painful to use that it wouldn't matter.
I don't want to say people who rely on screen readers don't matter and I think it can be fixed for them. However people who disable JS really shouldn't matter to you unless you are Facebook, Google, Apple, Amazon, etc. Even then some of those sites don't work without JS which could (Like google drive). It's simply not worth the resources to support a small group of people who have knocked out the foundation of a house and are expecting it to stand up just fine. "Screen readers don't play nice with js frameworks" (which is not true across the board) are not an argument for no-js, it's an argument for building better screen readers.
When it comes to the web you need to optimise for the 98% not the 2% (I'm being generous with that 2% number BTW) especially when that 2% CHOOSE to create this problem for themselves.
I disagree. Very little (if any) actual functionality would be lost. The differences would be more-or-less cosmetic and (to a limited extent, though I think this would be positive rather than negative in many cases) ergonomic.
None if you design your app with progressive enhancement in mind. Drag-and-drop and other forms of "interactivity" could be added onto the non-JS version rather easily.
It costs resources if it's not something you consider right from the get-go.
In other words, it only looks like it would use more resources because you're coming at this from the perspective of "okay, here's a JS-heavy app; how do we make it JS-free?" instead of the more efficient perspective of "okay, here's an app solely in HTML, CSS, and Rails; what JavaScript should we add to make this cooler?". The former is like trying to learn how to ride a motorcycle before learning how to ride a bicycle.
I agree with this. That doesn't mean that the existence of Javascript can always be assumed.