>Web accessibility, as we commonly use the term, pertains to creating a website that disabled users can interact with an navigate. It does not pertain to those who choose to or are forced to disable JavaScript...

Often web accessibility focuses on people with a disability, correct. Accessibility, like I said, really is more than that, though. From the Wiki: Accessibility is the degree to which a product, device, service, or environment is available to as many people as possible. Hence it does pertain to those who choose to or are forced to disable JavaScript. It literally means _as many people as possible_, RMS included. Even the WCAG do not solely focus on assistive technologies, but include "a wide variety of user agents".

The comment "just because your screenreader supports JavaScript does not mean you have no accessibility issues" was in reply to your statistics on JS-support for screenreaders. 98% of screenreaders supporting JavaScript is moot when less than 75% of browsers support pushState. In other words: You leave much more than 2% of users incapable of accessing your content. WebAim Surveys show that people have increasingly more trouble accessing content on JS-heavy social sites and dynamic web applications.

> A plain HTML website can have accessibility issues. So can a JavaScript one.

A JavaScript site can have a problem. If you serve it without a fallback (under the assumption that 98% of your users can access it that way) then it has a problem for sure. I have nothing against JavaScript. I have a problem with JavaScript sites that don't provide a fallback or weren't build according to progressive enhancement principles.

>AFAIK, nothing in WCAG says you must have a non-JavaScript fallback to adhere to their standard.

It said so specifically in WCAG 1. WCAG 2 is more ambiguous. You can have a no-fallback application that requires JavaScript provided: You can not show the content in any other way (a fallback is impossible), and you clearly explain in <noscript> why JavaScript is required.

Where a fallback IS possible, not providing one lowers accessibility. This is the relevant principle:

Principle 4: Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

If you do not provide a fall-back and require JavaScript then your content can not be interpreted reliably by a wide variety of user agents. Not providing a fall-back goes against this principle.

Relevant guideline:

Guideline 4.1 Compatible: Maximize compatibility with current and future user agents, including assistive technologies.

JS-only non-fallback sites do not maximize compatibility, they minimize it, breaking this guideline.

Government 508 guidelines for accessibility:

When possible, the functionality should be available without requiring JavaScript. When this is not possible, the functionality should fail gracefully (i.e., inform the user that JavaScript is required).

Webaccessibility.com best practices:

Ensure elements that use ARIA provide non-ARIA fallback accessible content.

Since you should markup your rich web apps with ARIA, and you should provide a non-ARIA accessible fallback, you should provide an accessible fallback for your rich web app.

I do know that this can be a point of debate, and that is fine. It is up for interpretation what "maximize compatibility" means to you. If you have legal obligations to maximize compatibility (like government organizations in The Netherlands) then this becomes a harder rule.

> The benefit is a development style that is more productive, giving me more time as a developer to focus on solving the problem at hand, be it business logic, SEO, or accessibility.

I really don't understand this way of thinking. If you want to spend time on accessibility, start with a fallback, don't create a website without a fallback and then cheer on the idea that now you have time left to fix the problem you created a few minutes before that...

If you want to solve problems with SEO, don't start out by creating one :D

> but don't imply that single-page apps cannot have SEO on par with HTML sites and good accessibility.

Good accessibility means good SEO. No fallback means poor accessibility. Draw your own conclusions (Socrates is mortal?).