- 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