Pentasis wrote:
Basically it is a bad idea to mark-up aural properties when it comes to accessibility.
It does not follow from the fact that popular screen readers ignore publisher aural/speech CSS or the reasonable argument that they _should_ ignore such CSS, that providing publisher aural/speech CSS is "bad" for accessibility.
For example, if you want to put a novel online with aural/speech CSS so it can be read aloud by Opera with the Voice plugin with those styles, there's no reason why that's bad for accessibility.
It just means that providing aural/speech CSS doesn't do what well-meaning web developers sometimes imagine it should.
However, it would still be nice to hide/show things solely for specific UAs.
Maybe, but I wonder if in practice, the rationales for this tend to boil down to:
1. Working around bugs in someone's code. (e.g. A screen reader fails to deal with Feature X in a webpage, so the developer inserts a message for screen reader users describing a workaround.)
2. A workaround for supporting non-linear, non-gestalt browsing (e.g. additional context for lists of links in a screen reader).
There may be more direct and effective ways to deal with these problems, such as
* Making product support information available to all users (what if the screen reader user has a sighted companion? What if they're using a screen magnifier/reader combination?)
* Fixing browsers and screen readers. * Providing explicit markup for additional context. -- Benjamin Hawkes-Lewis
