Make WordPress Accessible

Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

  • David A. Kennedy 12:01 am on March 24, 2015 Permalink

    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.

  • Rian Rietveld 3:48 pm on March 17, 2015 Permalink  

    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.

    • Jackie McBride 6:04 pm on March 22, 2015 Permalink | Log in to Reply

      Hi. I’d like to report 2 accessibility problems w/the current version of WordPress, which likely carry over into 4.2 as well.

      The first is a problem I reported 4 years ago & still exists today. Xcreenreaders cannot read submenu items. So if there is a menu w/subitems beneath it, i.e., blogs > my blog, the blind user gets no indication either that there are subitems, nor do these appear to open when the link is clicked.

      The second issue has to do w/moving items up & down in a menu. The way the ‘Up’ & ‘Down’ links currently work is that if you have a menu item, & you wish to move it down 1, but that item has subitems beneath it, then the item you move down becomes a subitem. Same w/’Up’. It’d be good if these links would skip menu items w/subitems. In other words, unless the developer specifically moves an item under another item, the ‘Up’ & ‘Down’ links should, it seems to me, go 1 above or below the item in question. Otherwise, take my word for it–the whole thing becomes a real nightmare.

      I hope this helps, & if I can assist further, please don’t hesitate to contact me.

    • Jackie McBride 10:03 pm on March 30, 2015 Permalink | Log in to Reply

      Abletec wrote:

      “The first is a problem I reported 4 years ago & still exists today. Xcreenreaders cannot read submenu items. So if there is a menu w/subitems beneath it, i.e., blogs > my blog, the blind user gets no indication either that there are subitems, nor do these appear to open when the link is clicked.”

      I’m trying to say that when navigating a WordPress site, submenu items are not read by screenreaders. So if I go visit a site built w/WordPress, & it contains a menu w/subitems, like blogs > blog a > blog b, where blog a & blog b are subitems under blogs, the only menu item that will be read is blogs. When blogs is clicked, then it will go to whatever the blogs item leads to. So accessing the submenu items in a WordPress site is problematic.

      “The second issue has to do w/moving items up & down in a menu. The way the ‘Up’ & ‘Down’ links currently work is that if you have a menu item, & you wish to move it down 1, but that item has subitems beneath it, then the item you move down becomes a subitem. Same w/’Up’. It’d be good if these links would skip menu items w/subitems. In other words, unless the developer specifically moves an item under another item, the ‘Up’ & ‘Down’ links should, it seems to me, go 1 above or below the item in question. Otherwise, take my word for it–the whole thing becomes a real nightmare.”

      When editing a site menu, you’re presented w/a dialog. You can change the label, move the item up or down 1, & move it under an item. When you move an item up or down, you can inadvertently move it under another item. I’m saying it’d be better if the ‘up 1’ & ‘down 1’ items actually bypassed subitems, i.e., if my item is above an item called ‘blogs’, & blogs has subitems, if I click the ‘Move Down 1’ button, it should move *below* blogs, not under it. There is a separate choice to move an item under another item. It’s really kind of a tough thing to work with as it is right now.

  • Rian Rietveld 11:49 am on March 15, 2015 Permalink  

    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)
  • Jeffrey de Wit 1:49 am on March 10, 2015 Permalink  

    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.

  • David A. Kennedy 5:04 am on March 8, 2015 Permalink

    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!

  • Jeffrey de Wit 10:33 pm on March 3, 2015 Permalink

    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: http://jsbin.com/rimoqu/

    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: http://jsbin.com/pogefemiha

    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: http://jsbin.com/vafapi/

    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: http://jsbin.com/rimuwo/

    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: http://jsbin.com/fuxagu

    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: http://jsbin.com/jaqehanalo/.

    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.

  • Rian Rietveld 4:04 pm on March 3, 2015 Permalink  

    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.



  • Rian Rietveld 10:59 am on February 22, 2015 Permalink

    Admin plugin pages and Shiny Updates: Accessibility user test result 

    Tested on WordPress 4.2-alpha
    Summary of the result at the bottom of this post.


    • Kim van Iersel
    • Gabriela Nino de Rivera
    • Tina Tedesco
    • Malgorzata Mlynarczyk
    • Greg Wocher
    • Jeff de Wit
    • Petra de Jong


    Go to Dashboard > Plugins > Add New
    Add a new plugin (any plugin, witch one doesn’t matter)
    Can you add a plugin and also is it clear what happens for a screen reader user.

    Go to Dashboard > Plugins > Installed plugins
    Can you also test updating an already uploaded plugin.

    Test results

    Kim van Iersel

    Jaws 15.

    When I clicked on a plugin, after the name appeared some message which implied that the plugin should be installed. I thought it was not clear because I’m used to read this info below/with the heading. Now there was no notice that plugin was downloaded and installed. I went to the plugins, the list of installed plugins and there it was, activated and all!
    For me personally, there is little information about the process and results.

    Gabriela Nino de Rivera:

    NVDA for Windows XP and FireFox, VoiceOver OS X Yosemite 10.10.2 and Safari. Extensions for Firefox: WAVE toolbar, Web developer toolbar and Jim Thatcher favelets. Firefox Inspector for manual code review.

    From Dashboard > Plugins > Add New page, there are two ways for adding a new plugin: first one is clicking on the “Install now” button available with the plugin information.

    The second one is to chose “more details” where an “Install now” button is at the bottom of the popup frame.
    Before adding a plugin, the user needs to search for it. The user might or might not know the plugin’s name. I’m not sure if the process for searching a plugin is in the scope of this test, so I’ll try to be short.
    Searching for a plugin

    To search for a plugin, the user can sort by category or use the search tool on the page.
    A list of five categories are available for the user (featured, popular, recommended, favorites and Beta testing). After being redirected to the category page, the user it is not notified where she is. The focus is moved at the beginning of the page, the user need to come back where she were. There is only a visual indication so NVDA and VoiceOver can’t tell the user current location.

    Plugin categories

    The search tool form it is a little bit confusing. When using the search tool, NVDA and VoiceOver will recognize that there is an input text, but it seems that the association between the label and the input is missing. This could be maybe occasioned by the hidden objects on the form.

    <form class="search-form search-plugins" method="get">
    <input type="hidden" value="search" name="tab"></input> <label><span class="screen-reader-text">Search Plugins</span>
    input class="wp-filter-search" type="search" placeholder="Search Plugins" value="" name="s"></input></label>
    input id="search-submit" class="button screen-reader-text" type="submit" value="Search Plugins" name=""></input></form>
    • Inputs are missing an id attribute
    • Label is missing the for attribute to make the association with the input.

    There is a select menu on the search form that it appears when a search is done. This select menu is missing a label, so when the focus is on this element, NVDA and VoiceOver won’t give any extra information than “keyword popup button” or “select menu keyword”.
    <select id=”typeselector” name=”type”>
    <option selected=”selected” value=”term”></option>
    <option value=”author”></option>
    <option value=”tag”></option> </select>

    Adding a plugin
    Clicking on the “Install now” button available with the plugin information
    When adding a plugin from the button “install now”, even if the focus on this element, none of the two screen readers notifies the user about the progress or the installation confirmation. The feedback is only visual.

    Plugin installed

    Clicking on the “Install now” button at the bottom of the “More details” popup information

    If the user decides to add a plugin from the “install now” button on more details, she will be redirected to a confirmation page where she can easily have feedback about the installation.

    Install via more details

    When an error happens the focus is not moved to the error element, so the user can not know about it unless she moves to the top and read again the page with the screen reader. Errors are only identified visually: by a red line at the left of the text.
    When the error is written in other languages, it does not seems to be using the lang attribute to specify the language of the text.

    Error message in another language

    Tina Tedesco

    I tried installing a plug in and received no information from my screen reader.  It did not seem like anything happened.  I received no message or additional information.

    Malgorzata Mlynarczyk

    I was able to add a plugin using keyboard only, and using a screen reader (NVDA in Firefox and Chrome). However, I did notice few issues:
    There’s a missing <h3> heading. I’d probably place this heading somewhere at the beginning of <div class=”tablenav top”> container, and set its value to a currently selected plugins category (as shown in <ul class=”filter-links”>). So, for example, if the page is showing “Popular” plugins, this heading should be <h3>Popular plugins</h3> (this heading can be hidden from sighted users).
    At the moment the selected category of plugins (‘Featured’, ‘Popular’, ‘Recommended’, etc) is only indicated using visual cues (border-bottom and different text colour). Screen reader users don’t know which page they are viewing when browsing through that list of links. The currently viewed page shouldn’t really be a link (because it’s only linking to itself), and/or maybe it would be useful to add some text to the selected one (hidden from sighted users).
    For example, on the page showing ‘Popular’ plugins, the list could look like this:
    <ul class="filter-links">
      <li class="plugin-install-featured"><a class="" href="[..]/wp-admin/plugin-install.php?tab=featured">Featured</a></li>
      <li class="plugin-install-popular"><span class=" current"><span class="screen-reader-text">Selected: </span>Popular</span></li>
      <li class="plugin-install-recommended"><a class="" href="[..]/wp-admin/plugin-install.php?tab=recommended">Recommended</a> </li>
    On most of the ‘Add Plugins’ pages the search area only contains one input field (‘Search plugins’). However, on the ‘Search results’ page there’s an extra field, a dropdown list. That dropdown list has no label. It should be labeled, for example:
    <label for="typeselector"><span class="screen-reader-text">Search plugins by: </span></label>
    <select id="typeselector" name="type">
      <option selected="selected" value="term">Keyword</option>
      <option value="author">Author</option>
      <option value="tag">Tag</option>
    <label for="search-text"><span class="screen-reader-text">Enter word or phrase:</span>
      <input type="search" value="form" name="s" ffpdm="gff6ot1hm6l5m5fe7xst3o">
    ‘Search plugins’ button is hidden. This means that from sighted keyboard users point of view the focus disappears from view when the focus is moved away from the ‘search plugins’ input field. Focusable elements shouldn’t be hidden from view, as this can be confusing to sighted people who use keyboard.
    For every listed plugin there’s an image link without text or an ‘alt’ attribute. This means that the purpose of those links will be unknown to screen reader users. NVDA read out for each of them ‘plugin-install tab=plugin-info”. I don’t think it’s necessary to wrap a link around those images, as there is an adjacent text link to the same page right next to it. I personally would remove the <a> element and add an empty ‘alt’ attribute to each of those images.
    image link without text or an 'alt' attribute
    When the text of the ‘Install Now’ button changes to ‘Installed’, the colour contast ratio between the text and the background is not sufficient – only 2.07:1, which is below the required minimum (4.5:1).
    colour contrast installed plugin button
    ‘Install Now’ button and screen readers:
    • This button should be marked-up using <button> element, rather than <a>, as it is not a link (it doesn’t take the user to a different location). From a screen reader user point of view, selecting that link doesn’t do anything – the user stays on the same page.
    • for me, the value of ‘aria-label’ attribute on that element was not read out by NVDA. Perhaps ‘aria-describedby’ would work better? It could point at the preceding heading, which contains the name of the plugin
    • I was also wondering if perhaps screen reader users should be given some feedback as to what is happening on the page after the ‘Install Now’ button has been pressed. I’d try adding ‘aria-live=”polite”‘ on that button (or a <span> inside that button, containing the button text). In that way whenever the text of that button changes (‘Install Now’ -> ‘Installing…’ -> ‘Installed!’), it should be automatically announced to screen reader users. However, please bear in mind that I haven’t tested it, so I can’t guarantee it will work as expected. I would try it though.

    Greg Wocher

    JAWS and NVDA on my Windows 8.1
    I was unable to install any plugin. I would click on the link that said install this
    plugin and nothing happened.

    Petra de Jong

    Screenreader Supernova
    No problems with adding a plugin. I knew which plugin I installed and that the install was successful.

    Jeff de Wit

    Adding plugins seems to function fine. There’s a lot of tabbing involved in selecting a plugin though. No different from how it is with 4.1, it’s 5 links per plugin block after all. Though 3 of them (image, title, more details) open the same modal.

    Updating seems to work fine as well with just a keyboard. I was having some minor issues with updating Jetpack, but it’s probably because Jetpack auto-updates. :)
    NVDA doesn’t actually tell me that the update or installation of the plugin is complete though. It also seems to announce table rows and stuff as I go through the installed plugin page (I think that’s a known issue).

    Comment by Rian

    Regarding the missing visible submit button in search plugins: I can see and I often find myself installing a featured plugin instead of doing a search. With out thinking, I expect a submit button, and therefor I press the nearest submit button in sight. Maybe for usability (don’t make me think?) a visible submit button would be nice with the search plugin form.

    Summary a11y test plugin pages and Shiny Updates

    Overall: And this doesn’t only count for the plugin pages: The heading structure is not semantic, a missing H1 and there are skipped levels in the admin pages.

    Search plugin:

    • Screen reader users get no feedback on what catagory they are seaching in
    • ‘Search plugins’ button is visually hidden, not usable
    • The search plugin form has no label (added a comment: #26600)
    • Select menu on the search form with search results : missing a label

    Adding a plugin:

    • Screen reader users get no feedback if a plugin is installed or not
    • When an error happens in /wp-admin/update.php?action=install-plugin the focus is not moved to the error element (related: #31368)
    • When the error is written in other languages, it does not seems to be using the lang attribute to specify the language of the text.
    • When the text of the ‘Install Now’ button changes to ‘Installed’, the colour contast ratio between the text and the background is not sufficient.

    Updating a plugin:

    • Screen reader users get no feedback if a plugin is updated or not

    Comment by Andrea

    I would like to add one thing no one reported, may I? :) The Install Now “button” (should be a real button) has an aria-label attribute that should be updated together with the button text updates, so when the button text changes to “Installed!” the aria-label should be updated too, currently it’s not:

    <a ... aria-label="Install Getty Images 2.3.0 now">Install Now</a>
    <a ... aria-label="Install Getty Images 2.3.0 now">Installed!</a> <-- conflicting infos

    Just after a page refresh the button is correctly changed to a span with correct information but it uses a title attribute that should be avoided, see “Title attributes galore” https://core.trac.wordpress.org/ticket/24766

    <span ... title="This plugin is already installed and is up to date ">Installed</span>

    Additional notes

    • keyboard focus may be lost, for example on the Installed Plugins screen, when you activate the “update now” link, the whole HTML of that section is updated via JavaScript and the link removed, so keyboard users will be lost.
    • Errors handling (failed update, failed install) and feedback could be improved. Additionally, in some cases like a failed update, you have no UI controls available to take any further action, your only option is to refresh the page.
  • Rian Rietveld 4:17 pm on February 16, 2015 Permalink

    Missing label associations throughout network admin: Accessibility user test result 

    Related ticket: https://core.trac.wordpress.org/ticket/30486

    Result: Taborder footer is fixed, see also the summary at the bottom of this post.
    Further: A lot of other issues where found using the table with a screen reader/keyboard.

    We asked the testers to log into the test server with a network install and check the label-input relation on pages like:

    • Dashboard
    • All sites
    • Add new site
    • Edit site ( tabs info, users, themes & settings)
    • Add new user
    • Settings
    • Check the HTML and check if the input fields still work.


    • Anna Natorilla (Desktop Windows 7, IE 11, and JAWS 16)
    • Jeff de Wit (Keyboard,ChromeVox and code review)
    • Malgorzata Mlynarczyk (NVDA/Firefox + code review)
    • Michelle DeYoung (code review and Windows 8.1 using FF/IE/Chrome)



    quick edit label

    edit site user tab label


    Labels are fixed on Dashboard, All sites, Add new site, Edit site ( tabs info, themes & settings), Add new user, and Settings. Only Edit site on users tab have one checkbox which is not labeled properly. Under Edit Site: User tab, the checkbox before the username does not have a valid label. The label’s for attribute value does not match the id attribute value of the checkbox.

    New: The form control primary site does not have a valid label. Location:/wp-admin/my-sites.php

    New: Under Post’s quick edit scenario, form controls – date month, day, year, hour, minute, and second does not have a valid label. Each form control does not have an id attribute to match the value of the for attribute with its related label tag. Location: /wp-admin/edit.php

    Malgorzata Mlynarczyk

    My sites page:

    “Primary site” element had no label, but the visible text was read out by the screen reader, as it was marked-up as a header cell (and so was associated with the cell containing the form field).my site label

    Add site page

    • the radio buttons in the “Privacy” section should be wrapped in a <fieldset> element and have a <legend> explaining the purpose of those controls. Otherwise screen reader users only hear “Privacy, yes radio button”, “no radio button” which doesn’t fully explain the purpose of those buttons. Example:

        <legend>Privacy: <span>Allow search engines to index this site.</span></legend>
        <label class="checkbox" for="blog_public_on">
       <input id="blog_public_on" type="radio" checked="checked" value="1" name="blog_public" ffpdm="qh8fxqe6ln9x8748wy80qr">
        <label for="blog_public_off" class="checkbox">
          <input type="radio" value="0" name="blog_public" id="blog_public_off" ffpdm="gil0ltqsbd06z4p0dx72pk">
    • the error message displayed on that page was not descriptive enough. It only said “Sorry, that site already exists!” without specifying which field it related to (‘site name’? ‘site title’? both?). Also, when the error is detected and the message is displayed on the page, the focus stays on the ‘Create site’ button, which means that screen reader users will now know what is happening, and why the form hasn’t been submitted. Either the error message should be displayed in a modal window, or the keyboard focus should be moved to the top of the error message. Otherwise screen reader users will have to go back to the form and investigate what has happened.

    Add new user page

    • just like on the “My sites” page, the main content was placed in the HTML table for presentational purposes. This creates unnecessary noise for screen reader users, as the screen reader read out the field’s label, its position within the table, and the corresponding header cell (the label again), for example: “role, row two, role combo box ‘subscriber’ collapsed”. Ideally, CSS should be used for layout purposes and not HTML tables. If this is necessary though, role=”presentation” could be added to tables used for layout (table role=”presentation” […]></table).
      In that way the screen readers will ignore the table mark-up when reading out the content;
    • when required fields were left empty, the form was not submitted, but no error messages were displayed. The problematic fields were only identified using colour, and so visually impaired people will not be aware of the identified errors and which fields they have occurred in.

    Settings page

    • ‘custom date format’ and ‘custom time format’ input fields were missing labels. Each of them should have a label, for example: ‘enter date format’ (which can be hidden from view);
    • labels for radio buttons had no ‘for’ attribute;
    • please note that screen readers will ignore the additional information displayed under / next to the form fields while in form (application) mode. You could consider adding aria-describedby attribute to each form field with additional information, pointing at the element containing that information, for example:
      input type="email" class="regular-text ltr" value="emailaddress" id="new_admin_email" name="new_admin_email" ffpdm="zovnc9anu1pi7qxdkwcjrh" aria-describedby="new_admin_email_info">
      id="new_admin_email_info" class="description">This address is used for admin purposes.......</p>


    Jeff de Wit

    On the Network Settings page(/wp-admin/network/settings.php) you can set the “Site upload space”. ChromeVox tells me that “Limit total size of files uploaded to” is a checkbox and whether it’s checked or not. Only after I tab to the next field will it announce the input field to me as “100 MB, edit text – size in megabytes”.

    There’s no continuation or link between the file size input field and the checkbox that sets that limit.

    For clarity, here’s the thing I’m talking about:
    upload settings



    To ensure that users will hear the text after the input field is announced by the screen reader, use aria-describedby. When the user tabs into the input element the label and paragraph text will be voiced by the screen reader.
    Add for and id attributes to implicit labelling to ensure that older AT’s can interpret the label/input relationship.



    Some labels were still missing, this is already reported with the ticket during this week. The rest will follow this week.

  • Rian Rietveld 4:13 pm on February 16, 2015 Permalink

    Tab order table of posts in edit.php: Accessibility user test result 

    Related ticket: https://core.trac.wordpress.org/ticket/30914
    Result: Taborder footer is fixed, see also the summary at the bottom of this post.
    Further: A lot of other issues where found using the table with a screen reader/keyboard.

    We asked the testers:

    • Go to Dashboard – Posts – All posts
    • On this page there is a table with the current posts, you can edit/quick edit/Trash and View posts from here
    • We are testing a fix, so that the tab order is right for this table.
    • Is the tab order logical for this page, can you tab through the post table and do you understand where you are and is everything read out well or clearly visible.


    • Kim van Iersel (Jaws 15)
    • Suzanne van den Bercken – Boonacker (Jaws 16)
    • Geof Collis (Windows 7 JAWS 14.09 NVDA 2011 IE11)
    • Anna Natorilla (Desktop Windows 7, IE 11, and JAWS 16)
    • Tina Tedesco (Jaws 15)
    • Greg Wocher (JAWS and NVDA on my Windows 8.1)
    • Malgorzata Mlynarczyk (code review and screen readers)
    • Michelle DeYoung (Windows 8.1 using FF/IE/Chrome)
    • Bram Duvigneau (code review and screen readers)
    • Chandra Shekar (Windows + Firefox + Keyboard + NVDA Screen Reader)



    The comments are read out as 1 or 2, adding the word Comment to that would make it clearer


    I initially found that navigating worked with moving through the cells with control, alt and the arrow keys, arrow keys and the tab key but later found they didn’t line up properly.What I did find a little redundant was having the name of the post, name of post with checkbox, followed by the post name again then quick edits when tabbing through the cells (JAWS only)

    When I arrow through the cells I only get the quick edit link not the others but when I enter the quick edit cell i can arrow through them, a little confused here, I expected arrow and tab to do the same thing, my normal navigation is to arrow not tab so we have a mismatch here.


    Compliment: Column headers and row headers are labeled correctly. Jaws tells me that I am focusing on a column / row header when tabbing through the table.

    Column headers: Tabbing the column headers using the tab key brings up information in a different order than displayed on the braille display.

    Spoken order: Checkbox SelectAll; title; comments; date
    Braille display: checkbox SelectA;;, Title (link); author; categories; tags; comments (link); date (link).

    Conclusion: Seems that column headers that are not containing a link are skipped by the tab order. Sounds logical, though all column headers are valuable to comprehend the way the table is constructed and to know the information that can be found.

    Tabbing rows: Again the tab order by using the tab key on the keyboard differs from what is shown on the braille display.

    Spoken order (first row for example): checkbox SelectNewPost; Title New Post (link); Edit (link); quick Edit (link); Trash (link); View (link); Date published; categories “uncategorized”(link); Comments “2” (link).
    Braille display: Checkbox SelectNewPost; New Post (link); mwa (link); uncategorized (link); –; 2 (link); 2015/02/09 published.

    Spoken order tabbing backward (using Shift+Tab) differs from tabbing forward (using Tab).
    Spoken order backward (first row for example): Comments 2 (link); categories “uncategorized” (link); author “mwa”; Title “New Post”; checkbox SelectNewPost


    • A. The action links (edit, quick edit, trash and view) are not visible in the table reading by braille, but are in the tab order when going through te table.
    • B. Tabbing forward the order of columns spoken seems to differ from the order in which the same columns are shown in braille / on screen.
    • C. Tabbing to the Date Column only tellsyou the post is published, does not pronounce the date (2015/02/10).
    • D. The tab order forward and backward differs. Forwards 4 action links are brought to focus that are not visible in the table reading by braille and not brought to focus tabbing backward.
    • E. Tabbing forward (using TAB) does not bring focus to the Author column. The column is brought to focus tabbing backward from the date column using Shift+Tab.
    • F. Tabbing backward the Date column is not brought to focus, therefore the Author Column is brought to focus.


    Helpful Information: Some JAWS 16 users may not know that Trash, and View links which are related to each title link exist as users of screen reader do not have to tab to the title link to read the table information. Users of screen reader can read the table title link and its associated hidden Quick Edit link even without tabbing on the title link.

    Steps to read a table: While JAWS 16 is turned on, go to the table and press the T key. To navigate between cells, hold down Ctrl + Alt and use ↑, ↓, ←, or → to move from cell to cell.


    When using tab through the table it did not read the column headers or row location.

    When using Ctrl+alt+any arrow key, The row in the first column would say row. I was confused a few times when I arrowed left/right or up/down the row was not spoken. That made it a little more difficult to figure out where I was.


    In the first test the tab order is just fine. I like how that when I tab to select it actually tells me what post I am selecting.

    One thing I would like to see is that instead of hearing move this item to trash, it would say the name of the item like it does when I move to the select this item checkbox.

    Another issue I am finding is that when you tab past the select checkbox it will say the name of the post and edit name of post. If you arrow this should just be a link for the post. The edit item link is the next item you tab to.

    Michelle DeYoung

    The tab order of the tables has greatly improved from the last check! YEAH!

    Allow screen reader users to know that the Bulk Action selections and Filter selections can be applied to the items they select in the table. Either visually add a description, or hide it, but still allow screen readers to access the text. Also create a data association between the descriptive text and inputs elements. Should apply to all screens with similar tables.


    1. Add paragraphs of descriptive/instructional text to that screen readers can voice to the user so the inputs and their purpose are more understandable.
    2. Use aria-describedby to tie the select elements to the associated paragraph with matching id value for more clarity of the purpose of the element.
    3. Add aria-label to the input buttons so they are more descriptive.
    <div class="alignleft actions bulkactions">
    <p id="bulk-actions-options" class="screen-reader-text">You may choose a Bulk Action item to apply to the posts you select from the table below.</p>
    <label class="screen-reader-text" for="bulk-action-selector-top">Select bulk action</label>
    <select id="bulk-action-selector-top" name="action" aria-describedby="bulk-actions-options">
    <option selected="selected" value="-1">Bulk Actions</option>
    <option class="hide-if-no-js" value="edit">Edit</option>
    <option value="trash">Move to Trash</option>
    </select><p id="bulk"></p>
    <input id="doaction" class="button action" type="submit" value="Apply" name="" aria-label="Apply selected bulk action">
    <div class="alignleft actions">
    <p id="filter-choices" class="screen-reader-text">You may select a filter options to apply to the table of posts below.</p>
    <label class="screen-reader-text" for="filter-by-date">Filter by date</label>
    <select id="filter-by-date" name="m" aria-describedby="filter-choices">
    <option value="0" selected="selected">All dates</option>
    <option value="201502">February 2015</option>
    <label class="screen-reader-text" for="cat">Filter by category</label>
    <select id="cat" class="postform" name="cat" aria-describedby="filter-choices">
    <option value="0">All categories</option>
    <option class="level-0" value="1">Uncategorized</option>
    <input id="post-query-submit" class="button" type="submit" value="Filter" name="filter_action" aria-label="Apply selected filter choices">
    For inputs under table:
    <div class="alignleft actions bulkactions">
    <p id="bulk-actions-options-bot" class="screen-reader-text">You may choose a Bulk Action item to apply to the posts you select from the table above.</p>
    <label class="screen-reader-text" for="bulk-action-selector-bottom">Select bulk action</label>
    <select id="bulk-action-selector-bottom" name="action2" aria-describedby="bulk-actions-options-bot">
    <option selected="selected" value="-1">Bulk Actions</option>
    <option class="hide-if-no-js" value="edit">Edit</option>
    <option value="trash">Move to Trash</option>
    <input id="doaction2" class="button action" type="submit" value="Apply" name="" aria-label="Apply selected bulk action">

    Screen readers voice the sortable table headers as: (Italicized is the screen reader voicing the table column)

    • Column two Title Link”
    • Column six Comments link”
    • Column seven Date link”

    The sortable headers should be voiced as sortable and ideally whether they area ascending or descending.
    Perhaps something like, “click to sort”

    • Column two Title link click to sort”
    • Column six Comments link click to sort”
    • Column seven Date link click to sort”

    The Select All heading (label for checkbox) is being announced by the screen readers at the start of the first data cell in each row of the table.

    • “Row one column one Select All checkbox not checked”
    • “Row two Select All column one Select NV Access checkbox not checked”

    This could possibly be confusing for screen reader users to hear “Select All” and then Select…checkbox.

    If the column heading was just “Select All” I don’t think it would be that much of an issue, but since the column heading is Select All with a checkbox, that seems to make it more specific to that item (the select all checkbox) and not as a header for the whole column. Although, the user is to select whatever items/posts they want to apply an action too.


    Either leave as is and get some user testing feedback, or try this:

    <span id="add" class=”screen-reader-text”>All</span>
     </div><!--end for tabletopnav-->
     <!--<label class="screen-reader-text" for="cb-select-all-1">Select All</label>-->
     <table class="wp-list-table widefat fixed striped posts">
     <th scope='col' id='cb' class='manage-column column-cb check-column' style=""><label class="screen-reader-text" for="cb-select-all-1">Select</label><input id="cb-select-all-1" type="checkbox" aria-describedby="add" /></th>

    Screen readers will voice it as:

    • “Row one column one Select checkbox All not checked”
    • “Row two Select column one Select NV Access checkbox not checked”


    TinyMCE documentation:

    There’s a typo in the TinyMCE documentation where it says “Jump to Tool Buttons Alt-F1” should be “Jump to Tool Buttons Alt-F10” (http://www.tinymce.com/wiki.php/TinyMCE3x:Accessibility)
    You can try here: Alt-F1 does nothing, Alt-F10 works.  (http://www.tinymce.com/tryit/full.php)

    Bram Duvigneau

    The various edit/delete links have title attributes. These attributes are all the same (Edit this post, delete this post etc). Either remove them or make them describtive (like “Edit post Test”). However, the View link has a better title attribute.

    The select all checkbox shouldn’t be marked as column header. This causes NVDA, and probably other screenreaders as well, to announce (Select all, select Test) when tabbing through the table

    Chandra Sekar

    Header row:

    Expected Tab order/sequence for the All post Table

    • Check Box
    • Mobile test <Title>
    • Edit | Quick Edit | Trash | View <On Tab sub menu for Title>
    • mwa <Author>
    • Uncategorized <Category>
    • Ally test, Keyboard test, screen reader test <Tags *added this for test purpose>
    • 0 <Comments>
    • 21 mins ago, Published <Date>

    Current Tab order

    • Check Box (Works)
    • Mobile test <Title> (Works)
    • Edit | Quick Edit | Trash | View <On Tab sub menu for Title> (Works)
    • mwa <Author> (Works)
    • Uncategorized <Category> (Works)
    • Ally test, Keyboard test, screen reader test <Tags *added this for test purpose> (Works)
    • 0 <Comments> (Works)
    • 21 mins ago, Published <Date> (Skips to next content row, avoiding the Date column)

    The tab order of the tables has greatly improved from the last check!

    Summary testresults

    Taborder footer is fixed. Moving the tab order of the footer was a good idea it works of keyboard and screen reader

    But while testing a lost of other issues where found. like:

    • Allow screen reader users to know that the Bulk Action selections and Filter selections can be applied to the items they select in the table.
    • The Select All heading (label for checkbox) is being announced by the screen readers at the start of the first data cell in each row of the table. This could possibly be confusing for screen reader users to hear “Select All” and then Select…checkbox.
    • The checkbutton was reason for much confusion
    • The comments are read out as 0, 1 or 2, adding the word Comment to that would make it clearer
    • The double link to edit post is confusing (also for sighted users)
    • Tab key and arrow keys don’t match up, arrow key skips the quick edit links unless you are in the cell
    • Some testers also added remarks about the colour contrast, we will open a new ticket on that.
compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc