Buttons not keyboard accessibile

[SteveALee]

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.

[SteveALee]

PS for an example hit tab a few times on http://fullmeasure.co.uk/OpenDirective/IPO/Final

[scottjehl]

Hi Steve
Thanks for the feedback.

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!

Scott

[scottjehl]

Hi Steve,
Please review now that the above change has landed and let me know whether we should close this out.
You can test latest on http://jquerymobile.com/test/
Thanks again!
Scott

[SteveALee]

Thanks shot

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!

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.

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?

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.

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!

When is the target date? I'd like to do this but as a new startup we have to watch our time.

[SteveALee]

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.

<div data-role="footer" id='footer'>
  <a href='actions.php' data-role="button" data-theme="c" id="save">Save actions</a>
</div> <!-- /footer -->

Enhanced markup is

<div id="footer" class="ui-footer ui-bar-a" data-role="footer" role="contentinfo">
  <a id="save" class="ui-btn-left ui-btn ui-btn-up-c ui-btn-corner-all ui-shadow" data-theme="c" data-role="button" href="actions.php">
    <span class="ui-btn-inner ui-btn-corner-all">
      <span class="ui-btn-text">Save actions</span>
    </span>
  </a>
</div>

Steve

[toddparker]

Hi Steve -

I think if the latest version on /test/ works, then maybe there is something with your hand-patched version? If what's in master is working pretty well, we can close this...

[SteveALee]

Todd, OK, done.
However note I patched the CSS and the problem is functional - ie can't action the buttons with the keyboard. If I get to the bottom of it i'll add a note here. One thought is my buttons have text and your's is just an icon. I checked all by event handlers. I'll do a test spike when I get time.

[toddparker]

Thanks again for your help @SteveALee. Please do submit more issues or pull requests once you have time to dig into more accessibility testing. This is a priority for us!