Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Buttons not keyboard accessibile #2639
RC1 Firefox 7 on Windows Vista
Buttons are not keyboard accessible. While they appear to be in the tab order they do not show the focus rectangle around the text and enter key does not work.
Also as they are spans (without ARIA) and not real links they are unlikely to be accessible by screen readers.
I concede this is not a problem on mobile phones but is on desktop (A grade support) and more general mobile devices like ASUS transformer which has a keyboard. We (OpenDirective) are working ofnwidgets that work on mobile and desktop and JQM offers good features including responsive layout.
This rather goes against the comments on focus/keyboard management on your accesisbility page (http://jquerymobile.com/demos/1.0rc1/docs/about/accessibility.html). Also I don't see any use of WAI-ARIA or HTML5 features like landmark elements. I feel there is a little way to go to become full accessible by 1.0 as you aim to do.
I'm looking into this now. It looks like we have outline set to "none" in one place that it shouldn't be, so I'll fix that up. I'm assuming it was in there to keep the outlines from creeping into the mouse experience, which is a constant complaint we get as soon as it crops up.
You mentioned the buttons being "not real links." Can you expand on that? Maybe the buttons you were looking at are an edge case that I'm forgetting about, but all of the buttons on the site should be either anchor elements or some sort of form button or input button. One exception is we're wrapping the input @type=button elements in a div to achieve styling that was otherwise difficult to achieve, but the input itself should still be actionable. Let me know!
As for landmarks, I suppose we could use some improvement in the markup our docs site, but that won't affect the widgets that we provide to end developers. The one area of the framework code that does seem to match a landmarks use case is the "page" divisions, which are optional elements that can be used to create a simple header, content, footer breakdown. When we enhance those components, we apply the ARIA roles "banner", "main", and "contentinfo" to them, respectively, does that seem appropriate? These elements aren't in every section of our docs, but you can find them on a lot of pages like this one: http://jquerymobile.com/demos/1.0rc1/docs/toolbars/docs-bars.html
As for other ARIA usage in the widgets, we tend to not need too much of it in our form controls, as we use the native controls in most cases, but there are a few places we're using ARIA for custom controls. The slider control for example, uses ARIA attributes, as does the custom select menu (but not the default selectmenu, as that's a normal select). There are some other places I'm probably forgetting...
Anyway, I'll get on that focus outline fixup. let me know if you have any feedback on the points above, and if you have any other ideas for improving our accessibility before 1.0 ships - it's a top priority for us!
pushed a commit
Oct 7, 2011
Firstly to clarify I'm was describing an issue in my own wep app using jQueryMobile (http://fullmeasure.co.uk/OpenDirective/IPO/Final/) not your site.. In fact it seems I owe you an apology as I see the top element in the DOM after your lazy enhancement is in-fact an a element I must have got data blind and only saw the 2 spans. The 2 buttons I have may be an edge case as they are in header/footer. I cannot get either to action with enter key, which is the real bug report.
Yes that is what I meant. Sorry not to be clear. It seemed an obvious uses case. I have to apologise again as I now see the role= markup. All I can think is I did something to break the enhancement or firebug reporting at some point.
BTW I also tried using the HTML5 structural elements (header, content, aside) and it mostly worked with some CSS damage. I see the problem in supporting both the more specific HTML5 and general div is the CSS and jQuery selectors would become messy, and so probably inefficient.
When is the target date? I'd like to do this but as a new startup we have to watch our time.
Hi Scott, and thanks
http://jquerymobile.com/test/ looks good.
I hand patched my jquery.mobile-1.0rc1.css and it also fixes the focus rect problem I had. However I still cannot action the buttons with the keyboard. Unenhanced links are fine but they are dynamically added, unlike the 2 buttons. I'm copying your dynamic page example (with edge case fixes for page load and F5 (feel free to use). I see the home button on http://jquerymobile.com/test/docs/about/intro.html works so I wonder what the problem is with my app? Do you have any ideas? The source markup is.
Enhanced markup is
Todd, OK, done.