A user needs some kind of pointing device to 'hover' an element:
The :hover pseudo-class applies while the user designates an element (with some pointing device), but does not activate it. For example, a visual user agent could apply this pseudo-class when the cursor (mouse pointer) hovers over a box generated by the element. User agents not supporting interactive media do not have to support this pseudo-class. Some conforming user agents supporting interactive media may not be able to support this pseudo-class (e.g., a pen device).
You can provide some kind of effect for the :focus pseudo class in addition to the :hover effect. This way users with just a keyboard can see which element is currently selected.
(Note that IE5 has some issues [dbaron.org] with the ordering of :focus.)
I've got a nav with mouse over and out effects on images/links. How do you guys handle this on an accessibility point of view
A solution is to replace those js rollover menus with css rollover menus. In a CSS menu, the nav bar is styled as a list of links (these can be manipulated into a horizontal row, if that's what you want), then each link can be given a background-image to emulate a button. The tex of the button is the actual text of the link (although a recent thread [webmasterworld.com] details what seems to be a pretty decent way to replace that text with an image).
This way, screen readers and other image disabled devices still get the pure text menu. It also makes the nav bar more spider-friendly since it's text marked up in a nice semantic way, instead of JS delivered images.
For lots of examples and explanations of how to mark up link lists in this way, check out Listamatic [css.maxdesign.com.au].
Thaks to all of you, I've replace the little images with a big one and text and put the links (with :hover/:focus state) in a list and positionned them using some examples found around the web (css-p) - the page validate and is accessible according to Bobby Standards - I'm thrilled it was my first attempt to accessibility.