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.
Comment | File | Size | Author |
---|---|---|---|
#12 | media-library-keyboard-2372903-12.patch | 4.43 KB | cboyden |
Comments
Comment #1
mgiffordWould make more sense to me for them to be a link rather than a button.
Comment #2
dsnopekI 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 analt="..."
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 injs/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.Comment #3
cboyden CreditAttribution: cboyden commentedI 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.
Comment #4
dsnopekAn 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...
Comment #5
dsnopekNevermind, 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:
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...
Comment #6
cboyden CreditAttribution: cboyden commentedSo 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.
Comment #7
dsnopekAlright, here is a patch that uses
aria-role="checkbox"
when multiple values are possible, oraria-role="radio"
when only a single value is allowed. In Javascript, it updates thearia-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/oraria-labelledby="..."
so that screenreaders will get a sane description of the image when tabbed to it?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!
Comment #8
cboyden CreditAttribution: cboyden commentedThanks 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.
Comment #9
dsnopekHere'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.
Comment #10
mgiffordWere 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?
Comment #12
cboyden CreditAttribution: cboyden commentedI'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.
Comment #14
cboyden CreditAttribution: cboyden commentedComment #15
dsnopek@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.
Comment #16
joseph.olstad.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)?
Comment #19
joseph.olstadComment #20
joseph.olstadComment #21
cboyden CreditAttribution: cboyden commentedAfter 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.
Comment #22
cboyden CreditAttribution: cboyden commentedNever mind, the tabindexes are a theme issue - setting back to fixed.