WordPress.org

Ready to get started?Download WordPress

Make WordPress Accessible

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

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

    Admin plugin pages and Shiny Updates: Accessibility user test result 

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

    Testers:

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

    Test:

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

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

    Test results

    Kim van Iersel

    Jaws 15.

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

    Gabriela Nino de Rivera:

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

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

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

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

    Plugin categories

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

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

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

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

    Plugin installed

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

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

    Install via more details

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

    Error message in another language

    Tina Tedesco

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

    Malgorzata Mlynarczyk

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

    Greg Wocher

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

    Petra de Jong

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

    Jeff de Wit

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

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

    Comment by Rian

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

    Summary a11y test plugin pages and Shiny Updates

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

    Search plugin:

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

    Adding a plugin:

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

    Updating a plugin:

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

    Comment by Andrea

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

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

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

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

    Additional notes

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

    Missing label associations throughout network admin: Accessibility user test result 

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

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

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

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

    Testers:

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

    Testresults:

    Anna

    quick edit label

    edit site user tab label

     

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

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

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

    Malgorzata Mlynarczyk

    My sites page:

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

    Add site page

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

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

    Add new user page

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

    Settings page

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

       

    Jeff de Wit

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

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

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

     

    Michelle

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

     

    Conclusion:

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

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

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

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

    We asked the testers:

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

    Testers:

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

    Testresults:

    Kim:

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

    Geof:

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

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

    Suzanne:

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

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

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

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

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

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

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

    Conclusions:

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

    Anna

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

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

    Tina:

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

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

    Greg:

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

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

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

    Michelle DeYoung

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

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

    Suggested:

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

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

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

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

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

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

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

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

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

    Suggested:

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

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

    Screen readers will voice it as:

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

     

    TinyMCE documentation:

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

    Bram Duvigneau

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

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

    Chandra Sekar

    Header row:

    Expected Tab order/sequence for the All post Table

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

    Current Tab order

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

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

    Summary testresults

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

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

    • Allow screen reader users to know that the Bulk Action selections and Filter selections can be applied to the items they select in the table.
    • The Select All heading (label for checkbox) is being announced by the screen readers at the start of the first data cell in each row of the table. This could possibly be confusing for screen reader users to hear “Select All” and then Select…checkbox.
    • The checkbutton was reason for much confusion
    • The comments are read out as 0, 1 or 2, adding the word Comment to that would make it clearer
    • The double link to edit post is confusing (also for sighted users)
    • Tab key and arrow keys don’t match up, arrow key skips the quick edit links unless you are in the cell
    • Some testers also added remarks about the colour contrast, we will open a new ticket on that.
     
  • Joseph Karr O'Connor 8:21 am on February 16, 2015 Permalink
    Tags: , ,   

    Accessibility Team Update: February 11, 2015 

    Testing

    We had a report by Rian Rietveld on testing results. Things are going very well. Rian said: “I’m getting test results back on the tab order of the post table, it seems to work ok, but they found a ton of other problems, I have to check the current tickets and open new if necessary.”

    Pattern Library

    David Kennedy told us that the repos are set up for contributions to the theme pattern library. See the Accessible Theme Pattern Library Update for February for more info.

    Core Discussion

    Andrea Fercia reported on a discussion he had with the Core team. He asked about menu bar admin focus and non-link links (28599 and 26504). Joe Dolson said “the link/button question really requires specific cases; I’m not sure how we could approach giving any kind of global comments on the topic.” Andrea said that he also updated the Core team about the first testing round on customizer theme switcher.

    Theme Checking

    Joe Dolson updated us on the state of checking themes requesting the accessible-ready tag.”We’re now up to 29 live themes carrying the accessibility-ready tag which have been tested and passed. There’s one outstanding theme live that does not pass (_tk); it’s undergoing the review process now, and will either be suspended or updated soon.I’ve got two pending theme reviews to do, and know of at least 1 theme that’s currently approved and waiting to go live.”
    Joe has also trained two of the theme review team admins on reviewing for accessibility. Additionally Joe has shifted support for landmark roles into a required feature for accessibility-ready themes, rather than recommended.

    Landmarks

    Discussion turned to the over-abundance of landmarks. The current proposed code (#23089) outputs too many landmark roles. A theme may add numerous landmark roles without the ability to control where and how many there are. Andrea noted “currently, _s outputs one aside (mapped to complementary) for each widget, nested inside a general complementary area for widgets.” Jared Smith of WebAim recently said “Easy accessibility check: Search for “role” in source code. If 0 instances, probably bad. If 1-20, probably OK. If greater than 20, definitely awful.”

    Other Items

    Morten Rand-Hendriksen asked: “What is the best tool for computer voice control (in particular, voice controlled browsing) on both Windows and MacOS? Are there any workable free tools or are we confined to things like Dragon?” There is a demo mode in JAWS and NVDA is free. If there is a free way for developers and designers to experience things using voice control it will help them understand the issues better.Sam Sidler noted that “OS X has voice control built-in, so I’d call that free, but not open source-level free.”

    We finished off by discussing Shiny Updates (see ticket 29820 now landed in core). According to Andrea Fercia there are two main accessibility issues:

      • focus handling
      • absolutely no feedback for screen reader users when an install/update action starts, ends, fails, etc.

    About the latter issue Andrea said “I’d like to propose a solution based on Graham Armfield’s idea (see #28892) but done in a way that it would hopefully be a useful tool for developers.”

    The entire conversation from February 11 is available in Slack archives for the #accessibility channel.

     
  • David A. Kennedy 4:27 am on February 11, 2015 Permalink
    Tags:   

    Accessible Theme Pattern Library Update for February 

    About a month ago, I announced that work on an accessible theme pattern library had started. Progress has moved forward steadily since then.

    Six people have volunteered to create patterns and code has been written! :)

    The volunteers are myself, @cheffheid, @joedolson, @chrisdc1, @arush and @rianrietveld. You can see the list of patterns on this Google Doc. I’ve also created the appropriate repositories on Github for the patterns that people volunteered to lead and/or create. I’ve kicked things off with code for Read More links, modeled after Twenty Fifteen.

    What’s Next?

    • We’ll start writing more code. If you want to contribute, fork one of the existing repositories and make a pull request. If you code exist yet, get in touch with the lead for that pattern. You can find that in the Google Doc spreadsheet. For contributions, we’ll use the fork and pull method.
    • If you have an idea for a new pattern, comment on this page and leave your idea.
    • If you want to lead the creation of a pattern, ping me in Slack (davidakennedy) and let me know. I’ll add your name to the spreadsheet in Google Docs.

    If you have questions, just comment on this post. You can follow along with our progress via the Theme Pattern Library tag.

     
  • Joe Dolson 4:16 pm on February 9, 2015 Permalink
    Tags: classes, , ,   

    Hiding text for screen readers with WordPress Core 

    WordPress introduced the class .screen-reader-text in 2009. Since then, it’s been the canonical way that WordPress handles any HTML output that is targeted at screen readers. Introducing new HTML in the admin that uses this class has never been an issue; but adding more hidden text to output into themed content has been an ongoing problem.

    Starting with WordPress 4.2, core will be making greater usage of the .screen-reader-text class in front-end code, so theme and plug-in developers need to know how to work with it.

    It’s easy to hide text — but the .screen-reader-text class is not about hiding text. It’s about providing text to a targeted audience that’s using a non-visual method to access it. So the simplest methods of hiding text – display: none; and visibility: hidden; aren’t an option. These techniques really do hide the text – from all devices, and all assistive technology.

    How to use screen-reader text

    The purpose of screen-reader targeted text is to provide additional context for links, document structure, and form fields. Usually, that context is readily available to a sighted user because of visual cues and familiar patterns.

    Screen reader text has many specific applications. One common example of this is a link that says “read more”. On its own, this link lacks context in a screen reader. While a sighted visitor can easily identify the context from the surrounding text and images, a screen reader user benefits from including the title of the target in the link:

    
    <a href="{article.permalink}#more">read more<span class="screen-reader-text"> of the title of {article.title}</span></a>
    
    

    Another use of .screen-reader-text is to hide labels in forms. Search forms are a common place where designers use placeholders and image buttons to convey the purpose of the form. Adding a label that’s available to screen readers make the form usable for screen reader users, without altering the design.

    Defining the class

    When you define classes for .screen-reader-text, there are two common methods: absolute positioning and clipping.

    The clip method is used by WordPress core, and is the preferred method.

    
    .screen-reader-text {
        clip: rect(1px, 1px, 1px, 1px);
        position: absolute !important;
        height: 1px;
        width: 1px;
        overflow: hidden;
    }
    
    

    The absolute positioning method is simpler, but requires you to provide alternate styles for right-to-left and left-to-right languages:

    
    .screen-reader-text {
        position: absolute !important;
        left: -999em;
    }
    
    

    It’s common to see the absolute positioning method also using negative positioning on the top margin — this is not recommended. While the arbitrary measurement of -999em is effective almost 100% of the time off the left margin, almost no value will be universally usable off the top margin. Additionally, if any object that can receive focus (such as a link, button, or form input) is positioned off the top of the screen, it will cause the browser to automatically scroll to the top of the window if that element receives focus. This can be disorienting for anybody using a keyboard to navigate the page. It’s also worth noting that the off-left positioning method can have a negative impact on web site performance.

    Bring Hidden Text into Focus

    In some cases, it’ll be necessary to bring your hidden text into view when it receives keyboard focus. This is relatively rare, and primarily effects Skip links, which need to be made visible for keyboard users. You shouldn’t apply a focus state on most screen reader text; if that text doesn’t need to be seen in order for the context to be understood by a sighted user, don’t make it visible on focus.

    If you do need to bring screen reader text into focus, you can use these base styles to move the text into view when using the clip method:

    
    .screen-reader-text:focus {
        clip: auto !important;
        display: block;
        height: auto;
        left: 5px;
        top: 5px;
        width: auto;
        z-index: 100000; /* Above WP toolbar. */
    }
    
    

    Using the absolute positioning method, it’s simply a matter of changing the value of the left positioning so that the text is on screen.

     
  • Rian Rietveld 2:26 pm on February 9, 2015 Permalink
    Tags:   

    Press This: Accessibility user test result 

    Accessibility test results of the new Press This bookmarklet.

    This is not an extended code review like we did on the Theme Switcher. The code itself is still in early development as we where told. We tested how to add the bookmark and the first impression of the press This functionality itself.

    Tested:
    Press This version 0.0.4.1 and 0.0.4.3
    Also tested the Copy Press This code patch 3 from ticket #28873

    Testers:

    • Michelle deYoung (NVDA on FireFox 35 Windows 8.1)
    • Malgorzata Mlynarczyk (NVDA on FireFox 35 Windows 8.1)
    • Chandra Shekar (Keyboard Windows Firefox)
    • Geof Collis (IE 11 and latest Firefox, JAWS 14 and NVDA 2011)
    • Greg Wocher (JAWS 16 on FireFox Windows 8.1)
    • Jeff de Wit (Keyboard on Chrome Linux)
    • Hyongsop Kim

    The report is divided into:

    • Adding a bookmark with keyboard or a screen reader
    • Using the Press This functionality
    • Conclusion

    Adding a bookmark with keyboard or a screen reader

    Results from testers:

    Windows Firefox:

    1. Tab to “Copy Press This Code” press enter
    2. Copy the code
    3. Press Alt+B and go to “Bookmark this page” Or Press Ctrl+D and Bookmark it
    4. Now Press Alt+B and go to “Recently Bookmarked” menu item
    5. Tab and use Arrow key to locate the bookmarked item
    6. Press the Contextual key when focus is on the bookmarked item
    7. Select the property link
    8. Now we can see Editable popup dialog
    9. Change the Name to Press This
    10. Paste the code previously selected code in the Location field
    11. Tab to save button and press enter

    Chrome (and probably same for Safari) on Mac:

    Use the Bookmark Manager (Ctrl+Shift+O or ⌘+Shift+O). From there, you need to tab to “Organize”, hit space, and select “Add Page”. The new “Copy Press This Code” button (From patch works well for me. It might be cleaner UI-wise to combine it with the existing “Press This” button.

    IE 11

    Unable to add the bookmarklet via keyboard. When added by right clicking on the icon, it was added to the Favorites list. When accessing the bookmarklet, it brought up a blank page.

    Empty page in IE11

     

    And Greg’s quest on how to add the button with JAWS:

    First I am unable to find a way in either FireFox, Internet Explorer or Google Chrome to manually create a book mark. The only thing I have been able to do is to take an existing bookmark and alter its properties by using either shift + F10 or by pressing the applications key to bring up the right click context menu when in the favorites menu in IE. I have not been able to find a way to do this in FireFox or Chrome as of yet.

    I need to test on my Windows 7 laptop. Once there I try and paste in the Java script code I retrieved by pressing the copy press this code button. However I am unable to paste all the code into the URL field because it is to long.

    After doing some research I was able to find out how to add manual bookmarks into both FireFox and IE. Neither of which is very intuitive. In IE you need to create a text file with the url in it and save it to your favorites folder with a .url extension. In FireFox you first need to open up show all bookmarks. Next you need to tab around till you hopefully land on the navigation pane, which is not labeled as such to the screen reader. It is basically the list with all your folders in it. Next you need to either press the applications key, folders in it. Next you need to either press the applications key, perform a right click or use shift + F10 to bring up a context menu.

    Once this menu is up you will see an option to create a new bookmark. Once I was able to create the bookmark in FireFox it seemed to work.

    No label on the textarea field

    Consider marking-up the instruction as a label for that field; in that way the instruction will be automatically read out to the users when they reach the field. Alternatively, ‘aria-labelledby’ could be used on the textarea field, associating that field with the paragraph which contains the instruction.

    When a screen reader user selects the ‘Copy press this code’ button, the keyboard focus is moved immediately into the textarea field. That means that the screen reader user skip the instruction displayed above the field, and may not be even aware of it. Although in theory the users could switch off the application mode, go back to the document mode and then access the content above the field, I don’t think it’s the best solution. Also, the textarea field has no label.

    Some users ended up bookmarking the Press This page itself.

    The text “or right click it and add it to your favorites for a posting shortcut” is probably not enough.

    Using the Press This functionality

    Only two testers ended up testing the Press This functionality itself, both developers. Their remarks:

    Using the actual Press This bookmarklet is a bit confusing compared to how it was before. I’m finding it hard to tell where my focus is at when I’m tabbing through the popup window.

    Some specific issues using just the keyboard:

    • Selecting a new image after activating this thing:
      Press this button
    • The editor seems to expand below the footer bar with the Save Draft and Publish buttons. I need to press enter a few times to be able to see what I’m doing at the end of a post if it runs long:
      Press this below the fold

    Other issues:

    • When the user tabs to the area to add the title of the post or to enter text, they have to highlight and delete the text or backspace to remove it so it is not added to the text they are typing.
    • When users add a url to be scanned, they are unable to access the editing items, or the textarea box. Not sure if this is intentional or not.
    • The icon, link and bottom of the page are voiced to the user as:Browse mode: (camera) “link add media” | “application clickable” (for rich text area) | “button save as draft button publish” Note: In the browse mode (virtual buffer mode), the link and button are read as one item.Forms mode: (camera) “add media link add media” | “application rich text area press alt plus h for help” | “button save as draft” | “button publish”Suggested: (camera) “add media link add media” | “rich text area, enter your text here, or press alt plus h for help” | “button save as draft” | “button publish”
    • When the user presses [Alt] + [H] for Help from the rich text editor in the sidebar, the help content is not able to be accessed via (browse mode) arrowing or (forms mode) tabbing.
    • Another tester: Two of the buttons are not labeled properly. One just says P and the other just says A. Also the text edit field is not labeled very well. All it says is Rich Text area. There is no indication for a screen reader user that it is an actual edit field.

    Conclusion

    1. Adding a bookmark with a screen reader or keyboard only is hard to do, and different for every browser. Add more help and explanation.  Every browser does this differently and besides that with a screen reader is almost impossible to tell what you are doing. Some testers bookmarked the tools.php itself.
    2. Check for the length of the url: does it fit in a bookmark in different OS and browsers.
    3. Nor a11y related: These are results for experienced users and developers,  a usability test would also be useful for sighted users. A decent manual would also help.
     
    • Michael Arestad 3:08 pm on February 9, 2015 Permalink | Log in to Reply

      Thank you so much for testing this, Rian, Michelle, Malgorzata, Chandra, Geof, Greg Wocher, and Jeff! This is all valuable and much-appreciated feedback! Some of these issues have already been fixed. We’ll do our dang best to fix the rest of the issues and improve UX in short order.

      • Badeyes 6:28 pm on February 9, 2015 Permalink | Log in to Reply

        Hi Michael

        very welcome!

        I just went to one of my dashboards and found it was different than what I tested, now I can add it to my favourites by using the application key but when I use it I still get a blank window.

        cheers

        Geof

    • Jeff de Wit 4:47 pm on February 9, 2015 Permalink | Log in to Reply

      You’re very welcome sir! And good work so far :)

  • Rian Rietveld 9:00 am on February 3, 2015 Permalink  

    Test Chat Summary, Februari 2 

    Last week @afercia and @trishacupra did an a11y test on the new Customizer Theme Switcher. @celloexpressionstook together with @afercia takes care of the issues we found.

    In our LinkedIn Group and on Slack we asked for new a11y testers on a weekly basis. About 25 people responded. They will get an e-mail every week with an accessibility test.
    The group is large and diverse enough to divide them into:

    • keyboard-only and colour testers
    • screen reader users
    • developers

    Each can test different issues.

    This week we will test:

    1. The new Press This plugin. For that we also need to install the latest patch with ticket #28873 because the Press This button in tools.php in not accessible with keyboard only.
    2. Missing label associations throughout network admin. For the developers, #30486

    Plugin and patches are installed on the test server now, details are in the test e-mail.

    Scheduled for testing after this: patches with the tickets #30685, #29958, #31143, and #31144. So if you want to work ahead…

    If you want to join in and receive the weekly test e-mail, please contact us in Slack in the accessibility channel or via the contact form.

     
  • Rian Rietveld 7:38 am on January 31, 2015 Permalink  

    Theme Switcher: Accessibility test result 

    Accessibility test results of the new Customizer Theme Switcher

    Tested:
    Customizer Theme Switcher Beta Version 0.7
    On WordPress 4.2-Alpha nightly build

    Testers:
    @afercia (keyboard, screen-reader, code review, report)
    @trishacupra (keyboard)

    The report is divided into:

    • Must have
    • Nice to have
    • General Customizer issues
    • A11y unrelate issues

    Must have

    1. The accordion title

    The accordion title doesn’t convey enough information about the purpose of this section. The text just says, for example:

    Theme: Twenty Fifteen
    Press return or enter to expand

    OK, that’s nice to know… but what I can do there when it’s expanded?
    Text should say also something like “preview more themes” or similar. This is a UI issue for all users: I just clicked on “Customize”, I know I’m in a place where I can customize things. So what I understand is I can “Customize Site Title & Tagline”, “Customize Colors” etc. and for analogy with other titles the information I get here is that I can “Customize Theme: Twenty Fifteen”. Nothing about a “preview”.

    2. Empty tab stop after “Add New” and before search.

    Just on first load, ‘.theme-overlay’ has display: block meaning is visible (though empty) AND is focusable:

    <div class="theme-overlay" tabindex="0"></div>

    Empty tabs stops are confusing for users, they can’t figure out what’s in there. What happens after you open and then close the modal? fadeOut() sets display to none and ‘.theme-overlay’ is no more focusable: no more empty tab stop. Should be display: none also on first load, to avoid the empty tab stop.

    3. Missing label

    #themes-filter “search installed themes…” has no label

    4. Focus + Enter on “Theme Details”

    Focus + Enter on “Theme Details” doesn’t trigger the details modal.

    Everything must be operable with a keyboard.
    Elements need to be focusable to receive keyboard events. Why binding keydown event on ‘.theme-screenshot, .more-details, .theme-name’ when they’re not focusable. No focus, no keydown event. What about to bind keydown directly on ‘.theme’ which is already focusable? And then move ‘.theme-actions’ out of ‘.theme’ and position it absolutely?

    5. ARIA role and aria-label on the details modal

    ARIA role and aria-label on the details modal, to give feedback a modal is currently open.
    Recommended:

    <div class="theme-overlay" tabindex="0" role="dialog" aria-label="<?php esc_attr_e( 'Theme details' ); ?>"></div>

    This way, when the modal opens, screen reader will read out:
    “Theme details dialog”
    Without this, screen readers will start reading out all the content of the dialog, with no feedback about a dialog is actually open, e.g.:
    “out of list” (meaning it’s exiting from the themes list)
    “Show previous theme button, Show next theme button, Close overlay button, Twenty Fourteen Version: 1.3″ etc…

    Important: to be done together with point 2.

    6. Close button.

    For consistency with 5., change the close button text in ‘Close details dialog’.
    Current text ‘Close overlay’ doesn’t help me to understand what an “overlay” is, that’s developers language.

    7. Contain keyboard navigation inside the modal.

    When a modal is open, keyboard navigation must be contained inside the modal.

    WordPress already does this for almost all of its modals. Every modal has its own way… we should standardize this sooner or later.
    We can provide a working code example, not a real patch, we’ve just patched the plugin locally. Code borrowed from media-views “wp.media.view.FocusManager”.
    It’s just an example, this feature can be implemented in many different ways, see for example other modals (wplink, etc.). Little concerned about jQuery UI :tabbable performance, maybe not an issue.

    8. The preview <iframe>

    The preview <iframe> should have a title attribute.

    9. Focus on Add New Theme box

    Focus on Add New Theme box (the last one in the left sidebar). Recommended: make focus style same as hover.

    Nice to have

    10. Tabbing in the modal

    Tabbing in the modal, there’s no easy way to find information about the theme! for example in this text:

    Twenty ThirteenVersion: 1.4
    By the WordPress team

    only “the WordPress team” is a link, when read out of context has no useful meaning. Would be nice to have some more text in the link (maybe using screen-reader-text) with the current theme name. Needs .org API change?

    11. Collapse/expand link

    Tester’s report: “Can’t figure out how to navigate to the ‘expand’ arrow after collapsing the customizer.”

    Important: when the sidebar panels slide out and are out of view, they’re still focusable and “tabbable”. You can tab through them and also activate their controls, just focus one of them and press Enter.

    Recommended: when panels slide out and their animation ends, they should really be hidden with display: none to make their controls not focusable.
    Similar to what currently happens in media views, see: #30599

    12. Collapse/expand link focus style

    Improve the collapse/expand link focus style

    13. Jump from the sidebar pane to the preview pane

    Consider having some sort of mechanism to quickly jump from the sidebar pane to the preview pane and vice-versa.

    Say you’re a keyboard user, you choose a theme and you press Enter on the “Live Preview” button. Page is updated and focus is lost. To navigate with the keyboard to the preview pane, you have to tab through all the sidebar controls first.
    Same when you want to return to the sidebar pane after finally getting to the preview pane.

    Tester’s report: “Can’t find a way to skip straight across to the theme preview pane on the right in order to explore the new theme preview, scroll up and down to check out the theme, etc.”

    Important note:

    Say you choose a theme and finally tab to the preview pane: there’s a chance you’re previewing a totally inaccessible theme.
    Tester’s report: “You’re tabbing and you have no idea where you’re in that case.”
    As a screen reader user you may be totally lost, as a keyboard users you could fall in some keyboard trap.

    Recommended: add a way to easily exit the preview pane and move focus back to the sidebar.

    14. Giving focus to iframes. (related to 13)

    Some browsers, especially when in combination with some screen readers, have issues giving focus to iframes.

    Tester’s report: “When I tab between the Collapse link and the Preview pane, there isn’t a smooth transition, which is the ‘gap’ where I’m getting lost. I suggest a link that appears on focus to go to the Preview pane just before the Collapse link.”

    General Customizer issues

    15. The .theme-screenshot image

    The .theme-screenshot image in “You are previewing” accordion section needs an alt attribute, see customize.php

    <img class="theme-screenshot" src="<?php echo esc_url( $screenshot ); ?>" />

    16. Headings

    Missing first level heading. @todo check header hierarchy.

    17. Orphaned/misplaced label, examples

    “Background Color” (and all the ones for picking colors with Iris)
    there’s a label that wraps 2 input fields, one gets revealed when picking a color. We understand this is how iris works, BTW screen readers won’t get the association between the label and a form element.

    “Background Image”:

     <label for="background_image-button">
     <span class="customize-control-title">Background Image</span>
     </label>

    The “background_image-button” button is the “Change Image” button.
    Result: click on what appears to be a title: “Background Image” and a modal opens.

    18. Empty links (Customizer or underlying panes?)

    Several empty links (some of them maybe img without alt? some just empty). See several add widget toggles a.widget-action with no text or aria-label, just empty. They should have some text that makes sense also when read out of context.

    19. Buttons

    Buttons should be buttons (see primary button is an <a>).

    20. Color contrast

    Color contrast: active/focus state, accordion toggle arrows, etc.

    21.  .theme-overlay .theme-version has user-select: none;

    Why .theme-overlay .theme-version has user-select: none; ?
    As a user, I want to be able to select that text.

    A11y unrelated

    22. Attributes

    Attributes should be escaped? see e.g.
    placeholder=”<?php _e( ‘Search installed themes…’ ); ?>”

    23. <button> elements

    All the <button> elements need type=”button”.

    24. Event namespaces

    Consider the use of event namespaces?

    25. “Update Available”

    On hover,the cursor is a pointer but clicking it doesn’t do anything: consider using default cursor style

    26.  Maybe .theme-header should not be rebuilt on each prev/next

    Enhancement: maybe .theme-header should not be rebuilt on each prev/next ?
    With .theme-header being “fixed”, focus would not be lost on each prev/next action, this would save focus handling via JS.

    27. Bug in Chrome when focusing the close button.

    Couldn’t reproduce using Firefox, looks like it happens just in Chrome.
    See attached screenshot: as soon as you tab on the “Close” button, the sidebar pane underlying the details modal slides out and the main accordions gets in.

    See: .wp-full-overlay-sidebar-content
    it inherits overflow: auto from theme.css so it can scroll horizontally.

    When focusing any focusable element on the right side of the details panel (close button or links in the content) it will scroll thus moving the sidebar on the left.

    Notice it gets also overflow-y: auto and overflow-x: hidden from customize-controls.css
    Need to reset both to visible, just when the details modal is open, using something like:

    .modal-open .in-themes-panel #customize-controls .wp-full-overlay-sidebar-content {
    overflow: visible;
    }

     

    customizer theme switcher tabbing

    customizer theme switcher tabbing

     
    • Drew Jaynes (DrewAPicture) 7:59 am on January 31, 2015 Permalink | Log in to Reply

      Thank you @afercia, @trishacupra, and @rianrietveld. Very thorough!

    • Graham Armfield 3:41 pm on January 31, 2015 Permalink | Log in to Reply

      Amazingly thorough test. Excellent work.

    • Joe Dolson 3:47 pm on January 31, 2015 Permalink | Log in to Reply

      This is great data – thanks for doing this!

    • Nick Halsey 7:08 pm on January 31, 2015 Permalink | Log in to Reply

      Thanks for the detailed & thorough testing! I’ve popped into #accessibility on slack and will work through these issues today. Many of these issues require core patches; I’ll create tickets for those and patch them (although I may leave some as good-first-bugs); it would be great if a committer could follow up on those soon.

    • Nick Halsey 8:45 pm on February 1, 2015 Permalink | Log in to Reply

      Please let me know if any of these changesets look incorrect in any way. Working my way through the list from the top, will do a second pass to create the core tickets that I know the fix for.
      1. @todo
      2. Fixed in https://plugins.trac.wordpress.org/changeset/1080258/customizer-theme-switcher
      3. Fixed in https://plugins.trac.wordpress.org/changeset/1080261/customizer-theme-switcher
      4. Sorry, I completely messed that up trying to fix something else. Fixed in https://plugins.trac.wordpress.org/changeset/1080271/customizer-theme-switcher
      5. Fixed in https://plugins.trac.wordpress.org/changeset/1080272/customizer-theme-switcher
      6. Fixed in https://plugins.trac.wordpress.org/changeset/1080274/customizer-theme-switcher
      7. @todo
      8. @todo core ticket/patch
      9. @todo core ticket/patch (this uses the CSS from the admin page)
      10. This would be a core patch at least, and possibly an API change. Could you create a ticket for this issue on core trac targeted at the current admin themes page, which has the same issue, which would most likely also fix the plugin?
      11. I think #29949 would probably fix this?
      12. I think that’s likely to change with #31195 if that happens, but in the meantime #31201
      13. @todo core ticket/patch, I’d like to add “Skip to preview” and “Back to controls” `.screen-reader-shortcut` links
      14. Add to 13. ticket an additional preview link before collapse
      15. The proposal is to make that section go away in the merge patch, so should be a non-issue.
      16. @todo core ticket/patch #customize-info .accordion-section-title should probably have a h1 somewhere?
      17. @todo core ticket/patch please open a ticket with more specifics on issue with the different control types (upload/image, color, etc.)
      18. @todo core ticket/patch please open a ticket with more specifics on this issue
      19. @todo core ticket/patch please open a ticket with a list of buttons that aren’t buttons in the Customizer so we can fix those (I know widgets have several)
      20. See #29158. Would love to get that resolved, it’s really bad right now.
      21. @todo core ticket/patch (no idea why that’s there)
      22. Fixed in https://plugins.trac.wordpress.org/changeset/1080352/customizer-theme-switcher
      23. Fixed in https://plugins.trac.wordpress.org/changeset/1080362/customizer-theme-switcher. Could also use a core ticket/patch for the existing equivalent for the admin page
      24. Not sure that that’s needed since everything’s already scoped to the Customizer section/control, but I’m open to suggestions/patches.
      25. I decided to remove the updates UI entirely, it doesn’t fit here. https://plugins.trac.wordpress.org/changeset/1080335/customizer-theme-switcher
      26. Could get a bit messy since there’s no container element for to sibling elements to .theme-header, is there a specific benefit here other than saving some JS?
      27. That’s been bugging me for a while and I had no idea what was causing it, thanks for the fix! https://plugins.trac.wordpress.org/changeset/1080369/customizer-theme-switcher

    • Nick Halsey 9:40 pm on February 1, 2015 Permalink | Log in to Reply

      Core tickets:

      I left some as good-first-bugs. I didn’t make tickets for ones where I’m not sure of exactly what’s needed.

      8. #31202
      9. #31203
      12. #31201
      13-14. #31204
      21. #31205

    • Andrea Fercia 11:24 pm on February 1, 2015 Permalink | Log in to Reply

      Nick thanks very much for your complete review and fixings. Seen many of them are already in v. 0.8.

    • Sharon Austin 3:06 pm on February 2, 2015 Permalink | Log in to Reply

      This is a superb report. I’m learning a lot just by reading it, because the report spells out “why” something is broken for the user, not just what is broken. I hope to see more reports like this.

    • Andrea Fercia 6:50 pm on February 3, 2015 Permalink | Log in to Reply

      Noticed two new issues, then we should maybe review all the points and do a second testing round:

      • DIVs added as last items inside UL (see the famous add-new-theme div+link) that’s not just invalid code but also not semantic and problematic for a11y: that list should… list :) the themes. Add new theme link is a control logically separate by the list and should be outside of the list
      • implicit labels (the ones without “for” attribute that just wrap an element) that contain more than one element so UAs won’t understand which element they’re associated to
      • “Search installed themes” gets read out twice. Repeating the same text in the label and in the placeholder it’s not a so good practice. Placeholder should not be used as a label but as a “hint” about how/what to enter in the field.

      Edited: added 3rd new issue.

    • Andrea Fercia 7:36 pm on February 12, 2015 Permalink | Log in to Reply

      Reviewed all the issues, thanks to @celloexpressions dedication to accessibility the main ones are fixed. Big thanks :) There are some outstanding issues, listed below. Note: Nick, will report also some of your comments, for clarity:

      New 1.
      “add-new-theme” DIV added as last items inside UL: invalid/non semantic code, also problematic for accessibility: how many themes in the list? Add new theme link is a control logically separated and should be outside of the list.

      New 2.
      “Search installed themes” gets read out twice, at least with NVDA. Repeating the same text in the label and in the placeholder it’s not a good practice. Placeholder should not be used as a visual label but as a “hint” about how/what to enter in the field.

      Old 1. The accordion title doesn’t convey enough information about the purpose of this section.
      see https://make.wordpress.org/core/2015/02/03/customizer-theme-switcher-update-22/
      > Our biggest remaining decision is whether to change the title of the “themes” section in the Customizer.
      Note: there’s ongoing discussion about the header area, involving possible UI changes.

      Old 10. Tabbing in the modal, there’s no easy way to find information about the theme!
      > This would be a core patch at least, and possibly an API change. Could you create a ticket for this issue on core trac targeted at the current admin themes page…?
      Thinking about this, not sure what we can do here about “authorAndUri” returned by wp.org API, there are also translation issues to take into consideration.

      Old 15. The .theme-screenshot image in “You are previewing” accordion section needs an alt attribute
      > The proposal is to make that section go away in the merge patch, so should be a non-issue
      OK, just mentioned here as a reminder.

      All the other issues already have a ticket or they’re not strictly related to the Customizer Theme Switcher, but to the Customizer itself, will open new tickets.

      • Nick Halsey 4:47 pm on February 13, 2015 Permalink | Log in to Reply

        1. unfortunately we can’t change that. The way the Customizer works, all controls need to be children of the same container, in this case the ul. We could put the add-new div within an li, though, if that would be better.
        2. So can we remove the screen-reader-text label then? We’d want that text in the placeholder only by default, but if we need to do anything additionally for accessibility let me know.

  • Rian Rietveld 1:41 pm on January 27, 2015 Permalink  

    Test Chat Summary, January 26 

    After a few months of having a test session on Monday’s we gathered a group of people discussing and fixing tickets and patches.
    But limiting the testing to a weekly one hour session turns out to be not pracical.

    Not eveyone has the time to be there and work on that exact hour, we are a global group.
    @afercia is doing a ton of work on the tickets at the moment and we need more testing and more feedback.

    So here’s a proposal for making better use of our time, coders and testers.

    The Monday session will be a meeting to discuss the tickets/patches, like:

    • what are tickets we need to work on, what has priority
    • what tickets have a working, tested patch and needs dev feed back or assigned a milestone to
    • what tickets need to be tested and on what AT and who can we ask for that
    • what are the test results, and can we change / approve a patch
    • people can ask for functionally to test or ask questions on how to fix stuff

    Then after/during the test session we can install a patch on the test server in the trunk website and assign testers.
    During the week the testers can look at the changes and report back as a comment with the ticket or to the #a11y team in slack or by e-mail. Then everyone can test in their own time, we can give specific small tasks to test.

    We can also ask the testers to look at specific functionality in the current version of WP to find what’s wrong or needs to be changed.

    In this meeting we discussed:

    Ticket #28599 (Better Visual Focus Indication in Admin Menu): This ticket has a working patch and needs dev and designers feedback. @ryan will also take a look at it this week. In it’s current state the patch is’t ready for production, for example it misses all the parts related to color schemes and SASS.

    Ticket #30589 (Comments navigation template tags): We discussed if the landmark <nav> is appropriate for the comment navigation, <nav> is meant for main navigation. Now there is a risk that we overload a theme with nav’s @afercia will respond to that ticket with outline examples in Twenty Fifteen.

    Ticket #29955 (Section 508 issues found on WordPress 4.0 admin page): This ticket will be closed and divided it into new separated tickets.

    The patch on the test server this week will be for Ticket #28599 (Better Visual Focus Indication in Admin Menu). If you want to join in the testing, please contact @rianrietveld.

    Screen Reader Text support:

    This is an ongoing discussion and commented on by some of us in:

    In the codex WordPress Generated Classes there is an example on how to implement the screen-reader-text class. We advice to remove the

    .screen-reader-text:hover,
    .screen-reader-text:active,

    because they have no use in this context. Just keep the focus.
    Clip is due to be deprecated in favor of clip-path, but clip-path is not very well browser supported yet. So lets stick to clip for the time being. Maybe a note of that in the codex will be useful.

    @joedolson will discuss a11y with @drewapicture this week, we also hope to get more dev feedback on some of the patches.

    In the weekly Accessibility Chat next Wednesday we want to discuss ticket priority.

     
    • Andrea Fercia 2:42 pm on January 27, 2015 Permalink | Log in to Reply

      To clarify just a bit my opinion, <nav> should be used for “major navigation blocks”. So yes, I do think there can be more than one <nav> on a page but what’s exactly “major” is matter of discussion.
      Specifically for comments, my opinion is that comments are by definition an “aside” or maybe a “section” as in the W3C example. They’re not the “main” content, they’re related to it. They’re complementary content. So if you add navigation to a “secondary” content, then considering that navigation “major” doesn’t look right to me.

    • هاست 9:56 pm on January 30, 2015 Permalink | Log in to Reply

      thank you

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