Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

Any way to outright exclude a control from the tab order? (besides xfa.host.setFocus)

Avatar

Level 4

Hey all,

I've been building forms for three years now, and I've gotten pretty good at forcing them to do what I want. One reoccurring issue is the tab order. My forms have a ton of buttons, and for the most part, I would like to be able to exclude them from the tab order. On top of that, I've seen issues where repeating subforms will confuse the tab order as well. For the past two years, I've been maunally coding in the tab order on a field by field basis. On the exit event of all controls, I include the following:

if (xfa.event.commitKey == 3)

{

     xfa.host.setFocus("SOM");

}

This is, of course, the simplest version. A lot of the time in the last field of a repeatable subform, I detect if there is another instance of the subform, and if so, I set the focus to the first field in the next instance.

The most annoying part of all this is that I wouldn't have to be so hardcore if I could use the Livecycle GUI to exclude buttons from the tab order. If that were the case, I'd be able to save myself a lot of thinking and work. Is there an attribute that I can set to skip the buttons? Even something that I could hardcode into the xml would be worth looking into. Is setFocus my only option?

Thanks for your help... I just want to make sure I'm not doing something that takes a ton of time for no reason. If setFocus is my only option, I'll live with it.

- Scott

1 Accepted Solution

Avatar

Correct answer by
Level 9

Tab order is a huge pain, because it becomes a massive maintenance issue, and can become a huge area for testing and errors.

Our approach has become to NEVER explicitly specify tab order, but always let Reader just "get it right automatically" by creating the fields in the right order in the first place.

This may not work in some situations, but we find it does work in most. Wrap fields in subforms where necessary to control the behavior.

Good luck.

Howard

View solution in original post

3 Replies

Avatar

Level 10

I don't know of any other way.

One thing to keep in mind, I believe buttons are part of the tab order to comply with accessibility guidelines (WCAG 2.0, etc.).

Avatar

Correct answer by
Level 9

Tab order is a huge pain, because it becomes a massive maintenance issue, and can become a huge area for testing and errors.

Our approach has become to NEVER explicitly specify tab order, but always let Reader just "get it right automatically" by creating the fields in the right order in the first place.

This may not work in some situations, but we find it does work in most. Wrap fields in subforms where necessary to control the behavior.

Good luck.

Howard

Avatar

Level 10

Hi,

In addition we have an example form here: http://assure.ly/gBUUXB, which highlight Howard's point about the automatic tabbing order being set by the relative x/y coordinates of objects (working from the top/left) and that once an object in a subform has focus, tabbing will work through the remaining objects in the subform before coming back out to the rest of the form.

Niall