Send to the test team March 26, 2015
For WordPress 4.2-beta2
We would like you to test the “Press This” categories selection in
You can access Press This directly in WordPress, at: /wp-admin/press-this.php
After the editor, you will find a “Post Options” area where you can set the Post format, Categories and Tags.
About Categories, it’s made with a list of DIV elements with role=checkbox, for several reasons developers choose to implement them this way so switching back to native checkboxes is not an option 🙂
You should be able to check them as you usually do with native checkboxes, by the way screen readers won’t automatically switch to “forms mode”.
To force the switch we added role=application to the list container.
This has pros and cons and, generally, it’s recommended to use role=application sparingly and wisely.
See for example this post by Mr. Zehe:
Since any recommendation and best practice should be always tested in a real world experience, we would like you to test what’s best for you.
- with no role=application, users will have to manually switch to “forms mode”
- with role=application, the switch should automatically happen but you will lose the native behaviour and other things like the number of items in the list being automatically announced, not mentioning arrowing won’t work.
Results so far:
After a quick look, I come to the following conclusions:
- NVDA shows an application region and you need to press space bar/enter to interact with it. Please note this is not necessary if the user just navigates by pressing tab
- The application region contains just a bunch of elements that behave like checkboxes
Given the fact that this is not a real application, but just a list of checkboxes, I recommend against using role=”application” here.
By putting the checkboxes in an <ul> or an element that has the corresponding aria role (list from the top of my head), you wil just make it clear that these checkboxes belong together. As a bonus I would suggest using the new wp.a11y.speak to announce the number of results when a user types in the search field, e.g.: “4 categories displayed” or similar.
Susan R Grossman
This doesn’t work for me even when using tab/shift/tab.
It skips some of the choices when trying to tab/arrow/space/navigate in any method through them. Does every other “radio button”.
On JAWS 14.5 IE11
I dont like it one bit and it should not be implemented, it goes against everything I know about radio buttons and checkboxes.
Not sure if this is relevant but when ever I see a form I go through the whole form without going into forms mode to give my self an idea what it looks like, then I will fill in the first edit box/ button etc, go out of forms mode go to the next field fill it in then go out of forms mode again, I do this for all forms because I dont trust them to cycle properly.
FF/NVDA/Win7: Once the screen readers announces “application” and throws me into forms mode, the next tab takes me back to the Category The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. tab and “Back to Post Options Button” is voiced. Then I have to tab through the other items in the tab order to access the categories I would like to check/not check.
Each category item name is voiced with checkbox not checked.
IE/JAWS/Win7: Once the screen readers announces “application” and throws me into forms mode, the next tab takes me back to the Category tab and “Back to Post Options Button” is voiced. Then I have to tab through the other items in the tab order to access the categories I would like to check/not check.
Each category item name is voiced with checkbox not checked, to check press spacebar.
Chrome/ChromeVox/Win7: Once the screen readers announces “application” and throws me into forms mode, the next tab takes me back to the Category tab and “Back to Post Options Button” is voiced. Then I have to tab through the other items in the tab order to access the categories I would like to check/not check.
Each category item name is voiced with checkbox not checked item.
Keyboard only: Another accessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) impact would be for keyboard users. Tabbing to the category item highlights it but they have no idea that the item is selected and operational via a checkbox. If you do not want the checkbox displayed then add some verbiage to let visual keyboard users know how and what they are supposed to do so they don’t have to guess that if they use a spacebar that it will check the category item.
I would recommend not using the role=”application” in this case, and focus on getting this to work for screen reader users and keyboard only users. Perhaps a tab/accordian widget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user.. Here is a link to an example, but it also is using role=”application” which impacts access via different screen readers, so in this example I would remove it as well, but it still shows a different widget option.
Example 37 – Tab Panel: Accordian using ARIA CSS selectors
I think the role=”application” will only frustrate users more and impact how they access those content items.
Trunk: This custom checkbox implementation allows the user to activate the checkbox with spacebar key only. The user has no problem checking the custom checkboxes. If the user reads the checkbox via virtual cursor mode and they press the enter key to select a checkbox, the screen reader will tell the users to press the spacebar key to check or uncheck a checkbox. Once the users check or uncheck a checkbox with the spacebar key, the user was switched to forms mode.
It is a fact that switching to forms mode on the checkboxes will cause the screen reader to not announce the number of items in the list. The user has to use virtual cursor mode to hear the list items numbering and levels.
Nightly: This native checkbox implementation allows the users to activates the checkbox with both the spacebar and enter key on via virtual cursor or forms mode. The users have no problem checking the forms control whether they are in forms mode or virtual cursor mode.
Gabriela Nino de Rivera Torres
Tools: Safari 8.0.4 + VoiceOver
I found very easy moving between the categories list. It’s a great improvement compared with the old situation. In the old version, first I need to go inside the group to interact with the items inside. When moving from one category to the next VoiceOver was speaking twice each item, one for the button ratio and the second for the text inside the button ratio, which was very annoying.
In the new version I don’t need to go inside the group to interact with its items. Selecting the ratio buttons it is also very easy to do.
Points not so good:
I noticed that when adding a new category, the user is not notified of the action. There is not a message confirmation to tell the user if the category was successfully created.
Also, when adding a new category, the category is selected by default (the ratio button is selected). The user won’t not know until she moves from one category to the next.
The categories are added at the beginning of the list under their parent category. It is funny, I was expecting to be added at the end instead. This has nothing to do with accessibility issues. 😀
When moving in the list of categories, there is nothing that announce the user if a category is a parent or a children. This information is being transmitted only visually.
For some reason all the sub-categories inside the testing category are announced by VoiceOver like “list of X items”. I added categories in other parent categories, but this behaviour only happened with the testing parent category. I looked in the code, I could not find any differences between the parent categories. So, I’m very puzzled about this.
Using JAWS 15
Not sure I did this correctly but I concentrated on the list starting whith the checkboxes. I was able to check and uncheck with any problems.
When arrowing down it said, “Entering Categories Application.” Then arrowed down and came to accessibility, it indicated “list of 6 items.” When I arrowed passed accessibility it indicated “list of 4 items nesting level 1.” When I got to the end of that list it indicated “list end nesting level 1.)
I heard no more beginning or ending of levels until I arrowed passed JDFh checkbox. it indicated “list of 2 items nesting level 1.” When I got to the end of the list it said “end of list nesting level 1.”
I arrowed to Testing (did not mention a new listing) and when I arrowed again it said “list of 5 items nesting level 1 as well as end of list nesting level1. ”
Came to Uncategorized (nothing to indicate any listing before the word) arrowed down once indicating “list of 2 items nesting level 1.” Once I arrowed past the 2 items it said “list end nesting level 1.”
At the end of this list it said “Categories applications end.”
Should there have been some sort of message for all listings?
Hope this is not too confusing.
Tested with NVDA in Firefox
As I’ve said before I’m not a native screen reader user, so I’m probably not the best person to test it (it would be better to test it with actual screen reader users). However, I personally prefer the solution with role=”application”. First of all, screen readers are expected to switch to application mode when in the form, so this is an expected behaviour. Once in the form, the users are used to navigate using Tab key, rather than by moving the virtual cursor using the arrow keys, so I don’t think this is a problem. The fake checkboxes work well – the change in state (checked / unchecked) and the ‘checkbox’ label are announced to the user. And although the screen reader doesn’t inform the user how many items the list contains, I don’t think this is particularly important here, and sighted users don’t know it either (unless they decide to manually count them…).