Is this issue complete? Last char in the description is a comma.

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.

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.

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.

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.

That is another accessibility described here.

I consider this not quite as serious as it's not a regression per se – these tabs didn't exist in 1.x, and section headers are still available. Definitely a bug that should be fixed, but not blocking 2.0 IMO.

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.

IIUC the major issue reported here then is that the 'delete' button does not have a focus highlight style?

Trying to make this issue actionable without "take everything apart and rebuild from scratch".

Task: CloudBees would like to review what accessibility improvements need to be made to new tabs UI.

No response by reporter clarifying what exactly needs to be done here, so punting to post-2.0.

gusreiber Is there a quick and easy way to add keyboard focus highlighting to the X button?

taking a look.

....waiting for gitHub.

Code changed in jenkins
User: gusreiber
Path:
war/src/main/js/widgets/config/tabbar.less
http://jenkins-ci.org/commit/jenkins/99e482b2a94102c6c2b3445c2fa1514f242fede5
Log:
JENKINS-33930 focus color for delete

style only.

Code changed in jenkins
User: Daniel Beck
Path:
war/src/main/js/widgets/config/tabbar.less
http://jenkins-ci.org/commit/jenkins/c403e88f44034919de07ddb3d6b419c5016f77d7
Log:
Merge pull request #2227 from jenkinsci/FIX-JENKINS-33930]

JENKINS-33930 focus color for delete

Compare: https://github.com/jenkinsci/jenkins/compare/e6df9f55bb6b...c403e88f4403

Is it a known issue the rendering of the delete button in config panels ?

I didn't find it reported but I saw it for a long time

Ok I just found JENKINS-35178 and PR https://github.com/jenkinsci/jenkins/pull/2378 by recena

teilo, Could you confirm whether it was fixed on JENKINS-35178?

Was partially fixed by https://github.com/jenkinsci/jenkins/pull/2227 (delete not showing focus)
Tab seems order is fixed
Tab selecting UX issue(s) remain

• Can not change them with tab
• Highlighted tab is not for the section you are editing/has focus (but is the same now if you use the mouse - the tab highlight matches what is at the top of the screen)