E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 1 (In chronological order)

From: Bryan Garaventa
Date: Sun, Jun 30 2013 5:56PM
Subject: jQuery UI Accessibility Analysis
No previous message | No next message

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. This is the article at:
http://www.linkedin.com/groupItem?view=&;gidA800&type=member&item%3259328&qid;0b34eb-9602-46fa-83bf-f1bff95f8063&trk=group_most_recent_rich-0-b-ttl&goback=%2Egmr_41800

Since jQuery UI came up during the conversation, I decided to perform an accessibility analysis of the live widgets that are currently included within the library. Hopefully this will be helpful for developers working on the project in the future.

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úlse, 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úlse, 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úlse, 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 press the Down arrow to read the content of the newly displayed tooltip text, the boundaries of which should also be conveyed.

All of these concepts, including functional accessible interaction designs, are included 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.

Hopefully this is helpful to others.

Sincerely,
Bryan Garaventa