Make WordPress Accessible

Welcome to the official blog for the WordPress Accessibility team.

The a11y group provides accessibility expertise across the project to improve the accessibility of WordPress core and WordPress resources.

Want to get involved?

Join the discussion here on the blog, or check these areas out:

Looking for support?

If you have questions or need support related to WordPress & accessibility, please visit the WordPress Accessibility forum.

Weekly meetings

We use Slack for real-time communication.

The team has a meeting every Monday at 17:00 UTC in the #accessibility Slack channel.

You can find out more about our Accessibility Working Groups as well as who you can contact if you’d like to get involved by looking at the Working Groups page.

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Trisha Salas 2:26 pm on April 27, 2017 Permalink |

    Week in WPa11y – April 24, 2017 

    Topics of Discussion

    • Settings API project
    • Gutenberg editor plugin
    • Browser support changes
    • Screen reader text PR
    • Tickets
    • New Widgets to test

    Settings API


    The current approach involves a redesign of the settings pages that is being discussed with some members of the design team.

    The next step is to process the thoughts @helen gave use on the CSS naming conventions. See: https://github.com/wpaccessibility/settings-api-enhanced/issues/6#issuecomment-294011891

    Gutenberg Editor Plugin


    @afercia recommended that we install and test the plugin. Instructions are here: https://github.com/WordPress/gutenberg/blob/master/CONTRIBUTING.md

    Note that it is not a conventional plugin so there are some specific steps to follow.

    @afercia has submitted a few issues based on the mockups but real (a11y) testing has yet to start.

    Changes in Browser support


    We discussed how the browser support changes would impact the screen reader text PR. @sami.keijonen said we should not use our time so much of finding things to remove at this point. But test new things like settings API and editor and make changes as needed.

    Screen reader text PR


    @ffood submitted a PR to update the screen reader class in the A11y Theme Patterns repo in Github.

    There was some discussion about updating the class in core as well.

    We agreed to merge the PR and also open a new issue in core to modernize the class. The changes in core should take into account end of support for IE 8-9-10


    Two tickets were closed this week.


    There are 2 new widgets to test

    Next meetings in Slack

    • Team meeting on Monday, May 1 at 17:00 UTC in the Slack #accessibility channel.
  • Corey McKrill 7:03 pm on April 14, 2017 Permalink  

    X-post: Nearby WordPress Events 

    Hello! Looking for feedback: https://make.wordpress.org/core/2017/04/14/nearby-wordpress-events/

  • Rian Rietveld 7:43 am on April 11, 2017 Permalink |  

    Week in WPa11y, April 5 -11 2017 

    Results Editor survey

    Editor Experience Survey Results

    105 respondents use a screen reader. 94 of those people feel the screen reader experience is sufficient or better. Other assistive technologies used by the respondents include: On-screen keyboards, alternative input devices like wands & sticks, voice recognition programs, screen enlargers, text to speech synthesizers, and braille embossers.

    Some quotes from the survey questions about accessibility issues with the Editor:

    You need to add more notifications for screen reader when somethings change on the page.

    I reached and pressed the Publish button and forgot that there are meta boxes after that. So then I had to fill up the category and tags then shift + tab to go back to Update the post.

    @mapk gave @afrecia a list of all the accessibility related answers for him to take a closer look at.

    WordCamp Torino

    Andrea: There were a variable number of 6-8 participants at the a11y table during the day. That’s a huge number for a11y during contributor days. Most of them were beginners so we’ve spent most of the time on introducing to accessibility. Run some keyboard accessibility testing, followed by an introduction to screen readers basic principles. In the last part of the day we’ve discussed all together #35497 – List tables: Post format links improvements.

    Dana Donato (@danuccia) joined the WPa11y meeting in Slack after joining the contributors day in Torino. She wants to help with tickets.

    Summary of the discussion during the Settings API meeting

    Notes by @afrecia:

    • use more settings sections to group fields that belong together (note: sections that group logically related controls should be fieldset elements)
    • GitHub flow: use distinct branches for design/layout changes and Settings API improvements
    • planning new GH issues to open
    • CSS naming conventions: the general issues here are trying to establish easy and maintainable patterns, taking into considerations the CSS Roadmap
    • keep selectors specificity as low as possible, avoid overqualified selectors
    • @helen suggested selectors should also provide a context:
      • “In an ideal world, you would have some baseline stuff for elements themselves, and then you scope upward to apply specific stuff based on context as needed”.
      • “The goal should be for people (devs) to not have to do anything involving class names or CSS the vast majority of the time.”
    • @helen will try to start a doc to dump thoughts on the best option we have for CSS naming
    • CSS classes to target stuff in JS: they should be separate from classes used for styling
    • CSS classes for state naming for JS (e.g. .is-active or .is-dismissible)


    Proposal for a new a11y-task ticket:  CSS generated content.

    We’ve discussed a few times the issue about font icons or other characters generated with CSS ::before and ::after. In some cases, they can be announced by screen readers. At the moment, the only way to make sure they’re not announced is using a <span aria-hidden="true"> element and target that with ::before and ::after rather than the main element. We should progressively introduce this as a best practice and also make people aware of the problem.

    Andrea will write the ticket and @trishasalas will do research on how CSS content is used in core.

    Note: a11y-task tickets are issues that should be addressed but we don’t have time and resources to tackle right now. Starting a discussion about them would be valuable though.

    Current work a11y team



    • #31476: Semantic elements for non-link links: /wp-admin/includes/widgets.php
    • Settings API plugin

    Both are also installed on our test server at wpaccess.org

    Interesting reads this week

    Next meetings in Slack

  • Rian Rietveld 8:03 am on April 4, 2017 Permalink |

    Week in WPa11y, March 29 – April 4 2017 

    New keyword a11y-task

    @afercia created a new tickets keyword a11y-task. These tickets aim to start a discussion and spread awareness about a11y issues that maybe can’t be resolved so soon. It’s also a way of being able to find accessibility tasks that we aren’t actively working on.

    Current work a11y team

    Gutenberg: as soon as the featured plugin is released we will test it.

    Tag Cloud adjustments (tag-cloud): #35566 #40187 #40186 #40184 #40138
    @samikeijonen and @davidakennedy

    Settings API plugin: @flixos90
    Felix released the plugin on GitHub: https://github.com/wpaccessibility/settings-api-enhanced which at the moment does exactly the same as the latest patches on #39441
    We can work on this plugin to iterate to the one-column layout we aim to have for admin forms.
    The advantages of developing in GitHub are:

    • Users can easily test the latest changes without us being required to do extra work.
    • Better diffs (because of individual commits) so that we can easier see what has changed over the last “patch”.
    • Easier collaboration (more people are familiar with git).

    Once we get to a first version of the one-column layout that is ready for testing, we should consider also adding the plugin to the wordpress.org plugin repo and formally announcing it as a feature project. This will allow us to hopefully get more voices on the honestly quite drastic changes and also to ask for user testing.

    Colour contrast in the Admin: @adamsoucie

    Required fields @rianrietveld

    Non-link links: @cheffheid

    Remove title attribute in the Admin: any volunteer

    To be worked on later

    Test requests (keyword a11y-feedback)


    Test the patches for

    • #35497: List tables: Post format links improvements
    • #31476: Semantic elements for non-link links: /wp-admin/includes/widgets.php

    Test the plugin Settings API Enhanced

    Interesting reads this week

    Next meetings in the Slack #accessibility channel

    • Team meetings are on Mondays at 17:00 UTC in the Slack #accessibility channel.
    • Trac ticket discussions (bug scrub) are on Mondays at 16:00 UTC
  • Rian Rietveld 10:52 am on March 21, 2017 Permalink  

    Accessibility discussions and work at WordCamp London 2017 

    At WordCamp London the a11y team worked during the contributors day and the two days after that on several issues. We where privileged to have Adrian Roselli joining us for two days to pluck his brain.

    Besides working on a11y tickets on trac we spend a large amount of time discussing and making decisions:

    Settings API: @karmatosed agreed to go for a one column design. @flixos90 will work on a patch and we will ask for the design team to help us. Summary of the Settings API discussion.

    Use of a code editor instead of the Text editor@grahamarmfield tested Code Mirror with Dragon NaturallySpeaking, and we discussed what the consequences would be of implementing this or any other code editor or syntax highlighter. Overall conclusion: A code editor is useful, but it should be implemented as an opt-in, not as default until there is an accessible version available. Summary of the Code Editor discussion.

    Gutenberg: The new block based editor. We researched and discussed the editor prototypes on Github and together with Adrian came with a list of recommendations to safeguard the accessibility. Issue at the Guterberg GitHub repo.

    Thanks for joining in the discussions and the work: @karmatosed @afercia @flixos90 @grahamarmfield @samikeijonen Adrian Roselli @hedgefield @abrightclearweb @moorscode and many others.

    And a huge thank you for the organisers of WordCamp London!


  • Rian Rietveld 9:53 am on February 20, 2017 Permalink  

    Ideas for the accessibility team at the Community Summit 2017 

    What can the accessibility team do on the  2017 WordPress Community Summit (CS) before WordCamp Europe in Paris?

    Here some ideas, comment below this post if you want to join the CS for the accessibility (a11y) team or if you have suggestions or remarks.

    Note: the deadline for submission is March 3, 2017.
    So we should make final decisions on the a11y team meeting in Slack on Februari 27.

    1. Proposed topics

    The editor

    @joedolson did a writeup on safeguarding the accessibility of the new editor. We have to make plans on how to provide our a11y expertise and resources to the editor team.

    The customizer

    The same counts for the customizer as for the new editor. Although this is a feature already is in core, it continuously needs our attentions and work.


    How to educate developers and designers more effectively. Ideas: better documentation, different approach for the handbook, accessibility talks, reviews, training, courses, a Day of A11y, etc…

    Get more developers and designers involved

    Set up a plan how to involve more coders and designers to work on a11y tickets in WordPress trac. And if people are joining, how to keep them involved for a longer time.

    Pattern library

    We need to review our GitHub repo a11y theme patterns. Is this the place we want to publish code and is the code still valid (some of it is 2 years old). Does the code validate for WordPress code standards, etc..

    The handbook

    After a few years of trying we just don’t seem to find the time and people to set this up. My proposal is to leave the concept of writing stuff ourselves but instead build a great list of resources and put WordPress specific issues in the core handbook.

    2. Representatives

    So far Andrea Fercia, David Kennedy (probably), Morten Rand Hendriksen, Rian Rietveld and Sami Keijonen (if he can find a sponsor) want to be at the CS.
    Anyone else wants to represent the a11y team?

    3. Help with the organisation of the event

    The CS organisers ask for one or two contributors who are willing to help with: posts, communication, travel assistance, finding sponsors, etc.

    As for the a11y team: the travel expenses of Andrea, David and Rian will be covered by their employers. It would be nice if we could find a sponsor for Sami.
    Who wants to volunteer or sponsor this Community Summit??

    Please put your ideas in the comments, we will discuss this on the accessibility team meeting in Slack February 27, 18:00 UTC.

  • Joe Dolson 9:02 am on February 17, 2017 Permalink
    Tags: core-editor, gutenberg   

    Revising the WordPress Editor: Gutenberg and Accessibility 

    One of the three top priorities for development in the next releases of WordPress is to enhance and modernize the editor. This is an important project to give users the ability to create rich and diverse content without requiring extensive knowledge of code. From an accessibility perspective, this is both an incredible opportunity to build a powerful and flexible experience for all users and an enormous risk that we could end up reducing the effectiveness of the editor for users with disabilities, or require them to use a 2nd-class editor without these enhanced editing capabilities.

    We in the WordPress accessibility community embrace the challenge of creating a great new experience, and want to assure the community that we are going to do everything we can to make sure that any new editor experience is as accessible as we can possibly make it.

    The most fundamental part of democratizing publishing is the ability to write and publish content. Without that feature, WordPress is not achieving its core mission. There are always challenges in creating content accessibly, but it is not an unachievable goal.

    It’s still early in the process, and there are many ideas floating around about how the new editing experience should be structured and how its interface should behave. The concerns for accessibility are universal, however. The new editor should consider accessibility to be a priority both in how content is created and in the nature of the content that is created.

    While the accessibility team wants the final implementation to be exceptional and accessible, we don’t want to limit the possibilities by imposing restrictions before they are necessary. However, there are some concepts that should be kept in mind early on that will significantly impact accessibility during development.

    Fundamentals of Accessibility to Consider

    1. Some common user interface interactions are extremely difficult to use non-visually. Drag and drop is an interaction that poses significant difficulties, since it is very difficult to disclose in audio how the dragged object and the potential targets are interacting. This doesn’t mean that the editor can’t use these interactions, but if they are used, there will need to be an alternative method to do the same task which is accessible.
    2. Fundamentally, all outputted code is organized in a linear manner. The experience of the content for keyboard users and for screen reader users will also always be linear. Ensuring that the content authoring process encourages a linear path will make the process easier for all users.
    3. Whenever possible, the user interface should encourage people to create semantically valid code; encouraging the use of correct headings (e.g., being content aware to know which headings are valid for a new content block); encouraging the addition of alt attributes, or defining table headings appropriately for tabular data.

    Updating the editor is a great opportunity to explore some of the requirements articulated in the Authoring Tool Accessibility Guidelines (ATAG). These requirements discuss how an editor should allow users to navigate the structure of their content and how the editor should encourage the creation of accessible content. A richer editor experience, with integrated prompts and formatting tools, has the potential to suggest best practices throughout the content authoring process. This would be an important growth step for WordPress.

    It should be self-evident that the new editor experience needs to meet the standards established for accessibility in WordPress core. The editor is the central experience of WordPress content creation, so planning ways to consider accessibility at every stage through the process is crucial to the success of the Editor project.

    Help develop the new editor

    If you’re interested in helping with the new Editor project, follow the development conversations in #core-editor and share your thoughts and ideas. You can also follow the GitHub project for the editor, where you can file tickets or follow specific issues like keyboard shortcuts, drag and drop, and the mobile interface. Weekly chats are in #core-editor, Wednesdays at 18:00 UTC.

  • Rian Rietveld 12:59 pm on February 13, 2017 Permalink

    Testing HTML5 type attributes in forms with different browsers and AT 

    How do the type attributes behave in HTML5 forms with assistive technology.
    On Github we set up a form with HTML5 type attributes..
    All with a proper label for/id relation, without CSS or supporting JavaScript, so we only tested use of the type field in the HTML.

    The conclusion is at the end of this post.

    The attributes we tested:

    • type=”text”
    • type=”search”
    • type=”tel”
    • type=”url”
    • type=”email”
    • type=”datetime”
    • type=”date”
    • type=”month”
    • type=”week”
    • type=”time”
    • type=”datetime-local”
    • type=”number”
    • type=”range”
    • type=”color”

    The list is taken from HTML5 forms input types on html5doctor.com.


    • Phillip Chalker: iPhone VoiceOver
    • Shaun Everiss: win7 pro, NVDA version 2016.4, firefox 51.1
    • Tina Tedesco: Windows 7, IE 11 and JAWS 17
    • Gabriela Nino de Rivera: MacOS Sierra 10.12.3, VoiceOver and keyboard only
    • John Sexton: Windows 7 64bit with IE11 & Supernova V14.
    • Priyanka Behera: Windos7 Ultimate, Firefox – 52 NVDA – 2016.4 and keyboard only on Mac Os Sierra Firefox – 51 and Chrome – 56
    • Riddhi Mehta:  Android Devices – Nexus S6, Moto G2
    • Afzal Multani:  Chrome & Firefox & Safari, keyboard only
    • Shah Rishi: Android Chrome Firefox Dell 7 3730 – Tab& Dell 8 3830 – Tab
    • Janki Moradiya: Iphone 6 – iOS 10.2.1, Chrome


    Phillip Chalker iPhone VoiceOver

    Eric Wright; Dragon: this is a presentation he did earlier.

    John Sexton: The video link below shows three passes of the form using Supernova. Each pass starts with the heading “The Form”.

    • The first pass I use only the tab key to go through each field.
    • The second pass I use only the cursor down key going through each field.
    • The final pass I use the tab key and enter values for each field. Note the range field I use the up/down cursor keys.

    Video John Sexton: abc4accessibility.com/html5test/


    First of all, there is a huge difference in support for the types between browsers and devices.


    Works on every tested device / AT


    HTML5 doctor describes the extra functionality for the search type. In the test no one noticed these extras
    The search options are disabled for VoiceOver, but it is announced as “search text field”.
    JAWS also announces the field as search.

    Gabriela: With VoiceOver, was able to reach all controls except for the “Cancel” button of the type search field. VoiceOver does not announce the “Cancel” button, so a blind person will miss it for sure. To actually access this button, I had to go inside the search field using control+opt+shift+down arrow. Once the focus is on the button, using the “enter” key or space bar won’t activate it. However, the user can erase the content of the search field using the combination of control+option+spacebar without having to use the cancel button.

    types “tel”, “url” and “email”

    The fields change the keyboard on mobile and in Safari gives an autofill option for tel an email.

    Validation is properly working in Firefox. It’s showing red focus in the, ‘Telephone’, ‘URL’, ‘Email’ and ‘Number’ fields but it’s not working in Chrome in both the devices (Nexus S6, Moto G2).
    Fields with autocomplete function worked marvellously with VoiceOver.

    Chrome on iPhone6: Telephone input field : validation for digit limit; URL input field : validation for http/https; Email input field : validation for @

    Date and time types

    They are only (mostly) properly supported in Chrome.
    On mobile in Safari date, month, time and daytime-local works, daytime not.
    For both Nexus and Moto, in Chrome Date and time picker is not displaying for ‘Date and Time’ field but datepicker is showing for ‘Local Date and Time’ field.
    Chrome on iPhone: Date and Time input field: open number keypad & valid only number not character.


    On the iPhone the “week” type is displayed very small and is not selectable in Chrome and Safari.
    Works in VoiceOver on desktop, but not on the iPhone
    On Android: Selected week is different in browsers. In Chrome it display like (Week 06,2017 ) and in Firefox it display like (2017-W06). In Firefox, when you click first time in week select menu “01” week is missing there.


    Text field on Safari & VoiceOver.
    Chrome on iPhone: Number input field : text box is very small. So, digit cutoff.


    Works on most devices and AT, although no visible feedback on the chosen value, but with screen readers you get the value read out load.
    In Nexus, Range field is not working properly during zoom out.
    Supernova: The range field was not editable by standard entering of numbers but instead required the cursor keys up/down to change the value.


    Supported in Desktop for Firefox and Chrome, but hard to use.
    Shaun on NVDA: when entering the colour box I was not able to do anything in there till I alt tabbed out then back in, after pressing the button to enter it NVDA just stopped and acted as if it was stuck in the button. After alt tabbing in and out I was able to change the values, different shades and colours.


    Type support varies with browsers and AT and seems better supported on mobile devices then on desktop.

    Safe to use are:

    • text
    • url
    • tel
    • e-mail

    As long as you don’t expect any type of input validation. The fields url, tel and email are nice to have for tablets and mobile, because they conveniently change the keyboard. Like numbers for tel, @ and .com for email. Some testers found it annoying that a telephone number only accepts numbers on mobile.

    Note: No one noticed the extra functionality added for type=search.
    Only Chrome fully supports date and type input on desktop, on mobile the support is somewhat better for most browsers.

    The color picker works on some browsers but is for AT very hard to use and understand.
    The only type that performed well was the range picker, although it did not give visible feedback on the chosen number.

    For Supernova: All fields accept the range filed were treated the same as standard text fields.

    Overall conclusion: don’t rely on HTML type attributes other than “text” for WordPress Admin.

    Follow up

    The data we have now is:

    As we have now enough data on how form fields behaves, we will use this data to improve the settings API.
    I hope our testers will join again to see how we can handle fieldsets, legends and punctuation in form labels, additional information in a field set, links in descriptions and complex constructions.
    This all to create a decent and also flexible API for form fields.

    Thanks all for testing!

  • Rian Rietveld 11:11 am on January 16, 2017 Permalink  

    Testing form functionality with different assistive technology 

    How do different types and implementations of form elements behave in HTML5 forms.


    On wpaccess.org/forms we set up a vanilla HTML5 form with different constructions of input and select fields. Also we took a code example of the settings page as is now in WordPress core, that has a combination of input fields put into a sentence. Especially we are interested in how an implicit and an explicit label with an input field works.

    We asked our test team and volunteers from Twitter to fill out the form elements and report how their assistive technology gives them feedback.

    Conclusion is at the end of this post.

    Explicit label:

    <label for="text-ext">First name</label>
    <input type="text" id="text-ext" name="first">

    Implicit label:

    <label>Middle name 
     <input type="text" name="middle">

    Implicit label with for/id relation:

    <label for="text-int">Last name 
     <input type="text" id="text-int" name="last">


      • Amanda Rush: Windows , FireFox 50.1.0, NVDA 2016:4
      • Mallory van Achterberg: Firefox 50 and IE 11 on Windows 7 (64-bit) with Dragon Pro 13.
      • Léonie Watson: Windows 10 desktop, Firefox 50.1 IE11 and Chrome 55, Jaws 18
      • Eric Wright: Windows laptop running Windows 10, Dragon 15 Professional, Chrome 55
      • Jeff Collis: Jaws 17, IE 11, Windows 7 desktop
      • John Sexton: Windows 7 (64bit) Desktop, Supernova 14 & NVDA 2016.4, IE 11
      • Gabriela Nino de Rivera: Macbook Pro, Safari 10.0.2 , VoiceOver
      • Shaun Everiss: NVDA 2016.4 firefox 50.2 win7 x86 sp1 pro toshiba sat pro c850 laptop.
      • Orlando Metcalf: keyboard testing on Windows 10
      • Priyanka Behera: keyboard testing on Chrome and FireFox
      • Sirisha Gubba: keyboard testing on FireFox and IE


    Supernova didn’t associate the forms grouping text with the form fields.
    NVDA did not read out the group label (legend) “5: I like the following movies”, when tabbing from the previous checkbox “I hate beer”. Where as it does read out the group label (legend) “4: I like the following beers”, when tabbing from the previous radio “Cycling”. However, NVDA does read out all labels when using the cursor keys.
    Also NVDA reads both the group label and first field label in one cursor down or tab action.

    Another difference is when tabbing Supernova reads all radio button items from each group where as NVDA only reads the first radio button from each group.

    Test 1: Input type=text with implicit and explicit label

    First: explicit label and input field linked with for/id relation
    Middle: implicit label
    Last: implicit label linked with for/id relation

    Dragon 13 Pro
    The first set of text boxes: saying “click edit” or “click type text” highlights all three text inputs. Saying “click first” moves focus to the First Name box. Saying “click last” moves focus to the Last Name box. Saying “click middle” moves focus to the Middle Name box.

    Dragon 15 Pro
    Role exposed to all three fields. For the “Middle” field, the word “middle” was the only part of the accessible name exposed to Dragon. For the other three fields, I could set focus by saying “click Name” or “click First” “click Last.” However saying “click name” only offers First Name and Last Name as options to choose from.

    NVDA and VoiceOver
    All input fields work and are pronounced well

    Supernova repeated form field labels on many of the fields, where NVDA doesn’t. For example Supernova reads out “Last name”, twice when tabbing from the previous field “Middle name”. Where Supernova only reads out “Middle name” once after tabbing from the previous field “First name”.

    Radio buttons:

    Favourite type of donut: explicit label and input field linked with for/id relation
    Favourite sport: implicit label

    Dragon 13 Pro
    Radios: saying “click radio” offers all radio buttons. Saying “click”plus the label name of the first 3 radios moves radio selection to that control. However saying “click” plus the label name of the second set (running/walking/cycling) does nothing; Dragon asks you to please say
    that again (meaning it does not recognise the command as valid).

    Dragon 15 Pro
    Could not set focus by speaking the name of the button, but could set focus and select a button by saying “click radio.”

    The other screenreader have no problems


    I like the following beers: explicit label and input field linked with for/id relation
    I like the following movies: implicit label

    Dragon 13 Pro
    Checkboxes: saying “click checkbox” offers all checkboxes. Saying “click” plus the label names of the beer options work as expected. It does not work with the Sound of Music/Zombie Apocalypse/Spongebob options.

    Dragon 15 Pro
    Could not set focus by speaking the name of the checkbox, but could set focus and select a button by saying “click checkbox.”

    Combined input fields in a sentence:

    The labels for the questions that consist of two fields (like “Remove content older than…” and “Break comments into pages with…”” do not read well because of the split over two fields. Perhaps a different field pattern would be more user-friendly?

    Usability remark
    Some elements appear to be conditional based on the selection criteria ( i.e. [ ] Remove content older than [30 ] days ).
    My initial reaction was the days value could not be changed with the checkbox not selected. This is not the case.

    Other screen readers
    Supernova, VoiceOver and NVDA are able to check, edit and select all fields within this section.

    Input field type=number

    Dragon 13 Pro
    None of the inputs type=numbers were focusable/available, except by using the “press tab” command to manually move keyboard focus to them. Once inside an input type=number, Dragon
    did not consider it an edit/dicatable field; the only way to get it to add anything is to preface my number with “Type” like “type 5”. I could also get it to “type T” and some other letters however not all letters worked. It seemed confused by the input type.

    This was both on IE and Firefox. I know Firefox understands input type=number. I can’t remember if IE 11 does, older versions did not and treated them as plain text inputs.

    Dragon 15 Pro
    Input 1: “Close comments for old post”.

    • Could set focus by saying “click remove” or “click checkbox.”
    • Couldn’t find a name or role to call to move focus from checkbox to the number input, but was able to move focus by saying “press tab.” On focus, commands for adjusting increments (press up or down arrow) were apparent.
    • After clearing the field, entering a number was difficult. I couldn’t say, “numeral 12” to enter a number, but I could enter a two digit number by sending keypresses. “Press 1” followed by “press 2.” This was non-intuitive, but quickly adjusting the increment was possible by saying “move up N” or “move down N.”

    According to NVDA feedback the selects for “remove content older than” and “break comments into pages”, NVDA reports these as “edit spin button”, (which I don’t think there’s anything that can be done about without a change to NVDA itself), and I can only arrow up and down through the selections.

    Using home/end to navigate to either the lowest or highest options in the selections does not work, and paging up and down through groups of options does not work either. This is probably not a big deal for most things, although it could probably get out of hand and cause some serious frustration if there are a lot of options to go through and the one you want is near the end. Maybe these should be comboboxes instead?

    Keyboard testing

    Different browsers have different ways of adding a visible focus, some like in IE are hard to see.


    By John Sexton: abc4accessibility.com/form-test Video screen capture of the test using both Supernova and NVDA, each showing the output with just cursor down, tabbing and then filling out the form. The video starts with Supernova using just the cursor down key starting from the heading “The test form” and then just the tab key, again from the same start point then lastly filling out the form via the keyboard only. It then repeats this in the same way for NVDA.


    • All form elements work with keyboard only, although the visibility of focus differed with each browser.
    • Explicit label with label/id relation works always
    • Implicit label works for Supernova, VoiceOver, JAWS and NVDA, but fields can’t be selected by name by Dragon (13 Pro and the latest version 15 Pro)
    • Implicit label with label/id relation works also for Dragon
    • Combining input fields in a sentence can confuse less savvy screen reader users
    • Input type=number does not work for Dragon (13 Pro and the latest version 15 Pro) and may be hard for NVDA.

    Follow up

  • Rian Rietveld 10:08 am on November 22, 2016 Permalink

    Summary meeting WPa11y team, November 21 2016 

    Attendees: @afrecia, @cheffheid, @joedolson, @sami.keijonen, @rianrietveld, @arush, @trishasalas and @antotrifiroconaccento.
    New to the meeting: Bonnie Boden (@bdd) and Terrence Gonsalves (@tegonsalves), welcome!

    Plans for WP 4.8

    Main focus: Settings API,  Uniform search and ticket 26601:

    Fixing accessibility and semantics of the settings API. Plan is to make a parallel version 2 to prevent plugins from breaking. There are a couple issues with the Settings API:

    • It outputs a table with labels and form controls in table cells
    • It doesn’t handle so well checkboxes, group of checkboxes, and radio buttons.
    • No fieldsets or legends.

    Related ticket: #38734 Dogfood the Settings API

    Uniform search, related ticket: #31818 Uniform Search Form Display/Experience

    Finish work in ticket #26601 Inappropriate content in headings on admin screens

    ATAG review

    ATAG means: Authoring Tool Accessibility Guidelines (ATAG) 2.0 and Joe Dolson reviewed how well the WordPress Admin does for those guidelines. He will write a report with the complete results later, here already a quick summary:

    1. Video/image modal does not announce selection to AT in visual editing.
    2. Video/image modal toolbar does not have valid labels (labels are on wrapper divs as aria-label, actually focusable element is empty)
    3. Method to associated video captions programmatically with media library object does not exist
    4. Animated Gif images should not autoplay in visual editor
    5. Alt attributes should be searchable in media library
    6. Should be possible to set custom style settings in editor
    7. Publishing content must not strip out added accessibility information, such as ARIA attributes
    8. Accessibility information should be mentioned in documentation: e.g., instructions on how to add an image should mention the need for alt attributes.
    9. There is no method to structure and publish accessible tables.
    10. There is no method to structure and publish accessible forms.
    11. Meta boxes order cannot be changed from the keyboard; drag and drop only

    And that will mean a lot of new tickets 🙂

    Next meeting will be Monday November 28 at 18:00 UTC

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
Skip to toolbar