Many screen readers can, but not all. It depends on if they themselves are a standalone UA, or if they work on top of an existing visual UA (browser). Braille interfaces, tappers, and so forth often can't simply sit atop a browser and have to act as their own user-agent.
It all depends on the user agent.
Also, contrary to popular belief, accessibility isn't JUST for screen readers. Again, many users are in workplaces that outright block client-side scripting for "security reasons". (that's in air quotes, blocking scripting is oft more paranoia than fact). Millions of people have downloaded tools like noScript out of distrust.
(side note, horrifically bad website!)
Just as websites are supposed to be about more than just sighted users on screens, accessibility is about more than just screen readers.
That's the same mental failing as "but it's fast on my computer". Well lah-dee-huffing-dah for YOU! Doesn't matter if it's painfully slow for half the world how fast it is for YOU. Thus, "but it's fine in JAWS" or "but it's fine on my Apple reader" -- well lah-dee-huffing-dah for JAWS and crApple.
Graceful degradation is an all-important part of the WCAG's "perceivable" section. Scripting off, CSS off, images off, markup stripped out/inapplicable... a well written accessible page should to all these things and still be useful to the end user.
Anyone telling you otherwise doesn't know what websites are or who they are for.
Mind you again, websites. IF you have a LEGITIMATE excuse like an application that simply cannot be implemented without such things (Google Maps) or you have full control over the UA (electron, nw.js) then you inherently cannot be accessible, and can squeak by.
But if it's something like a contact form, shopping cart, of general text content on a website? Well, then you've screwed the pooch.