jQuery UI Accessibility Review: Wrapup
Last week I announced my plan for performing a jQuery UI accessibility review. Since then I have posted two progress updates (Update 1 and Update 2).
This is the third, and final, update to the jQuery UI accessibility review. We likely haven't identified all bugs. We have, however, provided a broad high level accessibility review of all jQuery UI core widgets.
Bugs posted since last update:
- #7859 (Menu: Default accessibility)
- #7860 (Menubar: accessibility)
- #3079 (Tabs: keyboard accessibility) Comment #18
- #7861 (Dialog: default accessibility)
- #7862 (Dialog: modal accessibility)
- #7863 (Datepicker: Inline accessibility)
Once again I would like to offer thanks to all who were involved in this review. I believe that we have provided valuable feedback to jQuery UI developers, which will enable them to provide an even more accessible library to the many products, and sites, which make use of it.
Comments
Anonymous
Mon, 11/14/2011 - 12:03
Permalink
An Executive Summary?
It would be nice to have an executive summary of the findings in one document, a text-based summary of which jQuery core widgets have accessibility issues, for passing along to project leaders who don't necessarily have coding skills, but are concerned about compliance issues when jQuery is used. Can anyone write one?
Everett
Mon, 11/14/2011 - 12:16
Permalink
Response to Executive summary
@anonymous
I have no plan to write an executive summary (unless there is sponsorship of this task). I can point you to the list of open jQuery UI accessibility bugs.
http://bugs.jqueryui.com/query?status=!closed&keywords=~a11y
Whether the individuals evaluating jQuery UI have coding skills or not, they can quickly see which widgets have open bugs.
An executive summary would need to be detailed, as it cannot state definitively that a widget is, or is not, accessible. It would need to state that certain implementations of certain widgets have been found to have accessibility bugs. This doesn't mean that evaluators need to avoid the widget completely, but they would need to consider avoiding the particular implementation.
Add new comment