WordPress.org

Make WordPress Accessible

Category: Working Group Toggle Comment Threads | Keyboard Shortcuts

  • Rian Rietveld 7:50 pm on May 27, 2015 Permalink |  

    Team chat Summary, May 25, 2015 

    Main focus of the chat: The List Table tickets

    Tickets that need work

    • #32253: List table: posts navigation links pointing to same page
      And related #32028: List table pagination: text improvements for screen readers
      32028 has a working and tested patch and needs to be committed to continue the work on 32253
    • #32255: List Table: media wp-list-table lacks table header content for column-icon and related. Action: @joedolson will think of a proper heading (<th> text) for the thumbnails
    • #32509: List table: media thumbnail and title links improvements
      We stick to the current patch of #32255 and don’t add the aria-hidden + tabindex=-1> How to deal with the link in the image will be solved in#32509

    Ticket that needs dev feedback

    #32170: List table: sortable column headers accessibility
    Summary for devs and committers:

    • we need to give feedback about the current tables ‘order by’ and ‘asc/desc order’, also in the initial view
    • we also need to make clear which columns are sortable and what will happen when users click on the table header links
    • hence, we need to get additional information about the sortable columns extending what is set in get_sortable_columns()
    • a new method print_table_description() prints a hidden table description, referenced as target for the table aria-describedby attribute

    Of course we’re totally open to discuss a different implementation and better practices, any thoughts more than welcome.

    Ticket that needs translation feedback

    #32399List table: Lists of items should inform users about the “current view” being displayed
    Needs translation feedback, how to properly translate custom post types in this case

    Ticket that needs UI feedback

    #32152: List table: Comments column accessibility improvements

    Tickets to be closed

    • #31965: Add screen-reader-text to list “filter” links
    • #31966: Add screen-reader-text to list “filter” links: Posts and Pages

    We decided on close and won’t fix because these issues will be solved when a relevant heading will be added, see ticket #32399

    Tickets ready for commit

    • #32150: List table: better indication for “no taxonomy”
    • #32254: List Table: avoid adjacent links pointing to the same resource
    • #32147: List table: headings for pagination and views links
    • High priority: #32028 List table pagination: text improvements for screen readers
    • #32509: List table: media thumbnail and title links improvements

    Other work:

    • High priority: #32495 WP Admin bar multi-level menu accessibility
      This has a working patch, ready to commit.
    • #31650: Missing H1 heading in the admin: @joedolson will work on this
    • #32494: Semantic elements for non-link links: Help and Screen Options

    New work:

    Customizer accessibility audit

    Related tickets are:

    • #32493: Customizer accessibility audit (tracking ticket)
    • #31336: Customizer: separate navigation from options UI for better UX by removing accordion behavior

    Select2

    Related ticket:
    #31696Better select, multi-select, and autocomplete/suggestion inputs in the admin.
    At the moment the a11y team has no capacity to work on an a11y audit of the Select2 library.
    Drupal has done some work on this already: https://www.drupal.org/node/2346973

     
  • Rian Rietveld 7:05 am on May 5, 2015 Permalink  

    Team chat Summary, May 4, 2015 

    Tickets

    We use the Accessibility Priorities for 4.3 as guideline on what to work on.

    List table issues:

    @afercia wrote extra tickets to complete the list of issues for the list table.

    • #32150 List table: better indication for “no taxonomy”
    • #32189 List table: make the sorting indicator arrow visible on focus (new)
    • #32187 List table: Pages displayed in “Excerpt View”
    • #32170 List table: sortable column headers accessibility
    • #32015 List table views: missing current class for “All” when logged in as Author

    Patches we come up with will be given to the wpa11y test team for review with assistive technology. Test result will be added as a reply with the ticket.

    We discussed how to address the “too many links” and “too much noise” issues in the list table.
    In the tables on edit.php and upload.php there are more than one link to edit:

    1. the post title
    2. “Edit” in the row-actions
    3. in upload.php also the attachment is a link to edit

    Our proposal:

    • remove the link “Edit” in the row-actions
    • test if the link on the attachment in upload.php can be hidden for screen readers by aria-hidden

    Heading structure Admin

    This is a complex problem, two tickets are addressing this:

    • #31650: Missing H1 headings in admin
    • #26601: Inappropriate content in headings on admin screens.

    @trishasalas will investigate how best to address this problem and add that to the according tickets, we all will join in the discussion if needed.

     

     

     

     
  • Joe Dolson 7:46 pm on April 27, 2015 Permalink
    Tags: 4.3-early, , priorities   

    Accessibility Priorities for 4.3 

    For the development of WordPress 4.3, we’ve got a handful of major issues we want to work on to create a smoother and more predictable experience for users with disabilities.

    Reconcile Heading hierarchy throughout admin & clean-up heading contents

    #31650: Missing H1 headings in admin
    #26601: Inappropriate content in headings on admin screens.

    Use Semantic elements for non-link links

    Tracking ticket: #26504
    Individual tickets (so far): #31487, #31476
    Related: #26550

    Reconcile search methods

    WordPress incorporates 5 different search interactions in the admin. For usability, accessibility, and maintenance reasons, this should be made more uniform. We’d like to see this reduced to two basic interactions.

    #31818 Uniform Search Form Display/Experience

    List table issues

    We gathered a ton of data on the List table navigation experience during 4.2, and those are being turned into tickets.

    #32028 List table pagination: text improvements for screen readers
    #32150 List table: better indication for “no taxonomy”
    #32152 List table: Comments column accessibility improvements
    #32147 List table: headings for pagination and views links
    #31654 List tables: Select All shouldn’t be a column header

    Color contrast issues in admin:

    #31548, #31713, #38599

    Improve editor experience:

    The editor is the single most frequently used part of most WordPress installations – and the experience with this interface should be more consistent.

    #29838: Editor focus order issues.

    Throughout the cycle, we’ll also be picking away at the dozens of other smaller tickets we want to fix, but these are large issues that will have a deep impact on WordPress, and will require a community effort to make progress.

     
  • Joe Dolson 6:09 pm on April 15, 2015 Permalink
    Tags: ajax, ARIA, javascript   

    Let WordPress Speak: New in WordPress 4.2 

    Written by Andrea Fercia & Joe Dolson

    WordPress 4.2 is shipping with a useful new JavaScript method: wp.a11y.speak(). This is a utility to make it easy for WordPress core to create consistent methods for providing live updates for JavaScript events to users of screen readers – with the side benefit that developers of plug-ins and themes can also make use of it either on the front or back end.

    Why.

    In modern web development, updating discrete regions of a screen with JavaScript is common. The use of AJAX responses in modern JavaScript-based User Interfaces allows web developers to create beautiful interfaces similar to Desktop applications that don’t require pages to reload or refresh.

    JavaScript can create great usability improvements for most users – but when content is updated dynamically, it has the potential to introduce accessibility issues. This is one of the steps you can take to handle that problem.

    What.

    When a portion of a page is updated with JavaScript, the update is usually highlighted with animation and bright colors, and is easy to see. But if you don’t have the ability to see the screen, you don’t know this has happened, unless the updated region is marked as an ARIA-live region.

    If this isn’t marked, there’s no notification for screen readers. But it’s also possible that all the region content will be announced after an update, if the ARIA live region is too large. You want to provide users with just a simple, concise message.

    How.

    That’s what wp.a11y.speak() is meant for. It’s a simple tool that creates and appends an ARIA live notifications area to the <body> element where developers can dispatch text messages. Assistive technologies will automatically announce any text change in this area. This ARIA live region has an ARIA role of “status” so it has an implicit aria-live value of polite and an implicit aria-atomic value of true.

    This means assistive technologies will notify users of updates but generally do not interrupt the current task, and updates take low priority. If you’re creating an application with higher priority updates (such as a notification that their current session is about to expire, for example), then you’ll want to create your own method with an aria-live value of assertive.

    How do I use this?

    • enqueue ‘wp-a11y’ from your plugin or theme or set it as a dependency of the script that generates updates
    • on DOM ready, pass a translatable string to wp.a11y.speak(): wp.a11y.speak( mystring );
    
    add_action( 'wp_enqueue_scripts', 'yourprefix_a11y' );
    function yourprefix_a11y() {
    	wp_enqueue_script( 'wp-a11y' );
    }
    
    

    or

    
    add_action( 'wp_enqueue_scripts', 'yourprefix_ajax' );
    function yourprefix_ajax() {
    	wp_enqueue_script( 'yourprefix.ajax', get_template_directory_uri() . '/js/ajax.js', array( 'wp-a11y' ) );
    }
    
    

    For an implementation example, take a look at wp-admin/js/updates.js. An important note: wp.a11y.speak() is only available after DOM ready, so be sure not to call it earlier!

    If you’re intending to use this in your theme, you should take note that your theme should also support the core class .screen-reader-text, which is used in the inserted content. Read more about screen reader text.

    References and further reading

     
  • Rian Rietveld 6:48 pm on April 14, 2015 Permalink
    Tags:   

    Usertest: Link texts in the page with all posts (edit.php) 

    Question for the test team

    We would like you to investigate the links and link texts on wp-admin/edit.php page and suggest better solutions for the link texts, how to make them understandable and unique, without overloading a screen reader user with a huge amount of extra text. Hidden text suggestions (screen reader only) are welcome and also visual text suggestions.
    We hope to make this list of posts (and pages) understandable for everyone.

    Test results

    Geof Collis

    Sort of like they’ve done in the media section I’d like to be able to select the posts/pages in a list with just a link and checkbox for bulk edit an nothing else.
    I’d also like a heading at the beginning.

    Tobias Clemens Häcker

    Tested with: Windows7, Chrome Browser, ChromeVox

    Analysis

    The link texts for the link itself the control box and the sublinks (edit, quickedit, trash and view) are well-done. The voice output is clear. However author, category and comments are only announced as link.

    Suggestion

    Links to author, categories and comments should add the type. Announcing “author mwa”, “category uncategorized” and “zero comments” instead of just “mwa”, “uncategorized” and “zero”.

    YouTube demo

    Jeffrey de Wit

    NVDA (default settings, so includes reading out title) goes entirely nuts on this stuff. I’ll see if I can get a recording of it. Something that may be useful to change are the All/Published/Drafts/Trash links. These could probably use some screen reader text.

    Something like this (Maybe use List instead of Display? Not sure):

    [Display] All (13) [posts] / [Display only] Published (10) [posts] / [Display only post] Drafts (3) / [Display posts in] Trash (1)

    Right now it gets read out by NVDA as:
    “All 13 link”, “Published 10 link”, “Drafts 3 link”, “Trash 1 link”.

    On a similar note, the column headers for sorting could probably use the same treatment. It just announces the link (“Title link”, “Comments link”, “Date link”).

    Should probably be something like:

    “[Sort ascending/descending by] Title link”
    “[Sort ascending/descending by pending] Comments link”
    “[Sort ascending/descending by] Date link”

    Ascending is the “default” link for title and comments, that is, when you get on the page and you trigger one of these sort links the order will be ascending (A->Z, or 0->x).

    For Date the default is descending, which means the newest comment will appear on top.

    Neither the current sort order (if any), nor what the sort order will be when the link is used is conveyed by the screen reader. The suggested text in the list above would take care of what the link will do, but not what sort order is currently active.

    I’m worried that adding additional text for what sort order is active may be too much, nor do I know of an elegant way to word what the current sort order is. Or even where the most appropriate place to put it is.

    NB. NVDA + Chrome doesn’t announce the Comments header at all. Could possibly be because the screen reader text span is wrapped in two other spans.
    Seems the craziness only happens with Chrome and NVDA. Firefox is a bit more sane.

    Demo in Firefox + NVDA:

    Demo in Chrome + NVDA:

    John Sexton

    I’ve done a quick check with Supernova V14 on a Win7 PC with IE11 and have the following comments:

    When tabbing through links with supernova on all posts (starting from the h2) you get:

    “Add New”, “All 13″, “Published 10″, “Drafts 3″, “Trash 1″, “Forms mode Search Posts blankline edit”, “Search Posts button”,

    “Forms mode select bulk action Bulk Actions pull down list box”, “Apply button”, “Forms mode Filter by date All dates pull down list box”, “Forms mode Filter by category All categories pull down list box”, “Filter button”,

    “visited link”, “link”, “Forms mode select page 1 edit”, “link”, “link”, “List View link”, “Excerpt View link”,

    “table 14 rows by 7 columns selectall unchecked checkbox”, “title link”, “comments link”, “date link”,

    “select no title unchecked checkbox”, “no title link”, “mwa link”, “uncategorized link”, “0 link”

    Note: as the above is just using the tab navigation it skips over the empty tags and date columns. However, if using the Supernova table navigation controls the empty tags cell is just read out as “column 5 row 2″. This is because by default Supernova doesn’t read all punctuation.

    Pagination links:

    the symbols are not often read out by default and their purpose may not be immediately obvious.

    add ” First”, ” Back”, ” Next” & ” Last” as screen reader text inside the link text.

    alternatively add ” First Page”, ” Previous Page”, ” Next Page” & ” Last Page” as screen reader text inside the link text.

    or ” Page 1″, ” Page n”, ” Page n” & Page n” where “n” is the page number that the link will go to.

    Personally I prefer the first option as is short and to the point.

    Data links in table:

    It may be an idea to add ” tag” & “0 pending of 1 comments” (where 0 are the number of pending comments and 1 is the total comments), as screen reader text inside the link text after the displayed value.

    It would also make it more usable if the pending & comments are shown as 0/1 or 0of1 or just add another column for pending just before the comments column. This way both values are visible without the need for title attributes.

    For when there are no tags, adding ” no tags” as screen reader text inside the link after the – symbol may help for cases when the – is not read out by default.

    You could add “author ” as screen reader text inside the link text before the authors name.

    It may be an idea to add “Edit ” to the link text as screen reader text before the title link text.

    The “Edit | Quick Edit | Trash | View” menu is not accessible without a mouse in list view. However, in excerpt view, the following works from a keyboard.

    The “Edit | Quick Edit | Trash | View” links are not immediately obvious, to gain access with Supernova, first you have to switch to excerpt view then you have to use cursor navigation to find the  post excerpt text and press space while over this text.

    Options could be to add a show/hide link for these four links this can have the same action of as you show one it hides previously shown menus. This way there’s only one “Edit | Quick Edit | Trash | View” menu visible at any one time.

    When these links are visible you can tab through them. It may be an idea to add the post title as screen reader text to the end of each of the four menu links, so it reads “Edit post title | Quick Edit post title | Trash post title | view post title” (where post title is the name of the post that is being acted upon.

    It is probably worth considering removing either the “Edit |” link or the title edit link. As these are duplicated links one following the other. Perhaps while in excerpt view, the title link could be used to show/hide the menu links instead of performing the Edit link.

    Another interesting thing I noticed is when using Supernova’s list links function while in excerpt view with one “Edit | Quick Edit | Trash | View” menu visible you get:

    • The pagination links are shown with the title text “Go to the first page «”, “Go to the previous page ‹”, “Go to the next page ›”, “Go to the last page »”.
    • The comments link has “c o m m e n t s”, would be better as “Comments”
    • The post titles have “Edit ” preceding the title text.
    • The post comment fields have “0 pending 1″ (where 0 are the number of pending comments and 1 are the total comments).
    • The menu “Edit | Quick Edit | Trash | View” is only listed once for the currently visible menu and the links are listed as:
    • Edit this item “Edit” (where “Edit” is the actual link text and the first part is the title text).
    • Edit this item inline “Quick Edit” (where “Quick Edit” is the actual link text and the first part is the title text).
    • Move this item to the trash “Trash”, (where “Trash” is the actual link text and the first part is the title text).
    • View [post title] (where [post title] is the post title to view.

     

    Gabriela

    I used VoiceOver and Safari.

    Comments:

    All/Published/Draft/Trash links

    I agreed with Jeffrey’s idea of adding a “post” word to links to provide a better context to the user. In my opinion, the context for this group of links for a sighted user is more than clear, so maybe only adding this information for the screen reader should be better.

    Column headers for sorting

    I agreed with Jeffrey’s suggestion to add extra info to let the user know the sort ascending/descending order. To tell you the truth, if Jeffrey did not mentioned that those links are to change the sorting order, they had gone unnoticed for me. I suggest to show by default the black triangle instead of only making it visible when the user does a mouse over or a click on the object.

    First, previous, next, last page links

    The title for these links already contain the information describing the action of each one of the links, is a shame that that browsers don’t announce it.
    So to make them accessible, I see two options:

    1. Add the information in a span same technique than the one used for list view and excerpt view;
    2. Converting the symbols and background color to images and adding the information with the ALT attribute.
    Edit | Quick Edit | Trash | View links

    In my case, it was not difficult to access these links only using the TAB key. I tried on list view and excerpt view.

    Since edit/quick/trash/view are all in the same cell as the title of the post I think the user gets a good idea that those actions apply to the current post.

    My only concern with these links is that they appear only when the post title gets the focus. VoiceOver and NDVA let the user to open a window dialog containing a list with all links available on the page. But these links won’t appear on the list because the title post don’t have the focus on. So the user won’t be able to use these links from the link list window.

    Tags information

    I would suggest to add a text for the screen reader so instead of listening to a “end dash” the user will hear something like “not tags for this post”.

    Data table

    The table used for the posts is a data table type. But not all the data cells are associated with their corresponding head (th) cells. This could create confusion for the screen readers and affect the way the cells are read to the user.

    Shaun Everiss,

    NVDA latest version, firefox and internet explorer latest builds and windows7.

    I have looked at the links having the title of the posts and the date on when it was posted works for me thats how it has been in 4.1 what is the issue of keeping it that way.

    Reagan Lynch

    Test Environment: Windows 7 64 bit, Internet Explorer 11, JAWS 16

    I did this test on just the main listing you first go to when you click on All Posts. This focus is on links and what feedback you get with a screen reader.

    After the bulk action combo box you get the unlabled links.

    The first is links that I think are for navigating back and forward among the posts. In JAWS 16 these are not labled. I know that one is two left double angle brackets, but that is because I did a jaws command (insert+up arrow twice quickly) The next thing I see as I arrow down is a unlabled link that I cannot even determine because nothing is labled and JAWS cannot read the character that is there.

    These links are repeated in opposite after the edit field to select the page. For these unlabled links it would be nice to here prev and next for the links that move you page to page, and maybe first page and last page for the links that go to the first and last page. Just labeling these page nav links would make the all posts/pages pages more usable with a screen reder.

    In the table of posts I don’t really know what you can do to make the links that are numbers that take you to comments more accessible. Since we now have the wp speak function how hard would it be to use that function to tell a screen reader when it sees that link to report 1 comments or 0 comments. I know if you use I think a title attribute you can read that with a say line command twice quickly, but screen reader users are not really going to take the extra time to issue that command. Using WP speak or something else might be the best solution especially if you don’t want to impact the sighted experience.

    Sebastien Massy

    Use of title attribute

    Not all browser/screen-reader combinations will convey the title attribute to the user. For instance, Firefox/Orca/Linux conveys the
    title attribute, but Chrome/ChromeVox/Linux does not. What this means is that the user might wind up having or not having the information
    depending on his A-T choice. (Example, if there are comments pending moderation for a post, Firefox/Orca might say “7 pending” while Chrome/ChromeVox would just say
    “7”.)

    The screen-reader-text class

    In Firefox/Orca/Linux all text belonging to this class winds up being stretched out to one letter per line of the virtual buffer, presumably
    in an attempt to represent the text as it would appear if formatted according to the class. The end result is that using down or up arrow to
    scroll rapidly through a list of posts (or any other list employing this class) is at best tedious and at worst impossible. Chrome/ChromeVox,
    which tends to promote structural navigation over layout reproduction does not exhibit this problem. I would be curious to hear whether other
    firefox users on other platforms are experiencing this issue.

    Not all information is displayed

    Using either browsers, I ran into the simple fact that not all information would be spoken reliably. In particular, such things as
    publication dates and attached taxonomies were not always spoken. For example, in Chrome/ChromeVox, I found that navigating forward would
    speak the quick action links but omit the information mentioned, whilst navigating backwards would speak the whole information but the action
    links were not there. I am wondering whether this has to do with the fact that the action links appear on hover, i.e when focused (for us):
    could it be that they mask some information when they appear?

    All in all, I found that neither browser/A-T combination provided a good experience when attempting to scroll rapidly through a list of posts.

    Tina Tedesco

    Jaws 15
    After arrowing down past the #13 it said “link left double bracket.” It did not indicate the type of link. Arrowed down again and it just said “link” no type of link or no dataspoken. Arrowed after #2 after select page and there is a blank link; arrowed down again and another blank link.
    Some sort of data link or labeled tags need to be added.

    The table was very confusing for someone using a screen reader. To much text is being spoken in each column.
    As a user of a screen reader, I was able to go into table navigation mode which enabled me to navigate through the table. However, even using that, it was confusing.

    Amy Li

    I have some suggestions and they may not related to Accessibility but usuability issues. Hope it helps. Please see below:

    Too much links and caused confusion
    Remove non-important information on default, remove “Author”, “Categories”, “Tag” and “Date” since those items are in Filter list.
    Add icon-style for Tagging, add alt-text for tagging and other icons
    Links button need be less, combining View with Edit. Quick Edit should be default, adding “More” to extend functions like “Edit”
    “Trash” is better to be selectable in the front so that admin can bulk-select and delete together, instead of one by one clicking.

    Mocked screenshot in default page with removed extra links:Mocked screenshot in default page with removed extra links

    Issues and actions:

    Overall impression

    • For screen reader users this page is overwhelmed with links and hard to get an overview of.
    • There is a need for a quick overview with links to all posts (or pages).
    • A lot more screen reader text should be added to explain what the links are about.

    Page navigation

    Page navigation

    • The page navigation should have a heading to make clear what it is about: ticket @afercia
    • The page navigation is missing decent screen reader labeling: ticket @afercia
    • The previous links are still links on the first page , and the next links on the last page. They should not be links. Also the colour contrast of the >> and > is to low for these “inactive” links.  Ticket @rianrietveld

    Post filter

    post filter

    The links like Published, Sticky etc. are missing decent screen reader labeling: ticket @Cheffheid #31965 and #31966

    Comments

    Comments

    The amount of pending comments are included in the title attribute of the comments link and only visible on hovering, this is not clear for screen reader users but also not clear for sighted users. Ticket @rianrietveld

    Tags

    Tags

    A “—” ( “end dash”) for no tags needs screen reader labeling or a better explanation.  Ticket @rianrietveld

    Post link and row-actions

    Below the link for the post title there are action like: Edit, Quick Edit, Trash and View.

    • The link to the post title and the Edit link are double.
    • Some screen reader have difficulties entering the row-actions, we should review the way this is done now.
    • The | seperator could be included into the css or made invisible for screen readers by ARIA
    • Remove the explaining text out of the title attribute and add screen reader text
    • The quick edit link should be a button is now href=”#”

    Screen reader text needs to reset word-wrap

    In Firefox/Orca/Linux all text belonging to this class winds up being stretched out to one letter per line of the virtual buffer. This is due to the word-wrap: break-word; applied on an element Ticket @afrecia

    No feedback on sort order of a column

    • The way a column is sorted should be added for screen readers
    • The only way you can see if a column is sortable is by the colour of the table header text and by hovering over the link

    To consider

    How to decrease the number of links and make a post quicker selectable for a screen reader user

    One more thing to consider

    Edit by Andrea. We missed the format links: when a post has a specific format set, a small icon is prepended to the post title, see screenshot:
    video post format
    the image is linked to a screen with all the post belonging to that post format. Read out by screen readers as: “video link video”.

     
  • Rian Rietveld 7:59 pm on March 30, 2015 Permalink
    Tags:   

    Usertest: The search functions in the Admin 

    Question for the test team

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

    Test on WordPress 4.2-alpha

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

    Experiment:

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

    Can you tell us if:

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

    Shaun Everiss

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

    Gabriella

    Tools: Safari + VoiceOver

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

    Media

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

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

    Themes

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

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

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

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

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

    Amy Li

    Posts > All posts

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

    Posts->Categories

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

    Appearance->Themes

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

    Plugins > Installed Plugins

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

    Plugins > Add New

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

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

    Users > All users

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

    Resize window:

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

    Tina Tedesco

    I use JAWS 15.

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

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

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

    John Sexton

    Test on Win7 64bit, IE11 & Supernova14

    Search in categories:

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

    Search in tags:

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

    Search in media library

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

    Search on all pages

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

    Search on themes

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

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

    Geof Collis,

    Tools: IE 11, JAWS 14.5

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

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

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

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

    Tags and categories

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

    Still the issue of previous search term in edit box.

    Themes

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

    Plugins add new, all criteria

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

    Add new

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

    Add media

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

    Summary:

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

    Discussions in Slack about the results:

    Slack log

    Now there are 5 different ways for a search:

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

    We recommend only 2 forms of search:

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

    Actions:

    • Open ticket for the missing label for the  typeselector select field – @rianrietveld
    • Open ticket on a unified search form display: 2 types – @cheffheid
     
    • Rian Rietveld 6:39 am on March 31, 2015 Permalink | Log in to Reply

      Some extra remarks:
      It seemed there already was a ticket for the missing label for the typeselector select field : #31795
      Searching for posts with no title is possible if you ‘enter no title and not ‘(no title)’ in the search field

    • Jeff de Wit 2:56 pm on March 31, 2015 Permalink | Log in to Reply

      Here’s the ticket proposing the unified search form display changes: #31818 – open to thoughts from all.

  • Rian Rietveld 4:18 pm on March 26, 2015 Permalink
    Tags:   

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

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

    Question

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

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

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

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

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

    Results so far:

    Bram Duvigneau

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

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

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

    Susan R Grossman

    On JAWS

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

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

    Geof Collis

    On JAWS 14.5 IE11

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

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

    Michelle DeYoung

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

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

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

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

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

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

    Anna Natorilla,

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

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

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

    Gabriela Nino de Rivera Torres

    Tools: Safari 8.0.4 + VoiceOver

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

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

    Points not so good:

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

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

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

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

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

    Tina Tedesco

    Using JAWS 15

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

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

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

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

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

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

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

    Hope this is not too confusing.

    Malgorzata Mlynarczyk

    Tested with NVDA in Firefox

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

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

    Suggestion

    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.

    Summary:

    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.

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel