The Library tab of the Media browser can't be operated with the keyboard only. The image thumbnails don't receive keyboard focus. If the entity is a Document instead of an Image file type, the thumbnail renders as a preview that includes a link, which does receive focus. But activating that link with the keyboard when it's focused doesn't select the item.

As a side effect, this means that you can't test this function automatically. Webdrivers generally can't click something that isn't focusable.

Possible solution: Implement the thumbnails as links or buttons; prevent the default event so you don't end up submitting the form or following a link.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mgifford’s picture

Would make more sense to me for them to be a link rather than a button.

dsnopek’s picture

Status: Active » Needs work
FileSize
641 bytes

I experimented a little with a different approach than what @cboyden proposes: adding tabIndex="0" to each media item in the library. It's very visually pleasing, in that the whole media item gets surrounded with a blue outline (at least under Chrome 39). Attached is a patch in case anyone else wants to mess with that (it doesn't let you actually select the item still, just focus on it with the keyboard).

But in thinking about it more, I think having each media item include a single link would be ideal. For images, the link should be around the <img> tag so that it can include an alt="..." attribute. For other types, it'll have to just be the filename.

However, the media items in the library are basically the previews, so to get a link around the <img> tag we'd have to put it on preview, which won't make necessarily sense on other pages that use the preview. :-/ Beyond that, we'd just have to update the Javascript in js/plugins/media.views.js to recognize pressing Enter on a link as selecting the media item and maybe some styling to distinguish focused from selected, but I'm not sure that'll be necessary.

cboyden’s picture

I actually think they'd make sense as buttons, since you're taking an action (selecting) rather than going to a destination.

This is complicated by the fact that file previews already include links. Those links are going to be focusable unless you take them out of the tab order. This could probably be done by some jQuery magic. Then the link or button tag could be wrapped around the preview when it's rendered by media-views-view-media-browser.tpl.php.

Or, would it work to add a separate preview renderer for this situation? Then the link/button could be generated there, and the usual link provided by previews of files could be left off.

dsnopek’s picture

I actually think they'd make sense as buttons, since you're taking an action (selecting) rather than going to a destination.

An idea just occurred to me: What if we make this into a group of radio buttons? Because that's really what this control is: we're selecting a single item from a list of available options, while showing all options at once.

I think that would help with the tab order issues too. We could use jQuery to add tabIndex="-1" to all the links, so they can't be focused (for the previews that include links).

I'm going to put together a patch that does this and see how it works...

dsnopek’s picture

An idea just occurred to me: What if we make this into a group of radio buttons? Because that's really what this control is: we're selecting a single item from a list of available options, while showing all options at once.

Nevermind, this turned out not to be a very good idea at. :-/ While it makes semantic sense to be radio buttons (or checkboxes - I didn't realize at first that it's possible to select multiple items if the media browser is configured that way), there isn't any way for the label (what the preview would be) to inherit the 'focused' or 'checked' state of the control, and if we hide the control itself, it's no longer focusable/tabbable.

So, scratch that!

Responding to @cboyden about using buttons from #3:

I actually think they'd make sense as buttons, since you're taking an action (selecting) rather than going to a destination.

With buttons, will a screenreader treat the image alt text as the value of the button? If so, that's probably the better option.

Or we could just use div's and ARIA and tabIndex? I'm not sure we're really going to be able to make this control semantic anyway...

cboyden’s picture

So semantically, this is more like a multiple select. You could go with buttons for each item that toggled them on and off, but I think checkboxes make the most sense if we can make them work.

One way to do this would be applying an aria-role of checkbox to the divs that are currently clickable but not focusable. Javascript would set the selected/unselected state when you activate the item (click or Spacebar), and CSS would change to show them as highlighted. Not sure if these would also need tabindex, or if the aria-role by itself is enough to make them focusable with the keyboard. Easy enough to test.

We might also want to take the file links and make them not-focusable. If they're going to be not-focusable, they should also be not-clickable. It's confusing when you try to select an item and end up hitting the filename link instead.

dsnopek’s picture

Status: Needs work » Needs review
FileSize
3.63 KB

Alright, here is a patch that uses aria-role="checkbox" when multiple values are possible, or aria-role="radio" when only a single value is allowed. In Javascript, it updates the aria-checked="true/false" to match the selected state of the media item.

The tabIndex="0" is still necessary to make the items tabbable in Chrome, so that is included in the patch as well.

@cboyden: Do we also need to use aria-describedby="..." and/or aria-labelledby="..." so that screenreaders will get a sane description of the image when tabbed to it?

We might also want to take the file links and make them not-focusable. If they're going to be not-focusable, they should also be not-clickable. It's confusing when you try to select an item and end up hitting the filename link instead.

I agree that it's confusing, but the same would happen in a normal set of checkboxes or radio buttons where one of the labels contained a link. So, my current patch doesn't include this...

But we could definitely use Javascript to find all the links and make them not tabbable/clickable, if that makes the most sense from an accessibility perspective!

cboyden’s picture

Status: Needs review » Needs work

Thanks for the patch @dsnopek. The items are focusable, but I can't select them using the keyboard. The standard mode of interaction for a native checkbox is the spacebar, so in this case pressing spacebar when focused on an item should toggle its checkbox.

Also in Firefox/Mac I can't tab to the Library tab and activate it with the keyboard. I have to click the Library tab, then click into the search form before I can tab to the items. In Chrome, I can tab to and activate the Library tab.

dsnopek’s picture

FileSize
4.48 KB

Here's a new patch that allows selection of individual items by pressing the space bar!

However, using Firefox 34 under Linux I'm not able to reproduce the issue with the tabs. :-/ I can tab over to "Library" and press ENTER to select the "Library" tab.

mgifford’s picture

Status: Needs work » Needs review

Were now at FF35.

@cboyden I don't have a Mac at the moment. Can we find someone else to test if it is a problem elsewhere?

Status: Needs review » Needs work

The last submitted patch, 9: media-library-keyboard-2372903-9.patch, failed testing.

cboyden’s picture

Status: Needs work » Needs review
FileSize
4.43 KB

I've updated the patch to apply to the latest 7.x-2.x-dev. I also fixed the role attribute and allowed the Enter key as well as spacebar to select a thumbnail.

The keyboard interactions are OK, within the Library tab. However, if the ARIA role is radio button (when multi select is turned off), the expected interaction is to use the arrow keys to move between options. We'll have to test this with a screenreader to see if it's usable.

Status: Needs review » Needs work

The last submitted patch, 12: media-library-keyboard-2372903-12.patch, failed testing. View results

cboyden’s picture

Status: Needs work » Needs review
dsnopek’s picture

@cboyden's changes here look fine to me! I can't really RTBC this, though, since I wrote some of the earlier versions of this patch.

joseph.olstad’s picture

.bind() should work on jQuery 1.4 and newer
this should be compatible with D7.56 core and updated versions.
afaik.
has anyone tested this patch with jQuery 1.4 (the default jQuery for D7.56 core)?

  • joseph.olstad committed 8633574 on 7.x-2.x authored by cboyden
    Issue #2372903 by dsnopek, cboyden: Library tab not keyboard-accessible...

  • joseph.olstad committed 8633574 on 7.x-3.x authored by cboyden
    Issue #2372903 by dsnopek, cboyden: Library tab not keyboard-accessible...
joseph.olstad’s picture

joseph.olstad’s picture

Status: Needs review » Fixed
cboyden’s picture

Status: Fixed » Needs work

After this update, everything inside the Library tab is working OK. But I still cannot tab to the Library tab when first opening the modal. The Library tab is not tabbable. If you click the tab with the mouse, the Library tab then becomes tabbable, but the default Upload tab is not. When these tabs are created, both the LI tag and the A tag have their tabindex set to -1. This makes them focusable programmatically, but they are not reachable via the keyboard. This may be a separate issue.

cboyden’s picture

Status: Needs work » Fixed

Never mind, the tabindexes are a theme issue - setting back to fixed.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.