Skip to content
This repository

Select with custom menu not keyboard accessible in 1.1 rc1 #3658

Closed
toddparker opened this Issue February 27, 2012 · 14 comments

2 participants

Todd Parker Scott Jehl
Todd Parker

Both the native and custom menu selects will open when focused and the spacebar is pressed. However, the custom menu version doesn't seem to ever gain in focus when opened - no options have hte ui-focus class and no keystrokes seem to affect it.
http://jquerymobile.com/test/docs/forms/forms-all.html

This should have the same keyboard shortcuts as the native menu - arrow up/down changes the selected option, spacebar or Enter selects the option and closes the select.

This is an issue in 1.0.1 so it's not a recent regression.

Scott Jehl scottjehl referenced this issue from a commit February 28, 2012
make sure the first "active" link is found and focused when a custom …
…select is opened. This addresses issue #3658, but doesn't fix it visually yet (only audibly and for keyboard)
896678e
Scott Jehl

This definitely works in the betas, so it's a regression. I think it came from moving things over to native dom methods (maybe a tabindex was misplaced somewhere?).

Scott Jehl scottjehl closed this issue from a commit February 28, 2012
improved keyboard accessibility and tabindex roving for custom select…
… menus. They were previously semi-keyboard accessible, but the visual feedback was poor, and tabindexes were set in the wrong places. This seems to do the trick, but requesting a a11y overview from @wilto if he has time :) Fixes #3658
99e27a1
Scott Jehl scottjehl closed this in 99e27a1 February 28, 2012
Scott Jehl

I think this is good. @wilto - if you get a chance, I would love a second opinion on the roving tabs and such. I didn't get a chance to do a full ARIA overview, but the keyboard and roving focus appear to be good now, and things are certainly working from a visual keyboard access perspective. thanks!

Todd Parker

So odd this isn't working for us after that commit. We'll have to try and get this in for 1.1 final.

Todd Parker toddparker reopened this February 28, 2012
Todd Parker

Sounds from the commit message that @scottjehl's fix makes this work on screenreaders but we still need the visual feedback to work for sighted users.

Scott Jehl
Scott Jehl
Todd Parker
Scott Jehl
Todd Parker
Scott Jehl
Scott Jehl

Todd are you talking about the blue select at the end of the page? (second to last one?)

That one works for me, but the hover state and active state are all themed pretty similar, so it's almost impossible to see the shift. Something else for you?

Scott Jehl scottjehl closed this issue from a commit February 29, 2012
ensure $.mobile.focusClass is actually used on buttons on focus/blur,…
… and in particular, focusin and focusout. This indirectly fixes #3658, making keyboard access clearer when themes have subtle state shifts. @toddparker, please confirm the fix and if I missed something beyond this, can you reopen?
63052f5
Scott Jehl scottjehl closed this in 63052f5 February 29, 2012
Todd Parker
Scott Jehl
Scott Jehl scottjehl reopened this February 29, 2012
Scott Jehl scottjehl closed this issue from a commit February 29, 2012
send focus to shown page. This behavior regressed after the transitio…
…ns handler focus and scroll order changed. Fixes #3658
4a05277
Scott Jehl scottjehl closed this in 4a05277 February 29, 2012
Scott Jehl

Okay just closed this out, but I still question the ui-btn-down- class usage. @toddparker and @Wilto what do you think? With focus in place now, we've got additional "glow" from our ui-focus class. I think down should be reserved for actual down state, like a tap or spacebar click...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.