- From: Charles McCathieNevile <charles@w3.org>
- Date: Mon, 21 Jan 2002 09:33:27 -0500 (EST)
- To: jonathan chetwynd <j.chetwynd@btinternet.com>
- cc: David Woolley <david@djwhome.demon.co.uk>, <w3c-wai-ig@w3.org>
Nope, I missed the bit about wanting to generalise this beyond aural. So it
doesn't solve any problems Dave didn't already identify (except taht I would
again suggest that :hover and :focus should trigger the same things - people
don't always have a hovering mechanism as such, although the behaviour of
users with keyboards suggests that the two are equivalent.
chaals
On Mon, 21 Jan 2002, Charles McCathieNevile wrote:
Have a look at the CSS2 properties cue cue-before and cue-after.
Do these cover the effect you are looking for? They can be applied by
element, class, or id, so could provide a general 'earcon' for a type of
element, or could be used to provide a particular sound to associate with a
particular element identified by its id attribute...
(the problem then becomes one of getting that part of CSS2 implemented -
whether in the browsers or by some extension to them).
chaals
On Sat, 19 Jan 2002, jonathan chetwynd wrote:
An idea, but would that mean that we expected a sound to be used more
than once per page?
Perhaps, if we expect each event to have a unique sound, html is the
place to keep it.
However, I'm not sure I've understood the <object> tag, as I'd expect
anchor to be the parent (or child) of <object> in an event based code.
if that makes sense.
thanks
--
Charles McCathieNevile http://www.w3.org/People/Charles phone: +61 409 134 136
W3C Web Accessibility Initiative http://www.w3.org/WAI fax: +1 617 258 5999
Location: 21 Mitchell street FOOTSCRAY Vic 3011, Australia
(or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France)
Received on Monday, 21 January 2002 09:33:55 UTC