A real problem with getting accessibility issues to be taken more seriously, is that it's being viewed in terms of cost/benefit; as Joe Clark has recently said, accessibility is being viewed as a "feature" -- http://joeclark.org/ice/iceweb2006-notes.html
But it's not a feature, and it's not okay to think of it in terms of metrics. If we all did that, then no services would be accessible at all, because people with disabilities will probably always be in the minority.
And now, because so many people do think like that, the law has no choice but to step in and say "you must do this". I don't like that at all, but what's the option? As long as people view access in terms of their own convenience, rather than the convenience of the people who actually need help, this dichotomy will persist.
<steps down from soapbox>
Have a look here for more raw data on which such inferences can be based - http://www.access-matters.com/index/...ascript-tests/
RE: Speak support / aural CSS - none of the tested devices support aural CSS. It's funny actually .. a screen reader is a "screen" reader, not a "text" or "source" reader - it's designed to provide information about the visible screen that would otherwise not be available to someone who's blind - so in a sense it's perfectly correct that its media type should be "screen" and not "aural".
Opera + Voice supports aural CSS, but its intention is different. It's designed to provide additional speech input and output for someone who's not (or not completely) blind - it helps more with cognitive and motor disabilities, or low vision, and isn't a screenreader in the same sense at all, as it isn't useable if you're completely blind.
But there is a Linux screenreader called Emacspeak which supports aural CSS, though that's all I know - just the name!