Add tabindex support

Hi @foxpc,

To do this, you’ll need to override all of the callback functions which print the fields. To do this, you’ll hook into the rtb_booking_form_fields filter to adjust the [array which defines the booking form fields](https://github.com/NateWr/restaurant-reservations/blob/master/includes/Settings.class.php#L747-L854).

Each field has a [callback function](https://github.com/NateWr/restaurant-reservations/blob/master/includes/Settings.class.php#L792) which prints the output. You’ll want to override those with your own.

You can see an example of this in action in [this gist](https://gist.github.com/NateWr/f2bea22519667bf905f2).

However, I would encourage you not to do this. Setting the tabindex explicitely can be aa hostile act for screen readers or other users who must interact with sites with a keyboard. Upon loading, the user’s focus is immediately set in the first item with tabindex, and this hijacks their control in a way which might not be desire.

Also, users should be able to tab through the form normally anyway. It’s usually best to offer a “Skip to content” link which allows the user to jump directly to the form.

The only problem with keyboard-based browsing with the booking form is that upon completion of the date input, the focus is not returned to the form. However, adding tabindex won’t solve this problem.

I’ve gone ahead and created an issue to [improve the focus handling after selection of a date or time](https://github.com/NateWr/restaurant-reservations/issues/88). But I can’t promise that it will be implemented soon.

Hi great explanestion!
the booking form is on popup so when i focus the popup content and press the tab key, it not moves between the booking fields. that why i thought to add the tabindex.

any suggestions here?

Thanks

Modals (popup content) present difficult accessibility challenges. In the past, the way I’ve done it is to save where the current focus is before a modal is opened, inject the focus into the modal, then return the focus to that place after the modal is closed.

That still doesn’t solve the problem when a user tabs out of the modal. THey’ll often end up dropped somewhere they don’t want to be in the page. To solve that problem, I add hidden, focusable elements at the top and bottom of a modal. When a user hits these, it bumps them back to the other end of the modal so they can’t escape it.

Of course, then you have to make sure the user can close the modal from within it or they’ll be trapped forever.

As I said, it gets pretty complicated. The most I’ll probably do for the date and time pickers is to restore the focus to the booking form when they’re closed.