Keyboard Accessibility of Add Media Panel

[grahamarmfield]

Trying to keep this trac specific I'm talking here about keyboard-only interaction with the new Add Media panel once you have opened it by actioning the Add Media link whilst editing a page or a post.

Accessibility Issues:

• The most serious problem with accessibility in the Add Media functionality is that it is not possible to select any of the pre-uploaded media without using a mouse. This will effectively preclude any keyboard only or screen reader users from using this functionality.
• When the Add Media panel first opens it is unclear where keyboard focus sits. This could be disconcerting for some users.
• Reverse tabbing from the panel transfers focus back into the main page whilst leaving the panel open. Recommend that focus is kept cycling within the panel until the user either explicitly closes the Add Media panel or inserts some images.
• It is possible to tab through the text links on the panel(s), but the Upload Files link does not show focus as obviously as other links as there is no outline.
• When tabbing forwards from the Upload Files link there is a tab stop that is not at all visible. Believe this to be Media Library but it's not clear.
• The Insert into Page link can receive focus even when inactive.

Separate trac tickets will be raised to cover the full screen reader and speech recognition software experience.

The main problem with keyboard operability here is that there are no meaningful items in the media list that can receive focus.

The overall functionality of the media selection is like a series of checkboxes. For keyboard and screen reader and VR users the interface either needs to be coded like that, or potentially some ARIA techniques employed (however it is not certain they will work with VR).

Once the functionality is provided to select the media via keyboard, it is then not clear how quickly a keyboard user could navigate to the panel that contains the individual attributes for an image. Tabbing through the entire collection of media is not a viable option here - as especially on large sites with many files, the infinite scrolling will make this an awful experience.

Perhaps an accessibility mode is required here - as per existing widgets functionality, and that proposed for Custom Menu builder (see #14045).

This issue is being raised on make.wordpress.org/accessibility for some collective thought.

The separate trac tickets raised for screen reader and VR experience are: #23561 and #23562.

23560.diff​ addresses some of these items, including:

• Keeping the focus in the media modal once it's open
• Moves focus to #wpbody-content once the modal is closed (needs to be an element that is present on every page where the media modal is used)
• Made it so the media items could be tabbed to. Added role=checkbox, and the file name as the title (so that visually impaired users will know what they are focused on)
• When focused on an item, enter selects and deselects it. Shift + enter allows multiple selection.
• I added tabindex=-1 to the non-visible tab stop, and to the plus/minus link which shows up after you've selected an item
• Added an empty alt to the image
• Added an outline to the "upload files" and "media library" links

Please let me know how this works out.

A couple of observations after looking at this:

• Adding labels around the items will be a fair amount of work, since the focus is actually on LI tags, and I'm fairly certain we can't just wrap a label around an LI.
• If someone has a lot of media items, they will need to tab through all of them to get to the right column. Is there some keyboard combo we could use as a shortcut to get you there?

Replying to lessbloat:

23560.diff​ addresses some of these items, including:

Appreciate the work you're doing on this. I don't have the facility to test this myself as I don't have a suitable environment, but I have some comments I'd like to make:

• Keeping the focus in the media modal once it's open

Excellent.

• Moves focus to #wpbody-content once the modal is closed (needs to be an element that is present on every page where the media modal is used)

OK for now. Perhaps we can discuss further longer term.

• Made it so the media items could be tabbed to. Added role=checkbox, and the file name as the title (so that visually impaired users will know what they are focused on)

... and ...

• Adding labels around the items will be a fair amount of work, since the focus is actually on LI tags,

Since the purpose of the attributes that I'm proposing is to allow items in the list to get focus and to behave like a checkbox grouping it doesn't really matter which element the attributes sit on. So if the <li> item is the actual one that responds to click then you could put the attributes on that.

All the attributes that I specified will need to be employed to get this to work in screen readers and for keyboard users. See the example code at end of this comment.

Please also note that using the title attribute to label items is no guarantee that screen reader users will get that information. Some screen readers voice title attributes but not all do, and those that do only voice them in certain situations.

• When focused on an item, enter selects and deselects it. Shift + enter allows multiple selection.

You will also need to toggle selection by listening for the space bar presses. This ARIA technique works for screen readers by 'fooling' the screen reader that this is a checkbox. In standard forms the checkbox state is toggled by space bar. Users will expect enter key to submit the form they are in.

Whether the enter key or space bar has been pressed, the aria-checked attribute must be updated to reflect the state - true or false.

• I added tabindex=-1 to the non-visible tab stop, and to the plus/minus link which shows up after you've selected an item

This may be superfluous, but I'd have to test for real.

• Added an empty alt to the image

Excellent

• Added an outline to the "upload files" and "media library" links

Excellent

Please let me know how this works out.

A couple of observations after looking at this:

• Adding labels around the items will be a fair amount of work, since the focus is actually on LI tags, and I'm fairly certain we can't just wrap a label around an LI.

Understand the problem here. I have a solution for this which is to add the aria-label attribute to the <li> too and make it's value equal to the media file's title. This will remove the need for the label. See code example below.

• If someone has a lot of media items, they will need to tab through all of them to get to the right column. Is there some keyboard combo we could use as a shortcut to get you there?

It's a valid concern for keyboard-only users and one we should address in the future. I'd be cautious about adding extra shortcuts. Screen reader users can use the Attachment Details heading to jump to the input fields (it's a facility within screen readers to use headings as navigational items).

Example code to try
Please note that this has changed from the original example I gave on the make.wordpress.org/accessibility blog (​http://make.wordpress.org/accessibility/2013/03/28/add-media-panel-and-wordpress-3-6-a-simple-solution/) to avoid using a <label> element, and to attach new attributes to <li> element instead of image.

Unselected:

<li class="attachment save-ready" tabindex="0" role="checkbox" aria-checked="false" aria-label="Media file title">

Selected:

<li class="attachment save-ready details selected" tabindex="0" role="checkbox" aria-checked="true" aria-label="Media file title">

I have tested this markup in isolation with NVDA and it behaves as I'd expect.

Replying to grahamarmfield:

Example code to try
Please note that this has changed from the original example I gave on the make.wordpress.org/accessibility blog (​http://make.wordpress.org/accessibility/2013/03/28/add-media-panel-and-wordpress-3-6-a-simple-solution/) to avoid using a <label> element, and to attach new attributes to <li> element instead of image.

Unselected:

<li class="attachment save-ready" tabindex="0" role="checkbox" aria-checked="false" aria-label="Media file title">

Selected:

<li class="attachment save-ready details selected" tabindex="0" role="checkbox" aria-checked="true" aria-label="Media file title">

I have tested this markup in isolation with NVDA and it behaves as I'd expect.

23560.1.diff​ should do it I think.

I'm a bit green with jquery but the diff makes sense. Is there somewhere you could put it so that I can test it? Thanks.

23560.2.2.diff adds the ability to select an item with either the space bar, or the enter key. It also adds better focus styles to the items (especially in IE).

Replying to lessbloat:

23560.2.2.diff adds the ability to select an item with either the space bar, or the enter key. It also adds better focus styles to the items (especially in IE).

Both key changes - thanks for that.

I'm still having problems selecting with NVDA active but that's possibly down to how NVDA reacts to ARIA - I'll investigate further. If I use the NVDA 'pass-through' key then I can get it to select.

One other suggestion for improved user experience for screen readers: Currently you are presenting the name of the image in the aria-label attribute. In the cases of the images in the test site they are matt4.jpg etc. But they could of course be DSC0011.jpg etc.

How feasible would it be to pull out the individual titles for each of the images instead of the actual filename? That way, if I've added a meaningful title and/or alternate text when I upload the image then that will be externalised when I'm selecting the file to be included in the page.

Cheers for what you've done here.

Replying to grahamarmfield:

How feasible would it be to pull out the individual titles for each of the images instead of the actual filename? That way, if I've added a meaningful title and/or alternate text when I upload the image then that will be externalised when I'm selecting the file to be included in the page.

What percentage of the time will there be a title though? I'd imagine a lot of the time, there is no title, and the user just adds the image without adding one.

The options I see are, we could:

A) Keep using file name (would work all of the time, but some file names make little sense, as you pointed out)
B) Use title all of the time (I'd say the vast majority of files won't have a title, and so the aria description will be left blank)
C) Use the file name, but when the title is there, use that instead (this could be a bit confusing)
D) Always show the file name, and if there is a title, add it in there as well (this could end up being rather long)

Let me know which one you prefer. Thanks.

Replying to lessbloat:

What percentage of the time will there be a title though? I'd imagine a lot of the time, there is no title, and the user just adds the image without adding one.

The options I see are, we could:

A) Keep using file name (would work all of the time, but some file names make little sense, as you pointed out)
B) Use title all of the time (I'd say the vast majority of files won't have a title, and so the aria description will be left blank)
C) Use the file name, but when the title is there, use that instead (this could be a bit confusing)
D) Always show the file name, and if there is a title, add it in there as well (this could end up being rather long)

Let me know which one you prefer. Thanks.

Could we not do whatever the default action is for displaying the title in the Attachment Details panel? - Which I think corresponds roughly to C). The image or file name minus the .jpg or .pdf etc is the default title, unless it has been updated at some point by the user.

For me this makes the most sense.

Replying to grahamarmfield:

Could we not do whatever the default action is for displaying the title in the Attachment Details panel? - Which I think corresponds roughly to C). The image or file name minus the .jpg or .pdf etc is the default title, unless it has been updated at some point by the user.

For me this makes the most sense.

OK, I understand now. 23560.3.diff​ should do it.

Fantastic, thanks.

Replying to lessbloat:
Did you apply the latest diff to that test site you had? I'm testing it now and the aria-label value seems to still be always set to the filename and suffix - even when I've added a human-meaningful title, caption, and alt attribute.

Replying to grahamarmfield:

Did you apply the latest diff to that test site you had?

I did not. I'm hoping we can just get this committed so that everyone can test it.

Replying to lessbloat:

I did not. I'm hoping we can just get this committed so that everyone can test it.

OK. Thanks for letting me know.

Hello guys,

This is my first test with the WordPress source code, and I've tested the 23560.3.diff, and I didn't get some problems solved:

1. The button "Add Media" isn't being focused. I've tested it in the wp-admin/post-new.php?post_type=page, wp-admin/post-new.php and QuickPress Widget;

2. I can't select an uploaded media file with the keyboard. The itens aren't being focused;

I've been testing in a MacBook Pro with Mac OSX 10.7 with PHP 5.3.15 and mysql Ver 14.14 Distrib 5.1.58 and the browsers Firefox 19.0.2 and Google Chrome 28.0.1469.0

I'm testing this issue in a right way? Sorry if I'm doing something wrong.
Thank you.