If I wanted to imply that Google will punish your website for being rendered with JavaScript, I probably would have said so. It would likely be false too, as it is less of a punishment, than it is not maximizing your chance to rank (to put your best foot forward as a website).
Accessibility is not a numbers game. In many countries it is a legal requirement. And adhering to the WCAG means providing non-JS fallbacks or progressive enhancement. RMS not being able to access your content is an accessibility issue too, it does not have to involve a disability. It can be technical in nature, like disabling JS or being behind a corporate firewall, or your browser not supporting pushstate.
If you want to look at stats, take a look at the stats and surveys on accessibility of dynamic web applications. Just because your screenreader supports JavaScript does not mean you have no accessibility issues due to JavaScript. Rich internet applications should use WAI-ARIA. I don't think people who create websites without a fallback (avoiding this issue entirely), will worry about creating websites with ARIA-support. And if they do care about such accessibility, they should also provide a non-ARIA non-JS fallback.
Google making this change makes it possible to have your non-fallback JS-only application be indexed. It does not make it more attractive from an SEO or accessibility viewpoint.
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 (the RMS example). Creating an accessible site is a challenge regardless of what technologies you pick, for sure. Just as saying "just because your screenreader supports JavaScript does not mean you have no accessibility issues", just because your website uses JavaScript doesn't mean you have accessibility issues. A plain HTML website can have accessibility issues. So can a JavaScript one.
AFAIK, nothing in WCAG says you must have a non-JavaScript fallback to adhere to their standard. If you can back that up I am all ears, I would be interested to read it.
> Google making this change makes it possible to have your non-fallback JS-only application be indexed. It does not make it more attractive from an SEO or accessibility viewpoint.
The attractiveness of JS heavy development is not in an inherent SEO or accessibility benefit. Absolutely true.
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. You can debate this benefit, but don't imply that single-page apps cannot have SEO on par with HTML sites and good accessibility.
>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?).
Accessibility is not a numbers game. In many countries it is a legal requirement. And adhering to the WCAG means providing non-JS fallbacks or progressive enhancement. RMS not being able to access your content is an accessibility issue too, it does not have to involve a disability. It can be technical in nature, like disabling JS or being behind a corporate firewall, or your browser not supporting pushstate.
If you want to look at stats, take a look at the stats and surveys on accessibility of dynamic web applications. Just because your screenreader supports JavaScript does not mean you have no accessibility issues due to JavaScript. Rich internet applications should use WAI-ARIA. I don't think people who create websites without a fallback (avoiding this issue entirely), will worry about creating websites with ARIA-support. And if they do care about such accessibility, they should also provide a non-ARIA non-JS fallback.
Google making this change makes it possible to have your non-fallback JS-only application be indexed. It does not make it more attractive from an SEO or accessibility viewpoint.