-
Bug
-
Resolution: Cannot Reproduce
-
Critical
you can no longer use the keyboard to navigate on the restyled "FreeStyle" job configuration page.
There is no way to change the tabs which would confuse a user (they are not tabs - but look like tabs? - when an item gets focus via a tab key the "tab" thing should change highlight as it does if you just scroll
The tabbing order of the items and help is completely out of whack.
The red X on a build step never seems to receive focus
- links to
[JENKINS-33930] new tabbed job config page broken accessibility
The tabbing order of the items and help is completely out of whack.
Not a regression from 1.x. Order there is browser UI/chrome, then help, then page navigation/header (which is mostly gone from 2.x), then form elements, then footer, and it's still the same in 2.0-beta-1.
The red X on a build step never seems to receive focus,
It's still the last element (even though visually it's first), but could probably use a focus highlight.
The tabbing order of the items and help is completely out of whack.
Do you mean here that tab focus jumps to help icons when adding an item to a hetero-list. If not, I don't understand what the problem is.
| Labels | Original: 2.0 2.0-beta ui | New: 2.0 2.0-beta accessibility ui |
I think the main issue would be with the red X display, here. Tabs may be better to stay excluded from keyboard navigation, as the user can still tab through the form like 1.x.
kzantow I thought the issue was that tab highlighting doesn't change if you use keys to navigate down the page. When you scroll down the form the tab highlighting changes based on your location. I agree that using keyboard to go through tabs would make things more difficult.
If it is possible to navigate to the red X with keyboard and we simply have to show this better with highlighting then I don't think this should be a critical bug blocking release. As long as there are no regressions from 1.x functionality I would rather not risk breaking something else before we release.
| Description |
Original:
you can no longer use the keyboard to navigate on the restyled "FreeStyle" job configuration page. There is no way to change the tabs which would confuse a user (they are not tabs - but look like tabs? - when an item gets focus via a tab key the "tab" thing should change highlight as it does if you just scroll The tabbing order of the items and help is completely out of whack. The red X on a build step never seems to receive focus, |
New:
you can no longer use the keyboard to navigate on the restyled "FreeStyle" job configuration page. There is no way to change the tabs which would confuse a user (they are not tabs - but look like tabs? - when an item gets focus via a tab key the "tab" thing should change highlight as it does if you just scroll The tabbing order of the items and help is completely out of whack. The red X on a build step never seems to receive focus |
Not a regression from 1.x. Order there is browser UI/chrome, then help, then page navigation/header (which is mostly gone from 2.x), then form elements, then footer, and it's still the same in 2.0-beta-1.The tabbing order of the items and help is completely out of whack.
Hmmm.... I tested this on 1.x before I filed it. I just went to double check and it's as you describe.
hrmpw so yes. If the RedX is not visually highlighted in 2.0 how do you know it is selected - how do you know you have navigated to it?
Do you expect people to just randomly guess what they have selected? In 1.x it gets a nice visual border.
This is critical for anyone that does not / can not use a mouse.
I thought the issue was that tab highlighting doesn't change if you use keys to navigate down the page.
That is another accessibility described here.
Is this issue complete? Last char in the description is a comma.