PDA

View Full Version : TAB and focus



Shecky
Feb 18th, 2003, 11:27 PM
I have a simple form, and people like to [TAB] through forms, but i have linked images off to the right of some fields, and when i press tab wanting to go to the next field, instead focus is moved to the linked image... its really only just annoying.

I was wondering if theres a way to set the next item to be focused when tab is pressed.

I have the idea running around in my head that theres some kinda super complicated javascript that does it (something like onoutfocus="focus(field2)" or some onkeydown event for tab) I was wondering if there was something very much simpler... maybe that could restrict a certain link from gaining focus?

meow
Feb 19th, 2003, 01:34 AM
tabindex (http://www.w3.org/TR/html401/interact/forms.html#adef-tabindex)

Taa-taa! :p

wac
Sep 8th, 2003, 07:36 PM
What if one wants the tabbing order to completly avoid going to the images although one should still be able to click on the images?

The reason I ask is that I've coded up a spinner control with up/down buttons and I want it to work the same way the windows spinner does (example is desktop properties, Screen Saver tab). You can tab to the entry fields but not to the up/down buttons, although you can still click on them.

brothercake
Sep 8th, 2003, 09:06 PM
I don't understand - why would you want those controls to be accessible by mouse but inaccessible by keyboard?

wac
Sep 8th, 2003, 09:12 PM
I'm trying to mimic the windows spinner control and that is its behavior. The up and down arrow keys provide the appropriate keyboard functions so there's no real need to be able to separately tab to the controls.

brothercake
Sep 8th, 2003, 09:18 PM
Ah but there is - what if you can't use a mouse?

I don't know what Windows Spinner is, but I can be reasonably confident that, if it's not accessible by keyboard, this is a mistake rather than by design.

wac
Sep 8th, 2003, 10:52 PM
It is accessible by keyboard. The buttons are the up/down buttons. Since the up/down arrows do the associated functions that the up/down buttons do, its not necessary to tab to the buttons to
activate the functions, simply use the keyboard equivalents. So the control is fully keyboard accessible. If you allow the buttons to be tabbable (yikes, ok, accessible) then it will take 3 tab keystrokes to move from this control to the next control. In situations where you're using multiple spinners it becomes really annoying without adding any additional function (since the functions are already fully available from the keyboard)

brothercake
Sep 8th, 2003, 10:58 PM
Oh, so the up/down buttons are equivalent to the buttons on a scrollbar - they scroll the whole page?

Well that's different :)

You can't actually prevent an element from receiving the focus, but you can reject it again once it does. The brute approach is like this:

<element onfocus="this.blur()">

But that's not good, because it doesn't send the focus anywhere useful - it's effectively lost, and browsers will vary in which element next receives focus when you press Tab again.

The thing to do is decide where it should go to next:

<element onfocus="refToObj.focus()">

But it would be probably be easier to call a function, something like

<element onfocus="sendFocusTo('foo')">

then

function sendFocusTo(whatever)
{
document.getElementById(whatever).focus();
}

But remember that only links and form controls can receive the focus x-browser.

wac
Sep 8th, 2003, 11:04 PM
This is a different topic but...

Since you seem to be an accessibility advocate (just an observation), are you familiar with the Section 508 accessibility guidelines? Ok, you're in the UK and this is a US regulation. Is there anything similar in the UK?

For example, the 508 guidelines require many things to work with or without style sheets (just when I was beginning to figure out how to use them).

There seems to be a lot of things contained within which would make me think that no web application could possibly satisfy section 508. This deals with much more than just being able to access all functions from the keyboard.

Do you have any recommendations for documents that contain a sane list of guidelines for web applications to do to satisfy the spirit of accessibility?

brothercake
Sep 8th, 2003, 11:12 PM
Section 508 is very similar to (essentially based upon) the Web Content Acccessibility Guidelines - http://www.w3.org/TR/WAI-WEBCONTENT/ There may be minor differences, but WCAG is the one the follow.

In the UK we have the Disability Discrimination Act - it doesn't specifically mention the web, but it talks about the requirements of "premises" to be accessible, and websites are deemed by precedent to be premises.

There are a few cases going through at the moment, but I try not to pay much attention to them - the law is beside the point. It's self-evidently the right thing to do, as well as opening your site to a wider market. People with disabilities have $$ to spend, and they will, if you make it so they can :)

Accessibility seems, at first, almost ridiculously difficult, but it's not that bad once you let go of a few preconceptions (which maybe you already have)

- the web is not DTP - you cannot control what a page looks like, you only suggest it

- ditch tables for layout, font tags, and all presentational HTML - write semantic XHTML and do all styling with CSS

- browser/window control from a webpage is a bad thing - don't open or manipulate windows, don't write to the status bar or override the context menu

And much of acccessibility is common sense - remembering that other people are not the same as you. Keyboard control is one good example; color is another - some people are colour blind and cannot distinguish certain colours, so don't rely on color to indicate information - links, for example, should always be underlined, not just a different color.

A good place to start, if the WCAG seems a bit overwhelming for now, is http://diveintoaccessibility.org - it's written with blogs in mind, but most of what it says generally applies. What that guide is particularly good at is putting faces to the guidelines - showing you what kind of people will benefit from the things you do.

And there's a good validator at http://www.contentquality.com It helps a lot, but accessibility is always, to some extent, a judgement call. The most reliable thing is to go through the guidelines yourself, asking yourself if you satisfy each one.

Oh, and stay away from Bobby; it will not help.