jQuery UI Accessibility Analysis 

Posted by Bryan Garaventa on July 3, 2013 in ARIA, Assistive Technology, jQuery, RIA, SSB BART Group

I recently had a discussion on the Web Accessibility LinkedIn group regarding the importance of keyboard accessibility, and how there needs to be an accessibility related training resource for engineering students, one that is always accessible out of the box, in order for informed diagnosis of accessibility issues to take place effectively in the future.

During the conversation, jQuery UI was suggested as an accessible resource for this purpose.

Since a comprehensive accessibility analysis of jQuery UI has not recently been done, I decided to do so in order to see what the current level of accessibility is for the library, and to determine how useful it would be as an accessible development resource.

To summarize, the public jQuery UI library widgets as of July 1, 2013, are mostly inaccessible for both screen reader and keyboard only users.

In time, this will likely improve as these issues are worked on by project developers. In the meantime, the following test results explain the various issues that were found during the accessibility analysis.

This list only covers the highest priority accessibility issues as they relate to screen reader and keyboard only users, and does not cover low vision or voice navigation software accessibility.

jQuery UI Widgets

(NP = Not Problematic)

Draggable: http://jqueryui.com/draggable/

NP

Droppable: http://jqueryui.com/droppable/

Drag and drop functionality is not accessible to keyboard only users, nor to screen reader users, the importance of which is demonstrated on the Shopping Cart demo.

Resizable: http://jqueryui.com/resizable/

NP

Selectable: http://jqueryui.com/selectable/

This simulated select is not accessible to keyboard only users, nor does it have any ARIA support to ensure accessibility for screen reader users, both of which must match to ensure accessibility for both. This is also true for the Grid view.

Sortable: http://jqueryui.com/sortable/

None of the sortable implementations are accessible from the keyboard, nor are they accessible to screen reader users with supporting ARIA markup, the focus movement and ARIA markup of which must match to ensure accessibility for both.

This is true for all of the following implementations:

  • Default functionality
  • Connect lists
  • Connect lists with Tabs
  • Delay start
  • Display as grid
  • Drop placeholder
  • Handle empty lists
  • Include / exclude items
  • Portlets

Accordion: http://jqueryui.com/accordion/

All of the implementations use ARIA role=tablist and role=tab to convey expandable and collapsible accordion nodes. The problem with doing this, is that the insertion point for new accordion content is included within the container with role=tablist. Meaning that, if accordion content includes additional ARIA widgets, such as a real Tab control that uses ARIA role=tablist and role=tab to convey a nested ARIA Tab control, it is impossible for screen reader users to determine the difference between an accordion node and one of the nested tab controls, because both are announced as “Tab”, nor can screen reader users determine the proper order and level of nested Tab controls for the same reason, since no level information is conveyed.

Additionally, the Sortable Accordion implementation is not accessible for screen reader and keyboard only users.

Autocomplete: http://jqueryui.com/autocomplete/

  • Default functionality: NP
  • Accent folding: NP
  • Categories: NP
  • Combobox: Pressing Up and Down does not convey search results as instructed.
  • Custom data and display: NP
  • Multiple values: The edit field should be wrapped in a container with role=application so that Forms Mode is not automatically exited when Enter is pressed to select a value from the autosuggest list in JAWS.
  • Multiple, remote: The edit field should be wrapped in a container with role=application so that Forms Mode is not automatically exited when Enter is pressed to select a value from the autosuggest list in JAWS.
  • Remote JSONP datasource: The full name of the city including its geographic location is not announced to screen reader users when Up and Down is used to browse suggested items.
  • Remote datasource: NP
  • Remote with caching: NP
  • Scrollable results: NP
  • XML data parsed once: NP

Button: http://jqueryui.com/button/

  • Default functionality: The elements “button” and “input” with type=submit are already buttons, and as such, do not need role=button, nor aria-disabled=false, when setting the ‘disabled’ attribute will accomplish this natively for both screen reader and keyboard only users.
  • Checkboxes: The use of ARIA role=button, aria-disabled, and aria-pressed on the explicit Label elements bound to each checkbox is an improper use of ARIA. If these are meant to be separate elements that portray ARIA Checkbox controls, then these should be keyboard accessible using tabindex=”0″, and should include role=checkbox, and should dynamically toggle the aria-checked attribute. An ARIA Toggle is a similar concept, which does use role=button and aria-pressed in this manner, but not making these controls keyboard accessible via tabindex=”0″ is a critical accessibility issue.
  • Icons: The element “button” is already a button, and as such, does not need role=button, nor aria-disabled=false, when setting the ‘disabled’ attribute will accomplish this natively for both screen reader and keyboard only users.
  • Radios: The use of ARIA role=button, aria-disabled, and aria-pressed on the explicit Label elements bound to each radio Input element is an improper use of ARIA. If these are meant to be separate elements that portray ARIA Radio controls, then these should be broken out as a separate group of elements surrounded by role=radiogroup, with each radio element including role=radio, as well as supporting attributes such as tabindex to manage standard radio button functionality, including aria-owns if the radios are not first level children of the container with role=radiogroup, and aria-checked to indicate which radio is currently selected.
  • Split button: The element “button” is already a button, and as such, does not need role=button, nor aria-disabled=false, when setting the ‘disabled’ attribute will accomplish this natively for both screen reader and keyboard only users.
  • Toolbar: The use of ARIA role=button, aria-disabled, and aria-pressed on the explicit Label elements bound to the checkbox is an improper use of ARIA. If this is meant to be a separate element that portrays an ARIA Checkbox control, then this should be keyboard accessible using tabindex=”0″, and should include role=checkbox, and should dynamically toggle the aria-checked attribute. An ARIA Toggle is a similar concept, which does use role=button and aria-pressed in this manner, but not making these controls keyboard accessible via tabindex=”0″ is a critical accessibility issue.

Additionally, the use of ARIA role=button, aria-disabled, and aria-pressed on the explicit Label elements bound to each radio Input element is an improper use of ARIA. If these are meant to be separate elements that portray ARIA Radio controls, then these should be broken out as a separate group of elements surrounded by role=radiogroup, with each radio element including role=radio, as well as supporting attributes such as tabindex to manage standard radio button functionality, including aria-owns if the radios are not first level children of the container with role=radiogroup, and aria-checked to indicate which radio is currently selected.

If standard checkboxes and radios are already present, then there is no need to also include an ARIA Checkbox and Radiogroup control at the same time.

Date Picker: http://jqueryui.com/datepicker/

  • Default functionality: The Date Picker is not keyboard accessible, since tabbing away from the edit field causes the calendar to disappear. Additionally there is no separate triggering element to convey to screen reader users that there is a Date Picker attached to the field.
  • Animations: Default functionality: The Date Picker is not keyboard accessible, since tabbing away from the edit field causes the calendar to disappear. Additionally there is no separate triggering element to convey to screen reader users that there is a Date Picker attached to the field, nor is the calendar rendered inline with the triggering element.
  • Dates in other months: The Date Picker is not keyboard accessible, since tabbing away from the edit field causes the calendar to disappear. Additionally there is no separate triggering element to convey to screen reader users that there is a Date Picker attached to the field.
  • Display button bar: The Date Picker is not keyboard accessible, since tabbing away from the edit field causes the calendar to disappear. Additionally there is no separate triggering element to convey to screen reader users that there is a Date Picker attached to the field.
  • Display inline: Since the Next and Prev controls consist of A tags that do not include an ‘href’ attribute, neither of these controls are keyboard accessible, nor do they convey to screen reader users that these are active elements.
  • Display month & year menus: The Date Picker is not keyboard accessible, since tabbing away from the edit field causes the calendar to disappear. Additionally there is no separate triggering element to convey to screen reader users that there is a Date Picker attached to the field.
  • Display multiple months: The Date Picker is not keyboard accessible, since tabbing away from the edit field causes the calendar to disappear. Additionally there is no separate triggering element to convey to screen reader users that there is a Date Picker attached to the field.
  • Format date: The Date Picker is not keyboard accessible, since tabbing away from the edit field causes the calendar to disappear. Additionally there is no separate triggering element to convey to screen reader users that there is a Date Picker attached to the field, nor is the calendar rendered inline with the triggering element.
  • Icon trigger: Since the triggering element consists of an IMG tag, it is not keyboard accessible, nor does it include textual equivalents and a relevant ARIA role for screen reader users to convey that this is an active element.
  • Localize calendar: The Date Picker is not keyboard accessible, since tabbing away from the edit field causes the calendar to disappear. Additionally there is no separate triggering element to convey to screen reader users that there is a Date Picker attached to the field, nor is the calendar rendered inline with the triggering element.
  • Populate alternate field: The Date Picker is not keyboard accessible, since tabbing away from the edit field causes the calendar to disappear. Additionally there is no separate triggering element to convey to screen reader users that there is a Date Picker attached to the field, nor is the calendar rendered inline with the triggering element. Additionally the form fields are not explicitly labelled, making it difficult for screen reader users to determine their purpose.
  • Restrict date range: The Date Picker is not keyboard accessible, since tabbing away from the edit field causes the calendar to disappear. Additionally there is no separate triggering element to convey to screen reader users that there is a Date Picker attached to the field.
  • Select a Date Range: The Date Picker is not keyboard accessible, since tabbing away from the edit field causes the calendar to disappear. Additionally there is no separate triggering element to convey to screen reader users that there is a Date Picker attached to the field, nor is the calendar rendered inline with the triggering element.
  • Show week of the year: The Date Picker is not keyboard accessible, since tabbing away from the edit field causes the calendar to disappear. Additionally there is no separate triggering element to convey to screen reader users that there is a Date Picker attached to the field.

Dialog: http://jqueryui.com/dialog/

All of the jQuery UI dialogs are surrounded by a container including the ARIA attribute role=dialog, which presents critical accessibility issues for screen reader users such as those using NVDA in Firefox, since all textual content included within these bounds cannot be navigated within the Virtual Buffer using the arrow keys after focus is set within the dialog. Examples of this, including a full description of this issue, is described in the ARIA Warnings section at http://whatsock.com/tsg.

This issue is the same for all container elements that include the attributes role=alertdialog and role=application.

Additionally, none of the background content is properly hidden from screen reader users within the Modal implementations, causing all background content to remain visible and actionable to screen reader users regardless.

Menus: http://jqueryui.com/menu/

It appears that none of the menus can be closed from the keyboard, but looking at this more closely, this may simply be due to the demo not providing a triggering element to open a dropdown or flyout example of this functionality.

The ARIA markup and keyboard interactivity is correct however.

Progressbar: http://jqueryui.com/progressbar/

NP

Slider: http://jqueryui.com/slider/

None of the sliders include ARIA markup, making them inaccessible for screen reader users.

Spinner: http://jqueryui.com/spinner/

NP

Tabs: http://jqueryui.com/tabs/

  • Default functionality: NP
  • Collapse content: Since pressing Enter on a tab in JAWS causes it to enter and exit Forms Mode, using Enter alone for this purpose is not reliable, and should also include the Spacebar to toggle the expand/collapse state. The aria-expanded attribute should also be added to reflect the current state of the expanded or collapsed tab.
  • Content via Ajax: NP
  • Open on mouseover: NP
  • Simple manipulation: The inclusion of a clickable Span within the Tab presents an event propagation accessibility issue, since this element cannot be activated by screen reader users. This issue is more fully described in the Event Model Differences section at http://whatsock.com/tsg. Additionally, the use of role=presentation to hide this element from screen reader users is an improper use of ARIA, which is also described in the ARIA Warnings section on the same page. Only aria-hidden can be used to remove an element from the accessibility tree.
  • Sortable: The re-sort functionality is not accessible to screen reader and keyboard only users.
  • Tabs at bottom: The concept of this implementation, where the dynamic content appears before the triggering elements in the DOM element flow, causes a reading order accessibility issue for screen reader users, who will not know that the content that is being rendered is being inserted before the elements that currently have focus. As a general practice, dynamic content should not be inserted before the triggering element that causes it to appear.
  • Vertical Tabs functionality: NP

Side note: All of the A tags within the elements with role=tab (that do not contain href attributes) include the ARIA attribute role=presentation. Since these A tags have no href attributes, it is the same as a Span tag, and the inclusion of role=presentation literally does nothing. The use of role=presentation should only be used when you want to suppress the role of an element for screen reader users. The same is true for the use of tabindex=”-1″ within these A tags, which is not necessary, since the elements that receive keyboard focus are the surrounding LI tags.

Tooltips: http://jqueryui.com/tooltip/

The tooltip text for all demo implementations, appears at the bottom of the page in the DOM. This presents an accessibility issue for all screen reader users wishing to more closely examine what has been announced in addition to the text for the active element. The use of aria-describedby cannot be depended on alone for conveying this information, since it is not always announced as expected. The textual content for tooltips should appear directly after the triggering element in the DOM, so that it is then possible for screen reader users to then press the Down arrow to read the content of the newly displayed tooltip.

All of these concepts, including functional accessible interaction designs, are further explained in the AccDC TSG Coding Arena at https://github.com/accdc/tsg where more comprehensive explanations are available for relevant control types, including browser and screen reader compatibility testing data as it relates to dynamic content rendering and ARIA, and related pitfalls to be aware of during development.

Comments Icon Comments

No comments