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.

Replying to ocean90:
Not sure why this has been dropped out of 3.6, I thought the changes made by @lessbloat were committed. Members of the make.wordpress.org/accessibility group acknowledge that the changes made so far are not complete, but they do enable users of more modern screen readers to actually add some media - a significant step forward from the 3.5 version which is unusable by anyone who isn't using a mouse.

More work to build on @lessbloat's solution will need to be done in 3.7.

I would urge that this change be reinstated in 3.6.

Replying to grahamarmfield:

Replying to ocean90:
Not sure why this has been dropped out of 3.6, I thought the changes made by @lessbloat were committed. Members of the make.wordpress.org/accessibility group acknowledge that the changes made so far are not complete, but they do enable users of more modern screen readers to actually add some media - a significant step forward from the 3.5 version which is unusable by anyone who isn't using a mouse.

More work to build on @lessbloat's solution will need to be done in 3.7.

I would urge that this change be reinstated in 3.6.

+1 on reinstating this change in 3.6 if at all possible.

Is a reason why lessbloat's patch wasn't committed?

​23560.4.diff is a refresh of ​23560.3.diff.

Patch tested in following browsers on Windows 7:

• Chrome 31
• Firefox 25
• IE10

It is possible to tab to all the elements in the media file list. And they can be selected and deselected using the space bar. This is a good result for sighted users who rely on keyboard interaction. Focus visibility is the same as browser defaults.

Additionally, the functionality is enhanced when using screen readers - NVDA 2013.2 and Jaws 14. The screen reader announces the media file's title and whether or not the element is selected.

This solution is a pragmatic solution and will not suit users with some older versions of screen readers. But the situation is a lot better than the current keyboard inaccessible add media panel.

Further enhancements and issues about tab order in other areas will be handled in separate trac tickets.

The patch needs a refresh.

There appears to be an issue with the Featured Image view in the current patch ( 23560.4.diff ):

When selecting an image either via keyboard or mouseclick, the focus drops from the selected element and onto the Body element. This is a problem for users navigating the pane via the keyboard as it means that pressing tab/ shit+tab does not transfer focus to the next / previous item in the list as one would expect.

Steps to replicate:

1. Click on 'Add Media' in the edit post screen
2. Navigate to the 'Set Featured Image' view
3. Select an image either by tab/space or by mouseclick
4. Press tab

This is happening for me in the latest Chrome, Safari and Firefox on OSX Mavericks.

Note that in the two webkit browsers, the bug is far more apparent. This is because when the focus returns to the body, pressing tab moves focus onto the skiplinks in the main window. When replicating the bug in Firefox, pressing tab after selecting an item moves focus to the second media item in the list or the next focusable element when there is no second media item.

Some debugging info:

The focus dropoff happens when the media items collection is destroyed and rebuilt in backbone. This disposal doesn't seem to happen in the other two views which is why the issue is isolated to Set Featured Image.

Possible solutions:

1. Re-apply focus once the collection has been rebuilt
2. Prevent disposal in the first place if it can be avoided

I'm not sure which of the above two solutions is preferable or even possible, but should I figure it out I'll submit a patch

Replying to neil_pie:

There appears to be an issue with the Featured Image view in the current patch ( 23560.4.diff ):

When selecting an image either via keyboard or mouseclick, the focus drops from the selected element and onto the Body element. This is a problem for users navigating the pane via the keyboard as it means that pressing tab/ shit+tab does not transfer focus to the next / previous item in the list as one would expect.

Is this an issue with the patch itself, or just what actually happened before?

23560.5.diff​:

• starts with a refresh of .3
• Fixes featured image loss of focus bug mentioned by neil_pie
• Removes wp.media.view.FocusManager as much of it appeared to be unused/unnecessary
• Adds additional keyboard support for various actions within the media modal (moving to gallery, canceling gallery, clearing images, deleting an image)

If you spot any bugs, please ping me on IRC, or make a note on this ticket. Hoping to see this make 3.8.

I would love for this to be in 3.8 but this looks like a ton of code churn.

Is there a downside to keeping wp.media.view.FocusManager? That would allay a lot of concerns, I think. "much of it appeared to be unused" is not particularly comforting. :-) It is also more or less public API, so I wouldn't want to be accidentally breaking anything. Could you go into more detail as to how it appears to be unnecessary?

I don't think jQuery UI is used here at all, so we'll have to use 9 instead of $.ui.keyCode.TAB. To be honest, not sure why $.ui.keyCode is ever much benefit as long as there is a comment describing the character being intercepted.

I think prop needs to be used instead of attr for aria-checked.

Is there a reason why we are focusing on media-modal-close to keep the focus inside the media modal? Where does the focus go, otherwise? It seemed that this is what the focusManager should be tasked with doing. Keeping it and decorating it with this kind of stuff might be better than axing it.

What is the isIE class meant to target? All IE, including IE10? IE11?

This wasn't slated for 3.8 until yesterday; bumping.

Replying to nacin:

Is there a downside to keeping wp.media.view.FocusManager? That would allay a lot of concerns, I think.

Brought the main media.view.FocusManager structure back in .6.

Could you go into more detail as to how it appears to be unnecessary?

recordTab & updateIndex attempt to track the current tabindex. From my perspective, this is overkill, as it's not really necessary to make this all work.

I don't think jQuery UI is used here at all, so we'll have to use 9 instead of $.ui.keyCode.TAB. To be honest, not sure why $.ui.keyCode is ever much benefit as long as there is a comment describing the character being intercepted.

Cool. I removed all references to $.ui.

I think prop needs to be used instead of attr for aria-checked.

Nice catch. Fixed these.

Is there a reason why we are focusing on media-modal-close to keep the focus inside the media modal? Where does the focus go, otherwise? It seemed that this is what the focusManager should be tasked with doing. Keeping it and decorating it with this kind of stuff might be better than axing it.

Done. FocusManager.focus() now puts the focus on the first left menu item instead calling media-modal-close directly.

What is the isIE class meant to target? All IE, including IE10? IE11?

Currently downloading a Win 8 ISO to check it in IE10, IE11. It's definitely needed <=IE8.

This wasn't slated for 3.8 until yesterday; bumping.

Sorry, my fault. I had no idea that code freeze was so close. :-( 3.9 it is...

Replying to lessbloat:

This wasn't slated for 3.8 until yesterday; bumping.

Sorry, my fault. I had no idea that code freeze was so close. :-( 3.9 it is...

I will attempt to test this patch tomorrow - thanks for the input.

23560.7.diff uses LTE IE 8 conditional for IE specific CSS.

Patches 23560.6 and 23560.7 are no longer adding the aria-label="$title" and aria-checked="false" attributes into the <li> that contains the media file. So although focus is able to rest on the individual items, screen readers have nothing to voice.

In these two patches, the command to add the attribute takes the form this.$el.prop('aria-label'... whereas in 23560.5 the command is this.$el.attr('aria-label'... which does add the attributes successfully.

If you can provide a patch that combines the various focus updates in .6 and .7 along with the attribute setting from .5 then we may have something that ticks all the boxes.

Replying to grahamarmfield:

If you can provide a patch that combines the various focus updates in .6 and .7 along with the attribute setting from .5 then we may have something that ticks all the boxes.

23560.8.diff​ takes us back to using .attr() for aria-label values.

Testing 23560.8 with JAWS14 on IE10. All appears to behave as expected, including seemingly a fix for #25100. I can action the Add Media button and focus is in the modal popup. I can then tab around within the media files and JAWS announces the media file name. I can select/deselect using the space key. The functionality to add a gallery and to select the featured image for a post all appears to work.

So that's good. Testing with NVDA to follow after reboot.

Currently unable to test with NVDA at the moment. Be good if someone else could give that a go.

This ticket was mentioned in IRC in #wordpress-ui by grahamarmfield. ​View the logs.

The patch needs a refresh before further testing can be done.

Refresh of 23560.8.diff

Refresh of 23560.8

Please check 23560.9.2.diff, I accidentally uploaded 23560.9.diff which is an incomplete patch.

Whoops, it seems Trac has some accessibility issues as well. Second time that I as a screenreader user closed a ticket without wanting to do so...

Replying to bramd:

Whoops, it seems Trac has some accessibility issues as well. Second time that I as a screenreader user closed a ticket without wanting to do so...

I've done the same during accessibility testing - reported it on Meta Trac :) ​https://meta.trac.wordpress.org/ticket/273#comment:5. Feel free to add any other issues you come across there - it's about general accessibility problems with Trac.

This ticket was mentioned in IRC in #wordpress-ui by grahamarmfield. ​View the logs.

By way of follow-up to the promised review from last week's meeting ​https://irclogs.wordpress.org/chanlog.php?channel=wordpress-ui&day=2014-02-19&sort=asc#m159871and Graham Armfield's recommendation to try using NVDA 2013.3, I again tested on a 3.8.1 test site, on a Windows machine, going out of my way to test on Firefox, which has had known issues.

Using NVDA 2013.3 in browse mode, I found no accessibility blockers, even in the rich text area using Firefox. Using Version 2013.3 I was able to escape out of keyboard traps using (Shift+).

Bottom line, I found absolutely no blockers because of WordPress, at least when using NVDA 2013.3. Some accessibility blockers (keyboard traps) still exist with 2013.1, but even those disappear with testing in my 3.9 test site, I assume because of the upgraded TinyMCE.

The only problems I REALLY had is that NVDA 2013.3 kept crashing my station; for that reason, I did not test on Rian's site, I tested my own. It was all I could do to make it through a complete session. 2013.3 is in beta (as I understand it) so I expect even those "bugs" to be worked out soon. But again, I found no issues because of WordPress.

To all the developers, thank you so much for what you've done here.

Sorry, another relevant link to above:
​http://community.nvda-project.org/ticket/3145

This ticket was mentioned in IRC in #wordpress-ui by grahamarmfield. ​View the logs.

This ticket was mentioned in IRC in #wordpress-ui by davidakennedy. ​View the logs.

Is it possible to get this refreshed? I would like to revisit this with a fresh test, on trunk. Thank you in advance for any help (or advice) you can provide.

This ticket was mentioned in IRC in #wordpress-ui by ericandrewlewis. ​View the logs.

This ticket was mentioned in IRC in #wordpress-dev by ericandrewlewis. ​View the logs.

Before ircbot takes over this ticket, let's fixed it now.

Stunning work by the developers. A huge, huge thanks for the incredible work they've done with this.

Latest test was performed using a version of trunk 18512 using the instructions found here:
​http://make.wordpress.org/core/handbook/installing-wordpress-locally/installing-via-svn/
The files were uploaded to this location, where testing took place using NVDA 2013.3 on a Windows machine using Chrome.
​http://red-hound.com/tic23560/

There was nothing that was not available to me via keyboard. This is a major, huge improvement over previous versions.

One "headache" was the Add Media feature. It's a modal, and at least in my testing, when trying to add images while looking at the modal screen for Add Media, NVDA would read all of the links in the "background" for the post before reading aloud anything in the Add Media screen. Is it possible to somehow keep focus within the modal when one is working with it?
(Not that we are unappreciative of the improvements made to date...that the Add Media screen works is a major accomplishment! Thank you!)

While everything is accessible by keyboard, not everything is announced. For example, before even logging in, just reading the splash page of the test site, one is taken through various lists on the sidebar, but there is no announcement as to what those lists are other than "complimentary landmark heading" (instead of, for example, "Recent Comments", "Archives" or "Meta"). Another example: While in the "Edit Image" modal of the "Add Media" pane, I was able to navigate by keyboard to the "Image Crop" link, and it was announced as a "link" in NVDA, but there was no indication as to what that link was.

As I see it, the major issues for improvement to date are: keeping focus within modals while working inside of them, and adding labels to links so that screen readers can announce what the links actually are. Most of the links are labeled, (and therefore announced by NVDA), so I personally would not consider these issues showstoppers.

Thanks again for such terrific work by all the developers.

This ticket was mentioned in IRC in #wordpress-dev by helen. ​View the logs.

This ticket was mentioned in IRC in #wordpress-ui by helen. ​View the logs.

In 28607:

At long last, improved keyboard accessibility for the media modal.

props lessbloat, grahamarmfield, sharonaustin, bramd.
see #23560.

Ticket is still open, as I believe there are a few more things that could be made even better. We can do screen reader improvements here.

I noticed one thing - the .attachment.selected and .attachment.details items (that is, selected items, the former only actually showing up when multiple items are selected) use box shadow styling and so don't have focus styles. I tried giving them the same focus style as normal but it looked wrong, and negatively affected the visual styling when clicking.

In 28617:

Fix a jshint error introduced in [28607]. see #23560.

Other observations, please let me know if they are correct:

• When selecting a tab along the left side, focus should be transferred into the main panel. Edit: #25101.
• When selecting an image, focus should be transferred to the right details panel.
• Reverse tabbing out of the right details panel seems like it should take me back to the item in the list that was being edited.
• When in the media list, arrow keys should move between items, not scroll the page.

I agree with all those observations; they seem like sensible changes to me.

I've noticed a few odd behaviors in Chrome - when NVDA is enabled, I can't access the modal with the keyboard; when NVDA is disabled, it's not a problem. When selecting an image, spacebar jumps to bottom of screen after selecting image.

Chrome is definitely not going to give the best experience with NVDA, so while that's odd, it may not be readily fixable; but the keyboard behavior on spacebar should be fixable.

Keyboard focus is *really* subtle; that could definitely use some improvement.

This ticket was mentioned in IRC in #wordpress-ui by helen. ​View the logs.

This ticket was mentioned in IRC in #wordpress-dev by helen. ​View the logs.

This ticket was mentioned in IRC in #wordpress-ui by _Redd. ​View the logs.

This ticket was mentioned in IRC in #wordpress-dev by helen. ​View the logs.

#28704 was opened for arrow key navigation, in case we need to punt that piece to the future (don't want to, for the record). Trying to get developer interest here, since tasks are laid out.

This ticket was mentioned in IRC in #wordpress-ui by accessiblejoe. ​View the logs.