jQuery UI Accessibility Review: What's the Plan?

Two updates to the article.

1. the paths on view.jqueryui.com (where the code and demos are stored) have changed. the links in the article have been updated to reflect this.

2. Scott also mentioned that you can join irc://irc.freenode.net/#jqueryui-dev (IRC channel)for questions / assistance.

Firefox 7.0.1 / JAWS 13

Nice that these demos report 'has popup' as this provides some indication that there is a menu or drop down of some sort that should be available.

Default
1. Type 'ja' in the field.
2. Hear 'Menu to move to items press up or down arrow'.
3. Using arrows can navigate the list, content of field seems correct when I tab away and back, but nothing is read while navigating the list. ** Once in a while something s read, likely because this widget is replacing the edit field value while navigating th elist.

Custom data and display
1. Not sure what 'custom' data / display is. Only receiving words like 'jQuery' as results read by JAWS. Note: must tab away and back to field to confirm result, see (3) above.

Categories
1. When I type 'j' the only result seems to be for 'andreas johnson'. This does not seem very 'category' to me (didn't read anything about how this ought to work). When I type 'a' I receive more than one option, but still no sense of what a 'category' is.

Multiple
Nothing other than to say that it works as designed, for getting more than one value in the field, even though I am guessing about what items I am picking from the list.

Checkboxes

Firefox 7.0.1 / JAWS 13

1. For each checkbox JAWS recognizes a checkbox, followed by a button.
2. The button label is being read twice 'b b'.
3. When toggling on by checkbox or button the button disappears and toggling off does not bring the button back.

Icons
1. The first and last buttons, which should have no text, have text that can be read by JAWS. This is likely for the best, otherwise screen-reader users would have no idea what the button does.

Toolbar
1. the 'toolbar' role should be added to the span id='toolbar'. See http://www.w3.org/TR/wai-aria/roles#toolbar

Split

1. On load the 'Rerun' and 'Select' buttons were available as individual buttons.
2. Selecting 'Rerun' brought up a dialog.
3. Selecting 'Select' brought up a menu. Using arrow keys it was not possible to navigate the menu. Using tab and then arrow keys, it was possible to find 'open', 'save', 'delete'.
4. Selecting one of the menu options seemed to lock the window and it was necessary to switch windows and return to access the page again.

Firefox 7.0.1 JAWS 13

Default
1. It is not possible to press the tab key to get to each tab, but only to get to the selected tab. This might be correct, but is a new UI paradigm on the web for screen-reader users.
2. Only in 'forms' mode will JAWS allow the arrow keys to switch between selected tabs. This is part of the ARIA markup used.
3. When the enter key or space bar are pressed to expose a tab JAWS enters forms mode (unlike with a link <a>, where JAWS stays in buffer / reading mode).

Firefox 7.0.1 / JAWS 13

Default
1. Reading past the elements in reading mode does not expose a tooltip.
2. Tabbing to an element reads ' Use JAWS Key + ALT + R to read descriptive text + '.
3. Reaching a form field by a quick key 'f' reads ' + '

Forms with tooltips
1. the '?' can not be reached by tabbing.
2. Reading past, tabbing to, or accessing the form fields with quick keys 'f', does not read a tooltip (by design it seems).
3. Pressing the toggle button changes things.
a. The ? can still not be reached by tabbing.
b. In reading mode JAWS now reads '? Use JAWS key + alt + R to read descriptive text.'

Custom content
1. No tooltips could be found using JAWS (under development?)

Default

1. The list of tabs should be marked up w/ role='tablist'.
2. Each tab shold be marked up with role='tab'
3. Each tab panel should be marked up with role='tabpanel'

See http://www.w3.org/TR/wai-aria/roles#tablist

Open on mouseover
1. The click event appears to be replaced w/ moseover, so it is impossible to switch tabs from a keyboard.

Simple manipulation
1. It is possible to add a tab.
2. It is not possible to remove a tab, 'remove tab' does not receive focus and is not a link / button.

Tabs below content
1. This is a bit confusing to screen-reader users, as the page is accessed linearly and it is an uncommon construct for controls to appear after related content.
2. JAWS does read, for the selected tab 'Press JAWS key + alt + m to move to controlled content' and upon using the keystroke focus is placed at beginning of tabpanel.

Firefox 7.0.1 JAWS 13

Default
1. JAWS reports as a spinner, but doesn't indicate that up / down arrows change value. Perhaps, since this is a relatively new control on the web a default, or recommend, tooltip would be useful.
2. Up button has no name, down button has name of 'black down pointing triangle'.
3. Up / down buttons do not appear to receive focus.

Firefox 7.0.1 JAWS 13

Default
1. Slider is represented as '#' link. It is necessary to tab to the '#', disable virtual PC cursor (JAWS key + z), then use arrows to move slider, then turn virtual PC cursor back on (JAWS key + z) then to check the value.

** Since some demos (color picker) don't display the value in any other way it is impossible to know if the correct value has been selected.

jQuery UI Accessibility Review: Update 1

@anonymous:

Collapse content
Basic tab functionality OK but not possible to collapse with the keyboard

* Was not able to reproduce. Will discuss later in week on #jQueryUI-dev

Sortable
Basic tab functionality OK but not possible to sort with the keyboard

* Bug filed (see tomorrow's update).

Simple manipulation
Possible to add tab but focus moves back to the menu after clicking OK ('draggable' link), so that's lots of extra tabbing to get back to the tabs.

* Updated bug (see Update 1)

Not possible to remove tab with keyboard.

* Bug filed (see Update 1)

The close button is not focusable (span).

* Cannot reproduce. Will discuss later in the week on #jQueryUI-dev

I found no problems with this widget

JAWS 13 / NVDA 2011.1.1 / Firefox 7.0.1 did not announce %.
NVDA 2011.1.1 / Firefox 7.0.1 did not announce 'Progressbar'.
VoiceOver (Snow Leopard) / Safari 5 did announce % and 'Progress indicator'.

Firefox 7.0.1 / Safari 5.0.5

Default

Role and label for dialog not announced. I am not sure if this is because of a problem w/ the widget, or if AT is only supposd to announce the label on role="alertdialog".

Popup on hover (tooltip)

Not accessible from keyboard

@anonymous

But I wasn't expecting to need to use the arrow keys to move between the elements of the menu bar.

* This is an unfamilar pattern for web UIs, where 'tab' is epected to move between elements. But, it is completely expected for native UIs. Menubar is attempting to bring a native UI component to web apps.

* I had no problem navigating within the popup with a keyboard only interface here:
http://view.jqueryui.com/branches/master/demos/dialog/modal-confirmation...

But when I went back I couldn't get keyboard access to the form below it.

* Cannot reproduce. Will discuss on #jQueryUI-dev

Please read jQuery UI accessibility review: update 2 for remaining tasks.

@anonymous

JAWS 12 with Internet Explorer 9.01

* I used Firefox 8 + JAWS 13

1. Was able to Tab to the menu & navigate through the options using the arrow keys.

* I was also able to do this, but once in a while I was not able to navigate when tabbing to the menu. Sometimes pressing enter on the menu worked to activate, other times it did not.

2. Instructions text below the menu was not read by JAWS. I had to use the JAWS cursor to read the same.

* If you mean the text at the end of the page it is between the 'show demo in new window' and 'view source' links.

3. No means to close the menu and get out of the same.

* Pressing escape will not exit the menu, as you would expect from a select control or textarea. tabbing away from the menu exits the menu (but moves focus to next focusable control). Pressing enter on a item when the menu is active does not exit the menu.

@anonymous

JAWS 12 with Internet Explorer 9.0.1

* I'm using Firefox 8 + JAWS 13

1. Menu works fine with JAWS announced it as a menu & provides users with info about using arrow keys to navigate.
2. I guess the text is not read since as in case of desktop apps, when focus is on menu, text is not read out. Same was the case for Menu-default functionality.

* After pressing enter to activate the menu JAWS read 'Menu Amsterdam'. I was able to navigate with the arrow keys.

3. No means to close the menu once in it, did guess work & it worked with Escape.

* Worked with escape, or with pressing enter to select an item.

JAWS 12 with Internet Explorer 9.0.1

* I'm using Firefox 8 + JAWS 13

1. Menu works with the keyboard Arrow keys but fails to announce the name for some options.

* No failures.

2. Menu items with sub-menu options was announced by JAWS as 'sub menu' & same was the case of sub menu options with further sub-menus. I am not able to
write the menu item name as my screen reader does not read for me.

* No failure. 'Delphi sub menu' was announced as first sub menu, pressing right arrow or enter opend the sub menu.

* Once in a while I was not able to navigate when tabbing to the menu. Sometimes pressing enter on the menu worked to activate,other times it did not.* Pressing escape will not exit the menu, as you would expect from a select control or textarea. tabbing away from the menu exits the menu (but moves focus
to next focusable control). Pressing enter on a item when the menu is active does not exit the menu.

JAWS 12 and Internet Explorer 9.0.1
* I'm using Firefox 8 + JAWS 13
1. Menu & sub-menus were accessible with the keyboard
2. Menuitems with sub-menus were identified by JAWS as 'sub menu' and name/label of the item was not spoken. Same was the case for sub menu items of the menu items. However point to be noted is that text of the sub menu items was read out correctly.

* Again no problems reading out menu names with sub menus.

Pressing enter, as one might expect to interact with an interactive control, activated the menu item link.

Firefox 8.0 + JAWS 13

1. It is possible to tab to the first menu and to navigate across with arrow keys and down each menu with arrow keys.

2. If tabbing through the page from 'theme switcher widget' the order is: 'File', 'Open', 'Default functionality'. I am not sure if 'Open' is from the first or second menubar.

3. When tabbing in reverse from 'Default functionality' the order is: 'Full screen', 'Open', 'File'.

This doesn't seem consistent, I am not sure if there are guidelines or a best practice around this.

4. I can begin interacting with a menubar / menu with the enter key, but cannot stop interacting (return to virtual PC cursor) with the escape key. Using the escape key to stop interacting with controls (e.g. Textarea) is a very common pattern.

In update 2 there is a list of 3 tasks to be confirmed using keyboard only:

• Tabs (Collapsible): Not possible to collapse with the keyboard.

This does work in Firefox 7.0.1, but when opening a tab focus is set to top of DOM - #3079 (Tabs: keyboard accessibility) Comment #18

• Tabs (Simple Manipulation): 'Close' button on Add popup does not receive keyboard focus.
• Dialog (Modal confirmation): After dialog is dismissed underlying form is not accessible using the keyboard.

Problems in Chrome, but not other browsers, no bug posted.

Internet Explorer 9.0.1 & JAWS 12
* I'm using Firefox 8.0 and JAWS 13

1. On opening the example, JAWS read the dialog text "This is a default dialog..." which was good.

* JAWS reports 'Basic dialog dialog. To navigate use tab. Application mode on.'. Using arrow keys I could not navigate, pressing tab once focus went to close button and application mode turned off.

2. JAWS did not read dialog title before reading the text contained therein. However the same info was available if the user presses UP Arrow.

* Didn't experience this.

3. The dialog text states that the dialog box can be moved, sized & closed using the 'Close' button However users can only close the dialog box.

* Resize / move are Interactions (not tested and being re-written for 1.9).
4. The 'Close' button is available with a keyboard as well and by default the focus on the 'Close' button which was good.

* Focus did not go to close button when testing.

Internet Explorer 9.01 & JAWS 12
* I'm using Firefox 8.0 + JAWS 13

1. On opening the dialog, focus moves correctly to the dialog box. On pressing "Ins + Down Arrow", Jaws reads the dialog title, close button and text there

* Yes.

after. However, if the user presses Arrow keys to read the info, it reads at times from the middle or at the end of the dialog text.

* Application mode was enabled automatically, tabbing (to close button) disabled application mode.

2. Keyboard focus is correctly on the 'Close' button, which was a good part.

* Keyboard focus was not on close button, I needed to tab once to reach close button.

This demo had a modal dialog (could not tab to 'open' button or reach in Virtual PC Cursor mode, even though it was part of the DOM.

Internet Explorer 9.0.1 & JAWS 12
* I'm using Firefox 8.0 and JAWS 13

1. JAWS correctly reads the dialog text and button on opening the same.

* Yes. And, opens with application mode on.

On accessing the forms list "Ins + F5" on the page, it displays some other controls as well: check box, radio button & combo box. This is should not happen
as I feel only the dialog should be visible.

* Correct. After tabbing once to close button I can use up / down arrows to access all other form controls in the DOM, cannot tab to other interactive controls. This is different from animated dialog, where 'open' button is not available.

Internet Explorer 9.01 & JAWS 12:
* I'm using Firefox 8.0 + JAWS 13

1. JAWS correctly users about the 'OK' button which has the focus and name of the dialog box "Download Complete". However, on desktop apps, users have keystrokes
for reading the dialog box which is not available on the web "Ins +B" (reads the window). I feel User Agents - Assistive Technologies: screen readers should
come up with reading the dialog on the web with some keystroke to make the experience equal for users.

* Correct. Content of dialog (other than controls and title, not accessible as application mode is enabled.

2. Keyboard focus was fine.

* Accessing address bar (alt + d), tabbing to page, then disabling and renabling Virtual PC cursor (JAWS key + z) and then a buffer refresh (JAWS key + Escape) allowed access to entire DOM contents. This appears true for all modals. This also can cause problems with other keyboard operations (like going back a page (alt+left arrow or backspace) or even closing browswer (alt+f4)).

* From outside of the dialog pressing tab does not return to first focusable element in dialog.

@anonymous

Did you test Datepicker from 1.9pre (master branch) or from the datepicker branch? See notes in article.

Bugs already filed against slider.

Only testing jQuery UI, as it is incorporated into Drupal and other web CMSs. Would consider looking at jQuery Mobile in the future.

@anonymous

now tested: http://view.jqueryui.com/branches/datepicker/datepicker-rewrite/index.html TOTALLY BETTER!

XP, FF7, NVDA 2011.3
* I'm using Firefox 8.0 + JAWS 13

only thing not working is the page up page down to change months but alt+page up page down does change year
also big issue is that you can't tell what year and month you are in and it does not announce the new month / year as you change, should this be a table
caption?

* I didn't get these problems after switching to Application mode (JAWS key + z) and tabbing to datepicker.

* Inline

1. Application mode is not enabled when arriving at date picker, so can only interact with control using links (prev, next, numeric dates) by pressing enter / space. Cannot use up / down and left / right arrows to navigate the grid, and cannot use pgup / pgdown / alt + pgup / alt + pgdown.

If application mode is enabled manually (JAWS key + z) and I tab to the datepicker I can use all key combinations.

2. 'Prev' and 'Next' links do not have clear purpose.

3. No indication what has changed when clicking 'next'. JAWS does not announce 'December 2011'.

Popup datepicker seems to work well.

Thanks to all who participated in the review.

Please see the final update for the jQuery UI accessibility review.