WordPress.org

Make WordPress Core

Opened 14 months ago

Last modified 7 weeks ago

#23560 reopened defect (bug)

Keyboard Accessibility of Add Media Panel

Reported by: grahamarmfield Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.5.1
Component: Media Keywords: has-patch needs-testing needs-refresh
Focuses: accessibility Cc:

Description

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.

Attachments (13)

23560.diff (3.8 KB) - added by lessbloat 13 months ago.
23560.1.diff (4.4 KB) - added by lessbloat 13 months ago.
23560.2.diff (4.5 KB) - added by lessbloat 13 months ago.
23560.2.2.diff (5.1 KB) - added by lessbloat 13 months ago.
23560.3diff (5.1 KB) - added by lessbloat 13 months ago.
23560.3.diff (5.1 KB) - added by lessbloat 13 months ago.
23560.4.diff (5.1 KB) - added by atimmer 6 months ago.
23560.5.diff (8.2 KB) - added by lessbloat 5 months ago.
23560.6.diff (8.5 KB) - added by lessbloat 5 months ago.
23560.7.diff (8.5 KB) - added by lessbloat 5 months ago.
23560.8.diff (8.5 KB) - added by lessbloat 4 months ago.
23560.9.diff (8.8 KB) - added by bramd 2 months ago.
Refresh of 23560.8.diff
23560.9.2.diff (9.0 KB) - added by bramd 2 months ago.
Refresh of 23560.8

Download all attachments as: .zip

Change History (61)

comment:1 toscho14 months ago

  • Cc info@… added

comment:2 grahamarmfield14 months ago

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.

comment:3 grahamarmfield14 months ago

  • Cc graham.armfield@… added

lessbloat13 months ago

comment:4 follow-up: lessbloat13 months ago

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?

comment:5 in reply to: ↑ 4 ; follow-up: grahamarmfield13 months ago

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.

lessbloat13 months ago

comment:6 in reply to: ↑ 5 lessbloat13 months ago

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.

comment:7 grahamarmfield13 months ago

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.

lessbloat13 months ago

lessbloat13 months ago

comment:8 follow-up: lessbloat13 months ago

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).

comment:9 in reply to: ↑ 8 ; follow-up: grahamarmfield13 months ago

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.

comment:10 in reply to: ↑ 9 ; follow-up: lessbloat13 months ago

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.

comment:11 in reply to: ↑ 10 ; follow-up: grahamarmfield13 months ago

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.

lessbloat13 months ago

lessbloat13 months ago

comment:12 in reply to: ↑ 11 lessbloat13 months ago

  • Keywords needs-testing has-patch added

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.

comment:13 grahamarmfield13 months ago

Fantastic, thanks.

comment:14 follow-up: lessbloat13 months ago

  • Milestone changed from Awaiting Review to 3.6

comment:15 in reply to: ↑ 14 ; follow-up: grahamarmfield13 months ago

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.

comment:16 in reply to: ↑ 15 ; follow-up: lessbloat13 months ago

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.

comment:17 in reply to: ↑ 16 grahamarmfield13 months ago

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.

comment:18 ticaiolima13 months ago

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;
  1. 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.

comment:19 follow-up: ocean9010 months ago

  • Milestone changed from 3.6 to Future Release

comment:20 in reply to: ↑ 19 ; follow-up: grahamarmfield10 months ago

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.

comment:21 in reply to: ↑ 20 sharonaustin10 months ago

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.

comment:22 esmi10 months ago

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

atimmer6 months ago

comment:24 grahamarmfield5 months ago

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.

comment:25 grahamarmfield5 months ago

  • Keywords needs-refresh added; needs-testing removed

comment:26 follow-up: neil_pie5 months ago

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

Last edited 5 months ago by neil_pie (previous) (diff)

comment:27 in reply to: ↑ 26 grahamarmfield5 months ago

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?

lessbloat5 months ago

comment:28 lessbloat5 months ago

  • Keywords needs-testing added; needs-refresh removed
  • Milestone changed from Future Release to 3.8

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.

comment:29 nacin5 months ago

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?

comment:30 follow-up: nacin5 months ago

  • Milestone changed from 3.8 to Future Release

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

lessbloat5 months ago

comment:31 in reply to: ↑ 30 ; follow-up: lessbloat5 months ago

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...

comment:32 in reply to: ↑ 31 grahamarmfield5 months ago

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.

lessbloat5 months ago

comment:33 lessbloat5 months ago

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

comment:34 follow-up: grahamarmfield4 months ago

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.

lessbloat4 months ago

comment:35 in reply to: ↑ 34 lessbloat4 months ago

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.

Last edited 4 months ago by lessbloat (previous) (diff)

comment:36 grahamarmfield4 months ago

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.

comment:37 grahamarmfield4 months ago

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

comment:38 sharonaustin4 months ago

  • Cc sharonaustin added

comment:39 nacin3 months ago

  • Component changed from Accessibility to Media
  • Focuses accessibility added

comment:40 ircbot2 months ago

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

comment:41 GrahamArmfield2 months ago

  • Keywords needs-refresh added

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

bramd2 months ago

Refresh of 23560.8.diff

bramd2 months ago

Refresh of 23560.8

comment:42 bramd2 months ago

  • Status changed from new to closed

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

comment:43 follow-up: bramd2 months ago

  • Status changed from closed to reopened

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...

comment:44 in reply to: ↑ 43 helen2 months ago

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.

comment:45 ircbot2 months ago

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

comment:46 sharonaustin8 weeks ago

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.

Last edited 8 weeks ago by sharonaustin (previous) (diff)

comment:47 sharonaustin8 weeks ago

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

Last edited 8 weeks ago by sharonaustin (previous) (diff)

comment:48 ircbot7 weeks ago

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

Note: See TracTickets for help on using tickets.