Currently in both windows and web when using <TAB> the cursor progresses to anything that looks like something a user can enter data. Also the Windows and Web don't behave the same (I wonder where this will take us in Universal); Web does not progress to the next tab/label on a multi tab/label form, whereas windows does (might be due to readonly fields as the last thing on the current form). I can't really tell in Web where the cursor is after a few readonly fields...
I'd like to see that changed in the following sense
- Let the cursor not “land” on a read-only field, but rather ignore them and progress to the next changeable field in the form.
- If there are multiple tabs on a form (either by resolution restriction or by design), let the gui open the next tab (already the case in the Windows gui)
- When tabbing back (<shift>+<Tab> on the first field in a multi tabbed form, select the previous tab on the same form (now a detail tab of the table is selected) or the last tab when the first tab is selected.
- Let the cursor not land on a lookup item (the "magnifying glass” icon)
The behaviour you wish is exactly the behaviour of the "enter” key navigating through the form.
The idea is to navigate quickly through the editable form editors using "enter” and the “tab” key is used to visit focusable controls currently visible on the screen. In the Form this will be buttons and visible inputs. After the end of the form is reached using the "tab” key the focus will be placed on the upcoming component which accepts focus.
We did not designed this kind of the focus behaviour for our Universal GUI. Currently only the "tab” key could be used to navigate through the form or to navigate to other components on the screen using the default browser behaviour.
Ah, clear… I alway used to use the <Tab> key in forms…. I'll swiftly change my method or approach…
Regarding Universal… Let's hope similar functionality is preserved, either with <Enter> or with <Tab>..