- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Tue, 01 Apr 2008 08:00:51 +0100
Henri Sivonen wrote: >> I understand your point about superfluity being defined by the >> presentation (one could argue the same about relevance...). Aural CSS >> seemed, at one point, like it would make sense for handling such >> issues. However, since screen readers read the "screen" media styles, >> it doesn't really help. > > More to the point, it is unreasonable to expect casual authors to supply > sensible aural CSS even if it were supported. I think that assumes authors would need to devote the same energy to overriding default aural CSS that they spend on overriding default screen CSS. I don't think that's the case because the default presentation is mostly fine. Yes, there are problems with pronunciation, but CSS seems to the wrong layer for solving questions of meaning. And yes, you might want to specify default voices for different interlocutors, but that's an edge case. Customizations of this sort run the risk of colliding with the native use of alternate voices for semantics by speaking agents (e.g. the JAWS Web Rent-a-Crowd scheme), so they aren't necessarily desirable in run-of-the-mill web content. The main uses of speech CSS, were screen readers to apply it, would probably be to force rendering of content with display and to silence content with display or speak. I don't think this would be radically more difficult than the commonplace display: none; technique that currently doesn't work and it would arguably be as easy as the off-screen hiding technique that sort of does. So I don't think it's especially unreasonable. > As currently drafted, ARIA has aria-hidden, which is essentially a less > elegant duplicate of HTML5 'irrelevant'. As far as I can tell, ARIA > doesn't specify aria-hidden=false as overriding display: none; in > accessibility API exposure. (But then in general, ARIA doesn't specify > processing requirements in the way we expect from HTML5.) Hmm ? http://www.w3.org/TR/wai-aria/#hidden seems to be specified as equivalent to visibility: hidden, a property that theoretically shouldn't affect speech rendering but does (accidentally) hide content from screen readers. It doesn't say anything about display: none;. It's not at all clear that it's intended to meet the same use-case of @irrelevant, but if it is then I doubt it will help solve these problems arising from different media and modes of access. How are you envisaging aria-hidden might help? -- Benjamin Hawkes-Lewis
Received on Tuesday, 1 April 2008 00:00:51 UTC