Tab through TRs

Accessibility
1

I have a site which is basically just going to present some information in the form of tables. To make it a little more interesting, I’m adding hover and click functionality to the TRs.

But then I wondered about people who just keyboards. Would it be cool to allow them to tab through the TRs, as if they were hovering with a mouse? And to trigger the “click” function when they press “enter”?

And now I’m considering people with screen readers. If I did add that tab/enter fallback, would that make navigating the page too cumbersome? After seeing this YUI video on accessibility, I wonder if a better way to do it would be to allow the user to tab to the table, and then use the up/down arrow keys to navigate.

After all of this, I’ve come full-circle and decided that I’m really over-thinking it. There are already perfectly convenient navigational methods available to the mouse-less and screen-readees. The hover and click things are just flourishes that I shouldn’t worry about reproducing.

What does everyone else think?

2

I think it depends on exactly what you’re making.

If you’re making a CMS or some other web application, adding your own navigation methods might not be a bad idea if they really give you productivity benefits.

However, if you’re just creating some table with data in it, I think you should leave it to the more default manners of handling it, since learning new behaviors isn’t likely to be more productive.

3

SDL, I think you are making the hover show up using CSS correct? If so, the CSS equivelent to hover for keyboard users, is :focus. The click may work depending how it is used. (As a keyboard user, I can test)

If not, you need to explain more what you are doing with these…

It might be too much with the pop ups, depending on what they do, info they give etc. Screen readers, i know JAWS the best, have hotkeys once in the table. This is dependent on the user’s level. Basic users will read the tables LTR, top to bottom. Advanced users know how to jump by table headings etc.

4

:active acts like :focus in IE6, so for that reason I’ll have :active with :hover and :focus for styles in general… IE7 fixed :active but didn’t provide a fixed :focus, so there’s no non-javascript way around IE7 (bleh). At least IE8 fixed :focus.

Hm, we developers are already looking forward to IE9 and all the sweet new HTML5/CSS3 junk it’ll support… yet my userbase will likely remain using WinXP for a long time, and IE6 still doesn’t drop below Opera or Safari user levels… sigh…

5

Also use :active, however the rest of what Stomme says is spot on.

6

I’m just trying to figure out why you’d put it on the TR – and of course laughing at how bad the site in question would break for all the people who actively block javascript. (see the various noscript users who pop up here from time to time)

I’d have to see what it is you are trying to do, but it sounds like a total and miserable accessibility /FAIL/ just from what you’ve said so far.

7

SDL, I think you are making the hover show up using CSS correct? If so, the CSS equivelent to hover for keyboard users, is :focus. The click may work depending how it is used. (As a keyboard user, I can test)

:focus does not work correctly (at all) in IE6 or 7, which may still be popular with users of older Windows screen readers.

:focus does not work on elements without a natural focus ability (which would be anchors and form controls). So, not tr’s.

(on)click events can be placed on any element of any type; however if the element is not naturally focus-able, then keyboarders will not be able to reach it unless you’ve also had Javascript add a negative tabIndex (which will allow you to first put focus() on the element before click()).

OP: if this flourish isn’t really adding anything, don’t make it more complicated for everyone else. Sometimes it’s ok to just have something for mouse-users only, because it’s an enhancement (got a mouse? yay you get to do something cool/weird/stupid/cute) and not essential.

Screen readers differ in how good they are at showing DOM updates done by Javascript, and this assumes the user hasn’t turned Javascript off due to any problems it has caused with their reader. Newer readers tend to be better with DOM updates, in general. If this is done with CSS, then it’s presentational anyway and users of text browsers and screen readers and whatever else shouldn’t notice its absence or presence either way.