Usertest: The search functions in the Admin

Question for the test team

We like you to test the search function options in the WordPress Admin.
We know there are accessibility issues here, we would like your expert opinion about this.

Test on WordPress 4.2-alpha

  • Try the search function in:
  • Posts > All posts
  • Posts > Categories
  • Posts > Tags
  • Media
  • Pages > All pages
  • Comments
  • Appearance > Themes
  • Plugins > Installed Plugins
  • Plugins > Add New (try different options, like featured, favorites, etc.)
  • Users > All users
  • And if you still have time: Pages > Add new > Add Media > search an image or file in the Media Library, try different options, like kind of media item and date


  • Try with search words you know give results
  • Try an empty search
  • Try with nonsence words

Can you tell us if:

  • it’s easy to do a search or do you get stuck
  • you get what you expected
  • you can read the results well
  • you get good feedback when there are no results
  • you miss something to make it work for you
  • you have suggestions for improvement (keep it short please)

Shaun Everiss

I just did the test with NVDA, search worked as expected. I didn’t see any issues.


Tools: Safari + VoiceOver

  • Posts > All posts: The function worked perfectly, however I think that the missing part is telling the user how many results he obtained with his search. Also if is possible, make the focus stays on the main content after the page is refreshed would be nice.
  • Posts > Categories: Same comment than Post > All posts.
  • Posts > Tags: Same comment than Post > All posts.
  • Pages > All pages: Same comment than Post > All posts.
  • Comments: Same comment than Post > All posts.
  • Appearance > Themes: See missing search button comment.
  • Plugins > Installed Plugins: Same comment than Post > All posts
  • Plugins > Add New: Same comment than Post > All posts.
  • Users > All users: Same comment than Post > All posts.


Media: The function worked perfectly.
Missing search button: I noticed that in this page, the search function is a little bit different than search functions in the other pages. In the media page the button “search for XX” at the right side of the search input text is missing. Since in most of the pages we found a label + input text + button search, the user is used to this pattern. I propose to modify the search function to be consistent with the rest of the functions.
Media: Select class=”attachment-filters” missing label
The select option for type of media (images, audio, etc) does not have a label so the select context is not clear since the user only listen to “All (4)”.

Pages > Add new > Add Media: Here we have a similar case to the search function on Themes page. This is an interactive search. The problem here is that there is nothing that tells the screen readers what is happening while the user is performing the search.


Search Placeholder in Themes: The themes search function is the only one where the input text has a placeholder. Listening to it is a little confusing because the same word is repeated two or tree times:
“Search installed themes, clickable, Search installed themes, Search installed themes search text field”.
Since this function is the only with a placeholder, what do you think about removing the placeholder from the code to keep consistency with the other search functions?

Search function inside the H2: The search function for the themes page is grouped inside the H2. With VoiceOver, the user won’t be able to write in the input text unless she goes inside (control+option+shift+down arrow) the group to interact with it.

Blocked search input text; There is a bug when writing some text in the input text and clicking enter to execute the search. The focus is blocked and the text can not be erased. One solution is to move to another element on the page and come back to the input text to regain the functionality. The search function in Themes is different because is an interactive search, the user write something and at the same time results appears. The problem here is that there is nothing that tells the screen readers what is happening while the user is performing the search. Clicking on enter to execute a search is a normal behaviour because all the other pages offer the same pattern. I think if the user get trapped in this bug won’t be able to find a way out.

Missing search button: In this page, the button “search for XX” at the right side of the search input text is missing. Since in most of the pages we found a label + input text + button search, the user is used to this pattern. I propose to modify the search function to be consistent with the rest of the functions.

Also missing in this page is the text “Search results for “XX”” that appears inside the H2. Most of the pages added it when the page is refreshed after doing a search.

Amy Li

Posts > All posts

  • Focus should set to search input box when first enter all posts page
  • Screen reader read “Search Posts” button as “Disabled”
  • Search Posts color contrast radio is not higher than 4.5:1


  • Focus should set to search input box when first enter
  • When Enter space into Name input it should read out warning in Screen Reader
  • After input empty into Name, nothing shows and focus is gone and removed


  • After enter input text it should read results when there’s results found
  • Focus should set to first search result after click Enter into search box

Plugins > Installed Plugins

Focus should set to first search result after click Enter into search box or set back to search input box

Plugins > Add New

When enter “Jet” text which there’s search result, the the typeselector select field has no text/label

<select name="type" id="typeselector">
 <option value="term" selected="selected">Keyword</option>
 <option value="author">Author</option>
 <option value="tag">Tag</option>

Users > All users

  • Focus should set to search input box when first enter all posts page
  • Focus should set to first search result after click Enter into search box

Resize window:

Search box should be on top when screen size is smaller than <320 like mobile version.

Tina Tedesco

I use JAWS 15.

When I search for something, and whether it found it or not, my results did not appear until the end. I had to use the arrow key to go down to see where the actual results were.

It did say out loud searching but did not bring me right to the search results. Can you put in something where the screen reader will read out how many results after searching?

Besides that I thought the search worked well. Definitely doable with a screen reader.

John Sexton

Test on Win7 64bit, IE11 & Supernova14

Search in categories:

Focus is placed in the new category name field on page load

Search in tags:

Focus is placed in the new tag name field on page load

Search in media library

While in grid view, this search works differently it appears to filter items as you type but from a screen reader point of view clicking the search button gives no feedback that any search has been performed. Perhaps on pressing the search button focus can be moved to the first search result or if a total of items found message is added, like in posts, categories and tags focus can be moved to that.
While in list view, it works more like the posts, categories and tags search.

Search on all pages

Search on “(no title)” and “mwa” both return no items
It doesn’t seem possible to search for all pages with no titles

Search on themes

Empty search returns all six themes
Search on “four” returns two items: twenty fourteen and twenty ten
Search on “ten” returns four items: twenty fifteen, twenty eleven, twenty fourteen and twenty ten
There is no search button and pressing enter in the search field gives no indication to the screen reader of any changes and the search results are a little odd.

On the whole quite reasonable. However, themes gave the most odd results. Not having any screen reader friendly feedback a search has been done is a little off putting as is placing the focus on a form field on page load.
The searches appear to be limited to the first column of the results table and it may be nice to be able to search or filter on file type in the media library. IE jpeg, png, gif, mp3, mp4, doc, docx, pdf etc.
Another nice to have may being able to search or filter by user who created/uploaded the item.

Geof Collis,

Tools: IE 11, JAWS 14.5

search post, pages, comments, plugins and media/library

no problem with search function initially but I dont like trying to find the results, there needs to be a heading for the results, as it is right now I’ve got to tab through all of the regular stuff before I find a table with results if any, very annoying and time consuming, also, I’d like the focus to be taken to the results after a search if possible

On another note a heading before all posts, pages, categories etc would be nice.

I noticed that when I do a second search that the previous text is still in the edit box, this should be removed after the initial search.

Tags and categories

This is better, they have a heading and the search term used but the focus gets taken past the heading, I have to move backwards, this might be more of a problem for a keyboard user.

Still the issue of previous search term in edit box.


Something wrong with the edit box, as I start typing it is reading off the url and search term and when I hit enter it doesn’t go out of forms mode, I have to do it manually and again a heading with the results would be better than tabbing through the regular stuff.

Plugins add new, all criteria

This worked great, a heading for each plugin made it easier to sift through them but still the issue of text in edit box after search.

Add new

Posts and pages work fine as long as the disable the visual editor checkbox is selected in Profile.

Add media

Uploading from my computer has become a whole lot better but do have issues with adding alt text etc, trying to add one from the media library is non existent, perhaps a test for another day.


  • Give screen reader feedback for search results and what’s happening with the interactive search in themes.php and upload.php
  • Give better screen reader feed back about the amount of search results
  • Set the focus on search the results after search submit (and not for example at New category)
  • Add a (hidden) submit button  and remove the placeholder for search in upload.php (at least for list mode),  plugin-install.php and themes.php (see ticket #26600)
  • In themes the search input text gets blocked after clicking enter to execute the search.
  • Bug: Plugins > Add New: typeselector select field has no text/label (see ticket #26601 )
  • It is not possible to search for posts/pages with no title
  • Search installed themes gives to much results?
  • Remove search function for the themes.php outside the H2 (see ticket #26601 )
  • Move the search field on top in small windows

Discussions in Slack about the results:

Slack log

Now there are 5 different ways for a search:

  1. Search input no submit button, no live search (need to press Enter) in Media Library list mode
  2. Search input no submit button, live search fires “as you type” in Media Library grid mode, Themes (add new, API), Network Themes (add new, API)
  3. Search input no submit button, live search fires “as you type” (more a “filter current collection” than a search), Themes (installed themes), Customizer add widget, Plugins (installed plugins)
  4. Search input with hidden submit button, press Enter or tab and submit the hidden button (after the search, the “typeselector” select appears) in , Plugins (add new), Network Plugins (add new)
  5. “Classic” search: search input with submit button, press Enter or submit button, in Posts, Categories, Tags, Pages, Comments, Users, Network index: search users, Network index: search sites, Network Sites, Network Users, Network Themes (installed), Network Plugins (installed)

We recommend only 2 forms of search:

  • the classic one, the same for every search, with visible submit button
  • the dynamic one:  adding wp.a11y.speak to show the results count, and making sure focus doesn’t change dynamically


  • Open ticket for the missing label for the  typeselector select field – @rianrietveld
  • Open ticket on a unified search form display: 2 types – @cheffheid


Usertest: Extra small test about role=application in Press This

Send to the test team March 26, 2015
For WordPress 4.2-beta2


We would like you to test the “Press This” categories selection in
You can access Press This directly in WordPress, at: /wp-admin/press-this.php

After the editor, you will find a “Post Options” area where you can set the Post format, Categories and Tags.
About Categories, it’s made with a list of DIV elements with role=checkbox, for several reasons developers choose to implement them this way so switching back to native checkboxes is not an option 🙂

You should be able to check them as you usually do with native checkboxes, by the way screen readers won’t automatically switch to “forms mode”.
To force the switch we added role=application to the list container.
This has pros and cons and, generally, it’s recommended to use role=application sparingly and wisely.
See for example this post by Mr. Zehe:

Since any recommendation and best practice should be always tested in a real world experience, we would like you to test what’s best for you.

  • with no role=application, users will have to manually switch to “forms mode”
  • with role=application, the switch should automatically happen but you will lose the native behaviour and other things like the number of items in the list being automatically announced, not mentioning arrowing won’t work.

Results so far:

Bram Duvigneau

After a quick look, I come to the following conclusions:

  • NVDA shows an application region and you need to press space bar/enter to interact with it. Please note this is not necessary if the user just navigates by pressing tab
  • The application region contains just a bunch of elements that behave like checkboxes

Given the fact that this is not a real application, but just a list of checkboxes, I recommend against using role=”application” here.
By putting the checkboxes in an <ul> or an element that has the corresponding aria role (list from the top of my head), you wil just make it clear that these checkboxes belong together. As a bonus I would suggest using the new wp.a11y.speak to announce the number of results when a user types in the search field, e.g.: “4 categories displayed” or similar.

Susan R Grossman


This doesn’t work for me even when using tab/shift/tab.

It skips some of the choices when trying to tab/arrow/space/navigate in any method through them.  Does every other “radio button”.

Geof Collis

On JAWS 14.5 IE11

I dont like it one bit and it should not be implemented, it goes against everything I know about radio buttons and checkboxes.

Not sure if this is relevant but when ever I see a form I go through the whole form without going into forms mode to give my self an idea what it looks like, then I will fill in the first edit box/ button etc, go out of forms mode go to the next field fill it in then go out of forms mode again, I do this for all forms because I dont trust them to cycle properly.

Michelle DeYoung

FF/NVDA/Win7: Once the screen readers announces “application” and throws me into forms mode, the next tab takes me back to the Category tab and “Back to Post Options Button” is voiced. Then I have to tab through the other items in the tab order to access the categories I would like to check/not check.
Each category item name is voiced with checkbox not checked.

IE/JAWS/Win7: Once the screen readers announces “application” and throws me into forms mode, the next tab takes me back to the Category tab and “Back to Post Options Button” is voiced. Then I have to tab through the other items in the tab order to access the categories I would like to check/not check.
Each category item name is voiced with checkbox not checked, to check press spacebar.

Chrome/ChromeVox/Win7: Once the screen readers announces “application” and throws me into forms mode, the next tab takes me back to the Category tab and “Back to Post Options Button” is voiced. Then I have to tab through the other items in the tab order to access the categories I would like to check/not check.
Each category item name is voiced with checkbox not checked item.

Keyboard only: Another accessibility impact would be for keyboard users. Tabbing to the category item highlights it but they have no idea that the item is selected and operational via a checkbox. If you do not want the checkbox displayed then add some verbiage to let visual keyboard users know how and what they are supposed to do so they don’t have to guess that if they use a spacebar that it will check the category item.

I would recommend not using the role=”application” in this case, and focus on getting this to work for screen reader users and keyboard only users. Perhaps a tab/accordian widget. Here is a link to an example, but it also is using role=”application” which impacts access via different screen readers, so in this example I would remove it as well, but it still shows a different widget option.
Example 37 – Tab Panel: Accordian using ARIA CSS selectors

I think the role=”application” will only frustrate users more and impact how they access those content items.

Anna Natorilla,

Trunk: This custom checkbox implementation allows the user to activate the checkbox with spacebar key only. The user has no problem checking the custom checkboxes. If the user reads the checkbox via virtual cursor mode and they press the enter key to select a checkbox, the screen reader will tell the users to press the spacebar key to check or uncheck a checkbox. Once the users check or uncheck a checkbox with the spacebar key, the user was switched to forms mode.

It is a fact that switching to forms mode on the checkboxes will cause the screen reader to not announce the number of items in the list. The user has to use virtual cursor mode to hear the list items numbering and levels.

Nightly: This native checkbox implementation allows the users to activates the checkbox with both the spacebar and enter key on via virtual cursor or forms mode. The users have no problem checking the forms control whether they are in forms mode or virtual cursor mode.

Gabriela Nino de Rivera Torres

Tools: Safari 8.0.4 + VoiceOver

I found very easy moving between the categories list. It’s a great improvement compared with the old situation. In the old version, first I need to go inside the group to interact with the items inside. When moving from one category to the next VoiceOver was speaking twice each item, one for the button ratio and the second for the text inside the button ratio, which was very annoying.

In the new version I don’t need to go inside the group to interact with its items. Selecting the ratio buttons it is also very easy to do.

Points not so good:

I noticed that when adding a new category, the user is not notified of the action. There is not a message confirmation to tell the user if the category was successfully created.

Also, when adding a new category, the category is selected by default (the ratio button is selected). The user won’t not know until she moves from one category to the next.

The categories are added at the beginning of the list under their parent category. It is funny, I was expecting to be added at the end instead. This has nothing to do with accessibility issues. 😀

When moving in the list of categories, there is nothing that announce the user if a category is a parent or a children. This information is being transmitted only visually.

For some reason all the sub-categories inside the testing category are announced by VoiceOver like “list of X items”. I added categories in other parent categories, but this behaviour only happened with the testing parent category. I looked in the code, I could not find any differences between the parent categories. So, I’m very puzzled about this.

Tina Tedesco

Using JAWS 15

Not sure I did this correctly but I concentrated on the list starting whith the checkboxes. I was able to check and uncheck with any problems.

When arrowing down it said, “Entering Categories Application.” Then arrowed down and came to accessibility, it indicated “list of 6 items.” When I arrowed passed accessibility it indicated “list of 4 items nesting level 1.” When I got to the end of that list it indicated “list end nesting level 1.)

I heard no more beginning or ending of levels until I arrowed passed JDFh checkbox. it indicated “list of 2 items nesting level 1.” When I got to the end of the list it said “end of list nesting level 1.”

I arrowed to Testing (did not mention a new listing) and when I arrowed again it said “list of 5 items nesting level 1 as well as end of list nesting level1. ”

Came to Uncategorized (nothing to indicate any listing before the word) arrowed down once indicating “list of 2 items nesting level 1.” Once I arrowed past the 2 items it said “list end nesting level 1.”

At the end of this list it said “Categories applications end.”

Should there have been some sort of message for all listings?

Hope this is not too confusing.

Malgorzata Mlynarczyk

Tested with NVDA in Firefox

As I’ve said before I’m not a native screen reader user, so I’m probably not the best person to test it (it would be better to test it with actual screen reader users). However, I personally prefer the solution with role=”application”. First of all, screen readers are expected to switch to application mode when in the form, so this is an expected behaviour. Once in the form, the users are used to navigate using Tab key, rather than by moving the virtual cursor using the arrow keys, so I don’t think this is a problem. The fake checkboxes work well – the change in state (checked / unchecked) and the ‘checkbox’ label are announced to the user. And although the screen reader doesn’t inform the user how many items the list contains, I don’t think this is particularly important here, and sighted users don’t know it either (unless they decide to manually count them…).


Accessible Theme Pattern Library Update for March

Another month has passed, and work on the Accessibility Theme Pattern has chugged along.

What’s Happened? We have code committed for four additional pattens, beside the read more links one that got us going. They are:

  • A skip link.
  • A skip link for Genesis themes.
  • Dropdown menus with jQuery and without jQuery.
  • Comment form, enhanced with JavaScript and ARIA.
  • Two more patterns in progress: responsive menu and mobile menu modal.

We’ve moved from separate repositories on Github to just one. All the patterns live in sub-directories within that repository. It’s called a11ythemepatterns. Within that, we also have a basic readme file and a contributions file, explaining how to contribute.

You can see the in-progress patterns in the issues on Github.

Note: The patterns are also still available via their own separate repositories, which you can see on our Github account. Don’t use/fork those, as they’ll be removed soon. Use the a11ythemepatterns repository.

If you have questions, don’t hesitate to ask in the comments.


Test Chat Summary, March 16, 2015

Last week, two patches were tested:

  • #31522 – Quicktags: use aria-label to improve accessibility
    Conclusion: The ARIA labels to the markup buttons are clear. The editor itself needs more work.
  • #31450 – Add landmark roles to WordPress admin areas
    Conclusion: The new landmarks are useful, the text could be better (main content and contact information are not specific enough).

The results of both test are added as comments with the tickets. Extra issues the testers found are included in a seperate post: Extra issues found by the wpa11y test team 

 We discussed some issues the testers reported:

  • Where should the skip to content link go, now it goes to help tab. Conclusion: leave as is.
  • Dashboard menu tab order: One tester remarked that it’s a pain to tab through all the sub menu’s in the main menu. Conclusion: Maybe this can be solved easily by binding arrow keys to jump to next LI item inside the same immediate parent UL or a similar solution. @joedolson will open an (enhancement) ticket about this, there we can investigate the options.

New tests for this week:

Because the work on 4.2 is ongoing and there are not a lot new difficult patches to test, a test of the diffent ways the search function in the admin works seems useful. An overview of work that needs to be done to get the search and the search results accessible.

Next week we could provide a list of the issues we hope are fixed in WP 4.2 and have them all reviewed by the testers.
Suggestions are welcome.


Extra issues found by the wpa11y test team

During the testing our #wpa11y test team finds extra issues, not covered by the issue they are testing, but very useful to report.

So here is a summary of issues found:

Quicktags-toolbar with keyboard only:

Reported by @gab-nino

Buttons icons or labels

The present menu use HTML language for the button labels for example: to add an unordered list, the button label is represented by an “ul”. The issue here is that ul is only going to be understood by the users that are familiar with HTML language. Someone that don’t know about HTML won’t be able to know what ul, ol, li does. Asking them to write a comment in HTML and to order the attributes correctly (like making sure that a li inside an ul or ol) is going to be difficult for people without disabilities (and more difficult for blind people). As a proposition, what about using icons that that are internationally understood? See the menu image at the bottom of this post.

Open < > versus close < / >

If the user want to add a list item, first thing to do is to select the li button and then go back to the text area, then add some text and after come back to the list item button to click on it again to close the item (/li).

The label button change from li to /li and the actions performed in each case are different (open and close), I noticed that nor NVDA or Safari will announce the user the current button action to execute. If the label is /li, the user will listen to “list item” instead of “close list item” (or some other text that explain better the action). Please refer to the suggestion at the bottom of the message.

Adding and erasing

If the user add a list item and right after decides to erase it, the function does not understand that the initial list item is not there anymore and the state of the action reminds on /li (close a list item). The user need to click on the button to deactivate the function. This is evident for people without disabilities, but screen reader will keep telling the user that the button is a list item (see the previous comment and suggestion below).

Without using the mouse

It is impossible to select text on the area and come back to the menu to apply a bold or italic option only using the keyboard. I could not move to the menu without losing the focus on the selected text.


I know finding a solution for the previous comments is not going to be easy, but I was thinking that something that might help is creating simultaneously the open and close tags for the selected option. So if the user clicks on li button, both < li > and < /li > tags will appear on the text area.

Remark Rian: worth a ticket to sort out what good solutions might be for this. Related ticket: #31522.

Skip link navigation and tab order

Reported by Tina Tedesco.

When I enter on the link skip to main content it always brings me to the Help link. Not sure that is a big deal but I find it strange.

Remark Rian: worth a discussion in Slack.

Heading structure: The H1 is missing

Reported by several testers.

The H1 element is missing from the Dashboard screens. We already had discussions about this in Slack. If and where it should be added en what the content should be is point of discussion. The wpbody-content title is now an H2, that should be the H1, but changing that would break the heading structure of the rest of the admin. In the Accessibility team we differ in opinion on how to solve this.

Remark Rian: open a ticket and discuss there further on how to change this and what the implications are for the Admin and for plugins.

The Dashboard menu tab order

Reported by Han Sinke.

Is it possible to optimize the Dashboard menu (or is there a screen reader option) to first make a choice for a main menu item, and after that enter a sub menu item? Now I want to go quickly to Plugins, but have to tab trough Appearance too (maybe distinguish arrow down and tab), or add extra hidden links?

Remark Rian:  worth a discussion in Slack, is there an easy fix for this or does this mean a complete rewrite of the menu?

Loss of focus for screen readers after an action

Reported by several testers.

On several places in the admin the screen reader users looses focus after an action.
When updating a plugin the focus is not on the confirmation message, so the user is not aware of the result of the action. She needs to “read” the page from the beginning to listen to the announce.

Remark Rian: let the experienced screen reader testers explore the Admin for loss of focus issues, so we can have an overview on where this occures and open a ticket about that later.


Actions to take on the issues above:

  • Send an e-mail to the experienced a11y testers about the loss of focus for screen readers after an action (@rianrietveld)
  • Discuss in Slack about where should the skip to content link go to and the Dashboard menu tab order (MWA team)
  • New ticket on: Quicktags-toolbar with keyboard only (@cheffheid)
  • New ticket on: Missing H1 element in Dashboard screens (@cheffheid)

Test Chat Summary, March 9

Meeting log on Slack

Last week, two patches were tested:

  • #31415 – Plugin and theme editor focus trap
  • #31368 – Let WordPress speak (a “test run” with Shiny Updates)

Overall test results look good and most issues found aren’t directly related to the tickets. Will put the test results in the appropriate tickets. Full summary of the test results will also be posted on the blog.

In relation to #31368, a tester noted that the automatic activation of plugins caused some confusion. @afercia mentioned that the automatic activation of plugins after installation is still under discussion. If this is going to become a feature we’d recommend changing the “Installed” message to “Installed and activated” so that it’s clear what has actually happened.

Other test reports note that some different flows for the same task (installing and activating plugins in this case) seem to have inconsistent outcomes. For example, when adding a plugin from the pop-up “more details” window, the user is asked to activate the plugin via a link, whereas pressing “Install Now” will automatically activate it as well. These findings will be reported as tickets.

For next week the following tickets with patches are slated for testing:

  • #31522 – Quicktags: use aria-label to improve accessibility
  • #31548 – Fix color contrast on wp-login.php to meet minimum accessibility standards
  • #31450 – Add landmark roles to WordPress admin areas

And finally, additional testing of failing plugin installs with Shiny Updates by @afercia and myself.


Accessibility Team Update: Week of March 2, 2015

This week, the team covered a range of topics, mostly giving each other updates on ongoing projects. Chat archive in Slack.

We talked about the accessible theme pattern library, which is ongoing. I’m leading this effort, and hope to hit 10 patterns before starting on a handbook for the accessibility team.

@rianrietveld gave an update on our weekly testing sessions, which happen every Monday. She says:

Last week we tested:

  • #31143 – Login error handling accessibility improvements
  • #31326 – Edit comment screen: misplaced-missing labels

This week we retest the update/install plugins after the introduction of wp.a11y.speak().

Full report on the testing.

@afercia updated us on wp.a11y.speak, which is a tool for developers to dispatch feedback messages text strings to an `aria-live` region within the WordPress Admin area. This makes it easier for users with assistive technology to know what’s happening on the screen.

We also talked about the upcoming enhancement deadline, and what we might need to retest and coordinate with the Core team. @afercia attended the Core meeting that day to help coordinate the efforts.

We also agreed as a team to rotate a team representative to attend the Core development meetings. @afercia has handled that recently, and we’ll get a schedule up on this site soon. To start, @rianrietveld will take April and I’ll take May.

See you next week everyone!


Complex form structures, combining checkboxes/radio buttons and input fields

Sometimes our weekly test sessions unearth issues outside of the scope of the patches and functionality that we’re testing. These issues are usually quick to resolve, but sometimes they require more deliberation to find an elegant solution.

One of those issues is dealing with compound settings. The way they are currently structured makes these settings a bit confusing to screen reader users. There are two reasons for this:

  • Shifting from a checkbox to an input field for a sub setting announces partial labels. For example, “Automatically close comments on articles older than [14] days” becomes “Automatically close comments on articles older than” for the checkbox and “days” for the input field.
  • Shifting from a radio button group to the “Custom” input field doesn’t properly announce what the field is for. For example, for the “Date Format” setting it will simply announce “Custom” and whatever the value for the input field is (ie. “F j, Y”).

For a more detailed description on these issues, see also tickets #31354 and #31356.

As part of last week’s testing session we had asked some of our expert testers for their opinions on how to properly solve this. This is a summary of their findings.

Checkboxes and input fields (#31354)

Michelle DeYoung

For the more complex labeling, here’s a bin with some example code:

It contains the html and css for a complex labeling and text scenario that uses radio buttons as well.

I know normally you don’t want to create a bunch of extra listening for the user, but in cases like these, I think the extra can help define/explain what is needed; hopefully clearer. Ideally, this would be something that would be great to have user testing applied to.

Gabriela Nino de Rivera

For this problem, I think the best strategy is to do like the romans: “divide and conquer”.

Showing all the information in one line could be visually nice, but as you mentioned, it’s not screen reader friendly.

What I would suggest is to break the action in different steps. Something like this:

Malgorzata Mlynarczyk

I think the main problem here is that those problematic options were designed with sighted people in mind, and so it’s as much an UX as an accessibility issue. I’m not a UX person, but here are my thoughts on the subject:

It will be difficult to code these complex options in a way which is not confusing to screen reader users (label for an input field, containing another fields and their labels).

I guess it could be achieved using a combination of label text, some visually hidden text and text hidden from screen reader users (see example below), but it’s a bit complicated and may not work for all the checkboxes (perhaps the wording of some of them would need to be changed).

For the ‘break comments into pages’ checkbox you could use the following code:

Another solution would be to simplify the form and split all those complex options into several options (each containing just one form field and label), for example:

Radio buttons and input fields (#31356)


Our testers, rightly, pointed out that the legend is properly announced for them – adding context to the Date and Time Format radio buttons. Some investigation reveals that NVDA won’t announce text wrapped by span tags inside of legend tags when using Chrome. The suggestion is to remove these span tags as well.

Gabriela Nino de Rivera

I prepared an example form that include a suggestion for this problem. When I did the tests with VoiceOver and NVDA, I found it easier to navigate and to understand what needs to be fill in to complete the form.

The example can be found at:

Things that have been changed:

  • I moved the description texts before their input (for example tagline description), so we can listen to the information before we need to fill text.
  • I added significant information to the legends attribute, so the user is informed of the actions required inside the fieldset.
  • I associated the labels to their ratio buttons and removed the title attribute from them.

About the last change: Here we have a big issue because the title is notifying an important information to the user. But the problem is that not all the screen readers will read the label title. So, when doing the test on NVDA, this information was not notified to me. I don’t have a solution for this, the only thing I can think is to add it inside the span like this:

<span>4:26 PM (g:i A)</span>

But this is only solving the problem in half, because even if the screen reader announce it to the user, I won’t hear the two points (:) and won’t know that the A is capital letter.

Malgorzata Mlynarczyk

  • I would change implicit labels to explicit ones (using ‘for’ attribute pointing at the relevant form field)
  • I absolutely agree with you that the input field for custom date or time should be disabled and not focusable until the relevant ‘custom’ radio button is selected
  • each of those ‘custom’ text input fields needs to have a label, which can be visually hidden
  • I would perhaps also add ‘aria-live=”polite”‘ attribute to the showing an example (based on the selected format), so that it would be read out when it’s updated. I’d test it though first with different screen readers to make sure it works as expected.

So my mark-up for the time format fields, for example, would be something like this:

In conclusion

A lot of great feedback here. For solving complex form structure issues there seem to be two viable options:

  • Use hidden labels to make sure these fields have additional clarification for screen reader users.

    This option doesn’t compromise the way these settings look right now at all, while still solving the issue with fractured and incomplete labels.

  • Split them up into their own stand-alone fields.

    This will definitely clarify things for screen reader users, but could potentially clarify it for sighted users as well. However, it will require rewriting of labels and will also have a visual impact on the settings screen.


Test Chat Summary, March 2

About the testers: we still get new testers who want to join the group, we have 54 testers now, about 20 of them join the tests every week actively. So that’s going well.

Last week we tested the patches for:

  • #31143 – Login error handling accessibility improvements
  • #31326 – Edit comment screen: misplaced-missing labels

The results were added as comments with those tickets.

Some of the testers found extra issues, not related to the tests, like the poorly labeled buttons in the comments editor (@afercia opened a ticket for that #31522). Another issue is the loss of focus for screen reader users in various places in the admin. This can’t be solved easily and we plan to discuss this in the Wednesday meeting of the accessibility group.

We asked to the more experienced developers and accessibility experts for solutions for properly combine label/input/checkboxes/radio buttons in complex structures, like mentioned in #31354 and #31356. We will publish their findings and idea’s on this blog later this week.

The new tests for this week are the patch with ticket #31415 and a retest of update/install plugins after the introduction of wp.a11y.speak() #31368.

@DrewAPicture reopened ticket #26504 (Semantic elements for non-link links) for us to serve as a tracking ticket for related tickets and work on this issue.