No, he wants it to work without JS, like any site should. Developers should build one site, and use JS for progressive enhancement.
If you made the video with care, then you probably already have a script you used.
If you didn't, https://castingwords.com/ is really, really cheap and does a good job.
A government agency would rather not post a video to it's own site without a transcript (Section 508).
Many people would. For me it depends on the video. I often would rather read the transcript than watch. So yeah, it'd be better for me that the video wasn't even posted so I wouldn't have to waste my time searching for a transcript that didn't exist.
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.
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.
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.
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.
So if you have a web app - a page that needs to run code to provide its value - you have to let it do that.
But if you have a document that is strictly informative then REQUIRING that you run some code just to read some text is simply counter-intuitive. A document shouldn't need to run code to provide its value, NOR SHOULD IT DO SO TO LOOK NICE.
But it's getting harder to do that as we embrace frameworks we don't understand that do it all for us.
In addition, developing that way (instead of with JS in mind) also has a cost which in the end means that you are sacrificing resources developing for those 2% instead of the other 98%. Regardless of whether that approach leads to an easier situation in terms of maintaining JS vs. non-JS, it certainly does not lead to an easier situation than ignoring non-JS altogether.