WordPress.org

Make WordPress Accessible

Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

  • Rian Rietveld 10:34 am on December 15, 2015 Permalink
    Tags: , ,   

    Team meeting summary December 14, 2015 

    The last month, especially after WordCamp US we’ve got a lot more people contributing to the wpa11y team.
    Welcome Robert Jolly, Morten Rand-Hendriksen, Cheo Walker, Sakin Shrestha, Barret Golding, Adam Soucie, Scott Mann and Rachel Vasquez!

    We want to keep all the new people involved, not make them feel lost or left out and leave.
    Therefore we decided to form working groups, assign one lead and divide the new people in the workgroups, so they know what to do and who to ask for help/work. People can jump in and out of groups as work ebbs and flows.

    Working groups

    Core

    • Task: Find accessibility issues, write and discuss tickets on core trac and code patches for WordPress core.
    • Lead: Andrea Fercia
    • Contributors: Joe Dolson, Jeffrey de Wit, Sergey Biryukov, Cheo Walker, Trisha Salas, Adam Soucie, Robert Jolly, Rian Rietveld.

    Documentation

    • Task: Write documentation about accessibility in our Handbook and on other relevant places on WordPress.org
    • Lead: Trisha Salas
    • Contributors: Joseph O’Connor, Barret Golding, Richard Senior, David Kennedy, Rachel Vasquez.
    • Joe Dolson and Robert Jolly volunteered to review written content.

    Theme team

    Meta

    • Task: Find accessibility issues, write and discuss tickets on meta trac and code patches for the website WordPress.org and WordPress.tv
    • Lead: Joe Dolson
    • Contributors: Morten Rand-Hendriksen, Barret Golding, Trisha Salas

    WordCamp themes

    • Task: Review of the WordCamp themes and help with fixing the accessibility
    • Lead: David Kennedy
    • Contributors: Jeffrey de Wit, Adam Soucie

    Test team

    • Task: Test the accessibility of new and exsisting functionallity in and for WordPress core, at the request of the other workgroups and teams
    • Lead: Rian Rietveld
    • Contributors: > 75 volunteers, with different kind of assistive tecnology and/or accessibility expertise

    Accessibility code standards for core

    During the WCUS community summit in Philadelphia we made a start with accessibility code standards for core.
    Joe Dolson put a concept for the a11y code standards together.
    Please look at the concept and comment on it.

    Documentation

    Barret and Trisha are working on a good outine for the documentation, lots of good ideas, work in progress, more next week.

    Core

    The last #a11y-headings ticket is #26601 Inappropriate content in headings on admin screens.
    Joe Dolson will look into this, make a decision on how to solve this issue. On the WCUS contributors day we discussed this and the outcome od this was: First get the link out of the heading, without changing the visual design. And after that is committed, start the discussion of removing it conpletely from the post-new.php / post.php pages.

    Next big project for 4.5: Color contrast ratio of the colors used in the WordPress Admin.
    The official colors to use are on make.wordpress.org/design/handbook/foundations/colors/
    Related ticket: #31234 closed Update wp-admin default colors.

    We need to review them and fix contrast ratios for text and background lower than 4.5.
    The tickets we file for this will be labeled #a11y-color.

    Also related:
    #34957 #a11y-focus: Standardizing the handling of :focus and :hover
    Any feedback on this ticket for the project is appreciated by Adam Soucie

    Meta

    Ideas for meta.trac tickets from Barret:
    1. the skip-to link needs to be closer to.
    2. the skip-to link-text should be visible on focus.
    3. the headings hierarchy is far from W3C standard.

    Idea from Morten: Start a campaign to get WordCamp speakers to caption their own talks.

    To-do for next week

    Read and comment on Accessibility code standards for core.

    Tickets that needs work/discussion
    If you want to work on core, grab one of these tickets and help solving them

    • #31195: Add a user-friendly way to preview site responsiveness in the Customizer
    • #34625: wp-login.php site title link points to wordpress.org
    • #31195: Add a user-friendly way to preview site responsiveness in the Customizer
    • #35029: Remove title attributes: the revisions limit in the Publish box
    • #35050: Remove title attributes: Plugin Cards
    • #35064: Remove title attributes: options-general.php
    • #35076: Remove title attributes: the Featured Image postbox
    • #34957 #a11y-focus: Standardizing the handling of :focus and :hover
    • And every other ticket that focusses accessibility
     
    • RachieVee 4:18 pm on December 16, 2015 Permalink | Log in to Reply

      Looking forward to helping out with documentation. It’ll be awesome getting those standards that were just posted into the handbook.

  • Rian Rietveld 10:13 am on December 15, 2015 Permalink  

    Accessibility code standards for WordPress core 

    During the WCUS community summit 2015 in Philadelphia we made a start with accessibility code standards for WordPress core. Joe Dolson put a concept for the a11y code standards together (see below or as Google Doc).
    These are the standards expected from new code (like feature plugins) at the time it’s to be merged into core. Our target for released code is WCAG2.0 AA.
    Proposed place to put them is the Core Handbook: WordPress Coding Standards, we aim for a short list of very basic things with references to the Accessibility Handbook.

    Feedback (in the comment section below) is very welcome.

    Concept Accessibility code standards for core:

    This document is a list of standards that a WordPress feature plug-in should meet for accessibility in order to be merged into core. These standards are focused on best practices and easily testable concerns.

    The expectations for all code released in WordPress is conformance with WCAG 2.0 at the AA level.

    • HTML Semantics
    • Headings Hierarchy
    • Definition of HTML for Controls
    • Usage of ARIA
    • Color Contrast
    • Keyboard Accessibility
    • Images and Icons
    • Labeling

    HTML Semantics

    Take a pragmatic approach to HTML semantics. Don’t add semantics purely for the sake of semantics; but if there is an HTML structure that clearly matches the content, use that element. For example, if you have a group of links, it should most likely use a list element.

    Heading structure

    The H1 is the main heading representing the page title on every core page. For sub sections, use a reasonable HTML heading structure — including the use of heading elements for page sub-sections. Heading markup should not be used for presentational purposes.

    • Use H2 through H6 to give internal structure to the page.
    • Don’t skip heading levels.
    • Don’t add extra functionality inside a heading, like links or buttons.

    Semantics for Controls

    Controls with a native keyboard interaction (buttons or links) are always preferred. If there is a valid target link for the control, either an in-page reference or a link, then the control should use an <a href=”url”>. If there isn’t, it should use a <button>

    Related ticket: #26504 Semantic elements for non-link links

    Dynamic Content

    When there are dynamic changes within a page without a page reload you must provide audible feedback with ARIA for important changes, like a successful saving for example.

    [Provide documentation and links for aria-live, wp.speak, etc.]

    Color Contrast

    In most cases, feature plug-ins are not expected to add or modify colors in core. However, if a feature plug-in needs to add new color combinations, those combinations must meet minimum contrast requirements. Minimum contrast requirements are 4.5:1 for font sizes rendering smaller than 24px or smaller and 3.0:1 for font sizes larger than 24px or 19px and bold.

    [in detailed reference, comment on why we’re referencing as pixels]

    Keyboard Accessibility

    Users must be able to reach and successfully interact with all elements on the page that are actionable, including all form inputs, buttons and links by using the keyboard. They must be able to see a visual indicator of keyboard focus. You should be aware that keyboard events may operate differently when a screen reader is running.

    Images and Icons

    Any image resource must include an accessible name. An image can be represented by an actual element, an icon font, or an svg element; but any graphical representation is considered an image for these purposes. Different types of elements use different types of accessible names.

    For <img> elements, the accessible name should be in the alt attribute. If the img is ornamental, the alt attribute should still be included, but left empty.

    For icon fonts, the font icon itself should be aria-hidden, with screen-reader-text in a neighbor element. e.g.

    <a href=’this.html’>
    <span class=’dashicons dashicon-something’ aria-hidden=’true’></span>
    <span class=’screen-reader-text’>Something</span>
    </a>

    Something

    For SVG, the SVG should be inline, so that accessible information isn’t hidden from assistive technology. SVG elements should contain aelement with the accessible name of the image. For cross-technology support, the title element should be associated with the svg element via aria-labelledby. For more information, see http://www.sitepoint.com/tips-accessible-svg/

    Labeling

    All form inputs must include an explicitly associated <label> 

     
    • Aaron Jorbin 6:02 pm on December 15, 2015 Permalink | Log in to Reply

      This looks great! I am a fan. A few pieces of feedback:

      Under Keyboard Accessibility, I would consider adding specific wording along the lines of “All actions that a user can complete with a mouse, must be completable with a keyboard”.

      For labeling, I think we should add that for all checkboxes and radio buttons clicking on the label must cause the associated field to toggle.

      I would also like to suggest that we add as a requirement all videos included inside core (right now it’s just the about page that usually has a video, but that doesn’t mean other videos won’t ever be added) must be include captioning (even if the captioning is off by default).

      • Joe Dolson 7:38 pm on December 21, 2015 Permalink | Log in to Reply

        The keyboard and labeling suggestions are great, and I’ll definitely incorporate those. I’m wondering if this is the right document for talking about videos included inside core? The document is intended to be geared at code authors primarily, and I feel like while that’s a great policy to have in place, I’m not sure this is the document to put it in. Thoughts?

    • Adam Silverstein 3:48 pm on December 16, 2015 Permalink | Log in to Reply

      Yea! Thanks for working on this. I’m excited to see these standards headed to the handbook. Having a standard in place will help us improve everyone’s efforts.

    • RachieVee 4:07 pm on December 16, 2015 Permalink | Log in to Reply

      This is awesome. My favorite parts here are making use of the screen-reader-text class for images/icons and the semantics for controls. It’ll be great having a guide with examples to reference from the handbook. 🙂

    • Mark Root-Wiley 5:26 pm on December 16, 2015 Permalink | Log in to Reply

      These are so awesome! I can’t wait to see them finalized. The accessibiility progress in WordPress (Core and the community) this past year has been so heartening.

      One issue not included that maybe should addressed is color blindness. WCAG Level A (and AA, then) requires that “color not be used as the sole method of conveying content or distinguishing visual elements.” (http://webaim.org/blog/wcag-2-0-and-link-colors/) The two issues with which I often run into this are:

      • Links. They can’t just be a different color from the text but should be underlined, designed as a button, etc.
      • State. Color should be used as the indicator of a state (which includes :focus, disabled states, toggles, etc.) This might affect the visual :focus requirement in keyboard accessibility.

      This standard can get a little tricky (for instance if you want to support a :visited link state), but aspiring to meet it feels like a bare minimum we should be requiring. For instance, this would at least catch issues like the long-standing Yoast SEO color blindness issue, were that a feature plugin. (https://github.com/Yoast/wordpress-seo/issues/440)

      • Joe Dolson 7:36 pm on December 21, 2015 Permalink | Log in to Reply

        Hi, Mark! We’re not going to address color directly in this document, generally, because we’re aiming to separate developer and designer concerns; that’s why there are issues explicitly addressed about adding new colors. Preparing a document for designers on color choice and WCAG would be great, however; and I’ll definitely look into that. This is supposed to be primarily a code standards guide, and I want to keep it as focused as possible, so it doesn’t become overwhelming.

        • Mark Root-Wiley 1:53 am on December 22, 2015 Permalink | Log in to Reply

          Thanks for the reply, Joe. I had missed that these were so explicitly code focused, but that makes sense to me. If/when the contrast/color/design page were added, I at least hope they would be tightly linked, seeing that developers often make small design decisions for expediency so should be aware of design requirements.

          I had assumed that the Theme Handbook would already have something like this, but I was really surprised to see that the one section on Colors doesn’t really address actual scenarios where colorblindness is a problem: https://developer.wordpress.org/themes/functionality/accessibility/#color (It also uses the word “commonest”…)

          The accessibility-ready requirements similarly don’t seem to touch colorblind-related color requirements.

          • Joe Dolson 9:54 pm on December 28, 2015 Permalink | Log in to Reply

            The accessibility-ready requirements explicitly require that all contrasts in the default settings have to meet WCAG AA contrast requirements. However, since the colors of a theme are the most changed aspect of a theme in actual usage, there’s not a lot to be done with those requirements that is practical.

  • Joseph Karr O'Connor 7:21 pm on November 16, 2015 Permalink
    Tags: , ,   

    Team Chat Summary November 16, 2015 

    Documentation

    Discussion of adding information about accessible content management to either the Codex or the Accessibility Handbook. Decided to add it to Handbook. Keyboard shortcuts will go in the Codex with a link from the Handbook.

    Tickets

    #34681 Consider removing the “Disable the visual editor when writing” option.
    Decided to gather user experience data. Four questions to ask:

        Do you know how to switch between the visual and HTML editor in WordPress?
        If no, please try and figure out how, and tell us how that experience was for you.
        If yes, give us your thoughts about your experience using that feature.
        Do you use the option “Disable the visual editor when writing” in your profile?

    #34625: wp-login.php site title link points to wordpress.org.
    Suggested fix: removing the title attribute, changing the text to ‘Powered by WordPress’, and leaving the filter on that text.

     
  • Rian Rietveld 2:34 pm on September 22, 2015 Permalink
    Tags: , ,   

    Accessibility usertest: Twenty Sixteen 

    The new default theme Twenty Sixteen is close to release, so we gave it to our accessibility testers to check it.

    Testes who joined: Michelle DeYoung, Gabriela Nino de Rivera Torres, Jeffrey de Wit, Sirisha Gubba, Heather Migliorisi, Tobias Clemens Häcker, Kim van Iersel, Geof Collis, Shaun Everiss, and Rian Rietveld.

    Some remarks where not related to Twenty Sixteen but related to WordPress core. Those remarks where not included into this report, like the comment form issues. We will open tickets on them later.

    Summary is at the bottom of this post.

    Test results

    Jeffrey de Wit

    Firefox and NVDA

    • Focusing the featured image makes NVDA go “blank”
    • It may just be me, but the author, category, and tag links in the post meta simply state just that. That is, “themedemos”. Or “Uncategorized”. Nothing else, no context. (Same happens with the widgets, but that’s probably a core issue :))
    • I like how the search button is hidden with screen reader text, but it should probably appear when focused.
    • When focusing links, it sometimes happens that the page scrolls and makes the link go behind the black border around the page. This usually happens when the link that is to be focused is not in sight when tab is pressed.

    That last one seems to be specific to Firefox and IE Edge, I don’t notice it with Chrome because it seems to make an effort to center focused links.

    It can be reproduced with the second post – there’s a link under the h6 where you can see this issue, and then from there it goes back up to the author link in the post meta, which is also “hidden”. I’ll have some videos ready shortly.

    Firefox:

    Chrome:

    Michelle DeYoung

    Windows 8.1 / Firefox 40.0.3 / Window-Eyes 9.2

    Landmarks: Landmarks are voiced. The W3c validator does indicate that the additional role=”specificlandmarkname’ is not needed on the html5 elements (header, form, nav, main, aside, and footer). The questions – has screen reader and browser support grown enough to utilize HTML5 semantics, sans aria landmark roles, to convey the various regions on the screen? In my opinion, I feel aria landmark roles should still be used with the new HTML5 semantics, and I continue to add them to my markup until I hear otherwise. 🙂

    Menu navigation: Users should be able to select ‘ESC’ to close a drop-down menu, and then when tabbing or arrowing again they are taken to the next main menu item. This will make it easier to navigate the menu without it being necessary to tab through many items to get to the needed item.

    I would recommend making the asterisk on the form labels the same size that it is in the instructional text so it will be easier for low vision users to detect.

    Input fields: The color contrast for the border or background colors could be increased. They are difficult to discern. This is part of the minimalistic flat design, however, the light gray can impact users with low vision and they can also look disabled. Note: The input fields look great when they get keyboard focus.

    Gabriela Nino

    I have taken a look to the front-end with VoiceOver. In overall it was easy to navigate and the elements were well recognized. Opening the sublevels of the main menu was simple too. I was able to access the links and buttons and I did not get stuck.
    Something that caught my attention was that images like the post “this is a sticky post” are ignored by the screen reader. I step directly from thetitle of the post to post content.
    The images of the Markup: Image alignment worked well with VoicOver.

    Rian

    Safari, keyboard only

    Menu in responsive mode: If the menu is expanded, it is not clear when the menu button gets focus, for example if you want to close it again. The dropdown toggle arrows do not have a clear focus (only change of color, no dotted outline)

    Is it a feature, that the menu repeats itself in the footer in responsive mode (I actually quite like that).

    Normal menu: Only color change on hover. Active menu item is bold : ok

    Page navigation: No indicator current page number for a screen reader. Color is not enough to indicate this is the current page number.

    page navigation twenty sixteen

    Sirisha Gubba

    NVDA/FF

    1. Roles are used without aria label (more than one navigation is used)
    2. Search button is not visible on the page.
    3. Two search fields with role=search are there on the 404 page
    4. Screen reader user have to go through all submenu items in order to get to another tab item
    5. Also I see color contrast issues with the input fields which would be issue for low vision users.

    Note Rian: except for the 5th item these are all extra’s but not required for WCAG 2 AA.

    Heather Migliorisi

    This theme tested pretty well!

    Tested with VO and Chrome.

    1. the main nav with sub items could be easier to navigate. Currently, if you want to navigate to “Page B,” you have to tab through the entire main nav, sub items included. I like how Adobe’s Accessible Mega Menu tabs through the top level list items. It also provides the expanded/collapsed state to the VO user.
    2. Search field – VO reads “search for” twice
    3. Might be nice to be able to skip the list of keywords added to an article

    Summary

    The main opinion: This theme tested pretty well!
    No drastic errors. Yay!

    First: can someone reproduce Jeff’s error?

    Missing context for sighted users (maybe also a usability issue): The author, category, and tag links in the post meta simply state just that. That is, “themedemos”. Or “Uncategorized”. Nothing else, no context. For screen reader usres there is extra text to give context.

    Landmarks: A lot of the remarks where about landmarks. W3C and VAWE now mark elements with the same role as warnings (not errors). Like: Element nav does not need a role attribute role=nav.

    Note Rian: We discussed this in the team chat and decided that the roles should stay for now, for backwards compatibility with old assistive technology.

    Navigation: three the same remarks:

    • Users should be able to select ‘ESC’ to close a drop-down menu, and then when tabbing or arrowing again they are taken to the next main menu item.
    • Screen reader user have to go through all submenu items in order to get to another tab item
    • Currently, if you want to navigate to “Page B,” you have to tab through the entire main nav, sub items included.

    Note Rian: this is not an accessibility error, but a keyboard user usability issue. Might be worth to find a solution for this.

    Featured image: There was confusion about the featured image with the link being skipped. This is on purpose to prevent extr noise for screen readers by adding an aria-hidden=”true” to the link.

    Input fields: The color contrast for the border or background colors could be increased.

    Focus errors:

    • search button should show up on focus
    • inconsistent focus for responsive Menu toggle button
    • submenu toggle responsive menu should have an outline

    Page navigation

    • no ARIA indicator current page number for a screen reader
    • color is not enough to indicate this is the current page number

     

     

     
  • David A. Kennedy 2:34 pm on September 14, 2015 Permalink
    Tags:   

    Testing Twenty Sixteen 

    By now, I’m sure you’ve noticed Twenty Sixteen has been released on Github and the theme repository to spur development and testing. If you haven’t tested the theme for accessibility, now’s the time! I mentioned it in a recent chat, and a members from the community have already tested it, but the more the merrier!

    What do I test?

    Test the theme according to the accessibility-ready requirements. Since this is a default theme, you should test for the recommendations too. Also, it’s a good idea to look at the applicable WCAG 2.0 requirements (Link is not the official WCAG requirements, but a more readable version), and test the theme according to those, within reason. This way, the theme can be its best accessibility-wise.

    How do I test?

    The accessibility-ready requirements give some information on how to test. We also have a list of tools that will help when testing.

    How do I report bugs, issues or make a enhancement request?

    What information do you need to know when creating an issue?

    Here’s a good format to follow when creating a bug report:

    Title: Accessibility: ISSUE SUMMARY HERE
    
    What I Did:
    
    What I Expected:
    
    What Actually Happened:

    I’m not a developer, how can I help?

    No problem! You don’t have to be a developer to help out. Test the theme on your favorite operating system with assistive technology. This way, we get a better idea of how the theme works with different configurations. Try to break the theme! Note anything that is confusing, and makes the theme harder to use on the front end.

     
  • Rian Rietveld 2:09 pm on September 7, 2015 Permalink
    Tags:   

    Accessibility Usertest: Select2 

    In the last 2 weeks @lindsaymac and @helen requested if the Accessibility Team could take a look at Select2.  Select2 is a jQuery replacement for select boxes and gives you a customizable select box with support for searching, tagging, remote data sets, infinite scrolling, and many other highly used options.

    But how accessible is it, and is it accessible enough to include into WordPress core? Some research has been done by Drupal, but there are still issues open on GitHub.

    On the Select2 Github there are examples, styled with bootstrap. To insure we only test the select2 functionality, we made a series of test pages with the minified JQuery and select2.css and select2.js only.

    Examples of Select2 options:

    1. Basic dropdown
    2. Multiple select boxes
    3. Placeholders
    4. Disabled mode
    5. Disabled results
    6. Select with a button
    7. Limiting the number of selections
    8. Hiding the search box
    9. Add choices automatically
    10. For developers: More Select2 examples on GitHub, including bootstrap

    The questions we asked our testers:

    • Can you select an option
    • Can you remove a selected option
    • Is it obvious to you how to select an option
    • If you use a screen reader: did you get sufficient feedback on what was happening
    • What problems did you have trying to select an option

    The testers who joined: Michelle DeYoung, Gabriela Nino de Rivera Torres, Bram Duvigneau, Cyndy Otty, Philip Chalker, Geof Collis, Bart Simons and Andrea Fercia.

    Test results

    1. Basic dropdown

    Example of choices Select2

    Example of choices that don’t get read out, the entered value gets read out instead

    Geof Collis: JAWS 14.5 IE 11.
    Not accessible. I tried to open the box but just got dead air and I found the edit field down the page but was confused on what to do so typed in the letter a and arrowed down to get a list of states only to realize that if I arrowed up and down I got the list I expected in the drop down box.

    Bart Simons: JAWS15 and IE11,  JAWS15 and Firefox, JAWS16 and IE11, JAWS16 and Firefox
    JAWS says “combo box collapsed”.
    I press enter to go to forms mode.
    Since I am told that this is a combobox I try using arrow down to scroll through the list. This does nothing. I can’t go beyond Alaska. Also arrows up, left and right do nothing.
    Then I try to navigate by typing the first letter. This does not work either.

    The test suggestions suggest to use space bar. This is something I would never have tried by myself.
    After pressing space bar, I am told that I am in an edit box. I type “new” and I hear “New Mexico”. Again there is no possibility to use down arrow to go to New York for instance.
    Even New Mexico does not seem to be selected.

    Besides, it is really not intuitive to require a space bar in a combo box.

    Gabriela Nino de Rivera Torres: VoiceOver+Safari.
    The combo box does not respond to Control+Option+Space bar VoiceOver command to open the list of choices. It does respond to the space bar only.

    When the list of choices it’s open, the first element getting the focus is the link to go back to the list of examples. The second element is the search field text and lastly the table with the choices. I’m using Control-Option+right arrow to navigate inside the combo box element.

    The texts for Time zone are ignored by VoiceOver.

    VoiceOver offers me to navigate the table with the choices using Control-Option-right/left arrow or up/down arrow. Both commands worked fine.

    There seems to be something different with the choice Hawaii. There is an intermittent behaviour that requires me to use the Control-Option-right/down arrow command several times before moving to California. It seems like the focus gets stuck on Hawaii choice for some reason.

    It is not possible to move inside the list of choices using only up/down arrows.

    Using only the Enter key will open/close the combo box choices. In this case the first element getting the focus is the search field text. When making a search, the user does not get feedback if the state that she is looking for it is found or not on the list of choices.

    I could not find how to select an option of the list of choices. Normally I’ll use Control+Option+Space bar command, but I don’t get a response. Using Control+Option+Enter does not work either. Using only the Enter key will close the list without selecting the current choice (the one with the focus on it). But if I search for the state and click on Enter, the list will close but the current choice will be selected.

    Michelle DeYoung: Windows 8.1 / FF 40.0.3 / NVDA 2015.2
    Keyboard only: Works fine.

    FF/NVDA:
    Forms mode –  The state name is announced. This is considered the label via the aria-labelledby.  The label should be the ‘Select a US state”.
    The text input in the expanded list is not labelled.
    Virtual mode – Can arrow through the items in the combobox, but all that is voiced by NVDA is “blank”.
    Note: Can expand and collapse the list.

    Philip Chalker:  iOS + VoiceOver.
    It all reads fine on the screen

    Cyndy Otty:  iOS + VoiceOver.
    But VO is reading the list, but selection itself is definitely wonky.

     

    2. Multiple select boxes

    Geof Collis: JAWS 14.5 IE 11.
    Not accessible. Entered the box but heard nothing.

    Gabriela Nino de Rivera Torres: VoiceOver+Safari.

    The combo box does not respond to Control+Option+Space bar VoiceOver command to open the list of choices. It does respond to the space bar only.

    Using only the Enter key will open/close the combo box choices. In this case the first element getting the focus is the search field text. The second element getting the focus is the link to go back to the list of examples and lastly the table of choices.

    VoiceOver offers me to navigate the table with the choices using Control-Option-right/left arrow or up/down arrow. Both commands worked fine.

    I could not find how to select a choice directly from the list of choices. Control+Option+Space bar command does not work. Using only the Enter key will send me to the instructions page. But if I search for the state, I’m able to select it using the Enter key after entering the word (although I don’t get any feedback to confirm me if the state I’m looking for was found or not).

    I could not found how to remove a choice. Any of the common VoiceOver commands don’t work to get focus on the selected choices.

    Michelle DeYoung: Windows 8.1 / FF 40.0.3 / NVDA 2015.2
    Keyboard only:

    • No visual indicator that it is a select box and offers choices.
    • Yes, selections can be accessed and added.
    • Yes, can remove selections by using the ‘Backspace’. Selection will be removed a letter at a time.

    FF/NVDA:
    Combobox is missing a label. NVDA does announce that it is a combobox.
    List is announced that it is expanded, but the as user arrows through the list the items are announced as “blank”.

    If user randomly selects and item (they will not know what they selected), the items are added to the input field, but they are not announced.
    Unable to access added items in the input to have them announced.  If I assume items exist in that form field, then I can select “Backspace” to remove them a letter at a time.
    Note: Unable to type a selection name in the input field.

    3. Placeholders

    Geof Collis: JAWS 14.5 IE 11.
    Semi accessible. I expected that I would hear the placeholder before going into forms mode but had to enter the field before I did.

    Gabriela Nino de Rivera Torres: VoiceOver+Safari.
    No, VoiceOver did not announce the placeholder inside the first option. The combo box does not respond to Control+Option+Space bar VoiceOver command to open the list of choices. It does respond to the space bar and Enter key.

    Michelle DeYoung: Windows 8.1 / FF 40.0.3 / NVDA 2015.2
    FF/NVDA: Yes, Placeholder is announced. (No labels for input fields)

    4. Disabled mode

    Geof Collis: JAWS 14.5 IE 11.
    Semi accessible. I expected a checkbox for the modes but realized to click on the button and it worked but I’m starting to wonder if I should be reading 2 drop down menus because that is what I am getting in all examples so far.

    Gabriela Nino de Rivera Torres: VoiceOver+Safari.
    I was able to enable and disable the two select boxes. It does work with Control-Option-espace bar and with the Enter key.

    Michelle DeYoung: Windows 8.1 / FF 40.0.3 / NVDA 2015.2
    Keyboard only: Yes, Enable/Disable buttons work

    FF/NVDA:

    • No labels.
    • Yes, Enable/Disable buttons work.
    • Tabbing backwards through the inputs after ‘Disable’ has been selected skips over the inputs initially, but if user continues one more tab backwards the 2nd input will be announced, “Combobox collapsed has autocomplete”.

    5. Disabled results

    Geof Collis: JAWS 14.5 IE 11.
    Not accessible. Sometimes it reads first and other times it doesn’t it isn’t consistent and I only get one box. Used the back button and it froze my browser and had to close it down, grrr!

    Gabriela Nino de Rivera Torres: VoiceOver+Safari.
    I’m not able to move from the first option. I’m using Control-Option-right arrow to navigate between the options on the table. Using only right/left/up/down arrow to move from one option to the other won’t work.

    If I interact with the table choices (Control-Option-shift-down arrow) I’m able to move to the second option and it will be announced by VoiceOver. From the second option it is impossible to move to the third option.

    Michelle DeYoung: Windows 8.1 / FF 40.0.3 / NVDA 2015.2
    Keyboard only:

    • No labels for inputs.
    • Yes, disabled item is skipped over when arrowing.
    FF/NVDA:
    • List items are announced as “blank”.
    • Yes, disabled item is skipped over when arrowing.

    6. Select with a button

    Geof Collis: JAWS 14.5 IE 11.
    Semi accessible. But I find all of these boxes confusing and verbose so I’m quitting, I dont like it in the least, time to go back to the drawing board. :O)

    Gabriela Nino de Rivera Torres: VoiceOver+Safari.
    Yes I can set the option in the select drop using the two buttons for each example. In both examples, VoiceOver does not give feedback after the setting function. I’m able to press the buttons using Control-Option-space bar, only the space bar key and the Enter key.

    Also it is possible to open/close the select choices using Control-Option-space bar, only the space bar key and the Enter key. I think those two examples are easiest to use with VoiceOver.

    Michelle DeYoung: Windows 8.1 / FF 40.0.3 / NVDA 2015.2
    Keyboard only:

    • 1st Example: ‘Set’ & ‘Init’ work, but the others do not.
    • 2nd Example: Yes, it works.

    FF/NVDA:

    • 1st Example: ‘Set’ & ‘Init’ work, but the others do not.
    • 2nd Example: Yes, it works.   Note: Selected items are not announced in the input field they are added to.

    7. Limiting the number of selections

    Gabriela Nino de Rivera Torres: VoiceOver+Safari.
    I was not able to select any of the choices. Once in the table choices I tried selecting with the Enter key (it sent me back to the instructions page), using space bar key only and Control-Option-espace bar did not work either.

    The combo box does not respond to Control+Option+Space bar VoiceOver command to open the list of choices. It does respond to the space bar key and the Enter key.

    Michelle DeYoung: Windows 8.1 / FF 40.0.3 / NVDA 2015.2
    Keyboard only: Yes, it works.

    FF/NVDA:

    • Yes, can only select two items.
    • No, the feedback is not announced.
    • No, the item choices are not announced.
    • No, selected items are not announced.

    8. Hiding the search box

    Gabriela Nino de Rivera Torres: VoiceOver+Safari.
    The search box it is very well hidden, VoiceOver did not notice it.

    Michelle DeYoung: Windows 8.1 / FF 40.0.3 / NVDA 2015.2
    Keyboard only: Yes, it works.
    FF/NVDA: Yes, Search box is hidden and not voiced by screen reader.

    9. Add choices automatically

    Gabriela Nino de Rivera Torres: VoiceOver+Safari.
    I was able to add choices using the coma and the space. The combo box does not respond to Control+Option+Space bar VoiceOver command to open the list of choices. It does respond to the space bar key and the Enter key.

    Michelle DeYoung: Windows 8.1 / FF 40.0.3 / NVDA 2015.2
    Keyboard only: Yes, it works.
    Note:
    Using space – Cannot add more than two rows of items.
    Using comma – Cannot fill past one row of items.

    FF/NVDA:
    Yes, can add items with space or comma, and they will appear in the list.
    If too many items are added to the list they are dynamically removed except for the first item.
    >Note:
    Using space – Cannot add more than two rows of items, but NVDA will still voice like items are being added.
    Using comma – Cannot fill past one row of items, but NVDA will still voice like items are being added.
    Items – Items in list are announced as “blank”.  Items added to the input are also not announced.

    Notes from Bram Duvigneau

    I had a quick look at Select 2 using Firefox + latest NVDA nightly build.

    The Select 2 widget is announced as combo box, however it doesn’t respect the common keyboard navigation conventions on Windows. I expect to be able to use the arrow keys to select an item when the select box is in closed state, that doesn’t work. The alt+down arrow hotkey, which is the default to open a dropdown in Windows, works. However, when the select box is open, the active item is not announced by a screenreader. I can select an option by pressing enter and after closing the box the selected item is readable.

    Conclusions: It seems that some aria support has been implemented. This causes a screenreader to pick up the role (select box) and the state (open/closed).
    However, much more work is needed to support the focus in an open Select 2 widget. All the special Select 2 features such as grouping items and typing to filter/search the list has not been tested, but this also needs additional aria markup to be read by screenreaders.

    Another issue is the expected keyboard shortcuts. These are different on every platform and Select 2 should feel native on all of these platforms, so this has to be implemented and tested prety well. E.g. on Windows I don’t expect a dropdown to open when I press space bar, but on Mac this is the common way to open such an element.

    Notes on the test results by Andrea Fercia

    • Difficult to understand how to open the combo box. Users expect to open the combo box using just the down arrow key. Previous version worked that way.
    • Missing label for the input field (The text input in the expanded list is not labelled). It gets announced with the name of the first option, e.g.: “Alaska  combo box  collapsed  has auto complete”. Investigate on current usage of “aria-labelledby”.
    •  Searching:
      • leaving the field empty, it is possible to arrow through the items in the list but every option gets announced as “blank”
      • entering some charavters e.g. “mi” and arrowing through the results e.g. “Minnesota”, “Mississippi”, “Missouri” will read out just “mi” which is the entered value in the input
      • no feedback about how many search results – the previous version announced “5 results are available, use up and down arrow keys to navigate” or “No matches found”.
    • “I could not find how to select an option of the list of choices”. I guess that’s because all you hear is “blank” or the characters you entered in the search field.
    • No feedback when selecting an item: If user randomly selects and item (they will not know what they selected), the items are added to the input field, but they are not announced.
    • Multiple select boxes: “Unable to access added items in the input to have them announced.  If I assume items exist in that form field, then I can select “Backspace” to remove them a letter at a time.”Once you’ve added options, they’re not announced so users really have to guess they’re in the input field.

    Conclusion

    The main problems are:
    • There is no or not enough feedback for screen readers on what is selected or what can be selected (list items are announced as “blank”.)
    • No feedback about how many search results.
    • The select dropdown does not behave like a user expects, quoting Bart: “It is really not intuitive to require a space bar in a combo box.This is something I would never have tried by myself”
    • Testers report slightly better results on iOS + VoiceOver
    • Select2 has at the moment too many accessibility issues to be included into WordPress core
     
    • Rian Rietveld 2:19 pm on September 7, 2015 Permalink | Log in to Reply

      Updated the test results for iOS + VoiceOver by Cyndy Otty and Philip Chalker

    • Rian Rietveld 6:11 am on September 8, 2015 Permalink | Log in to Reply

      @joedolson opened an issue about this test result on the Select 2 GitHub: Accessibility issues in Select2: https://github.com/select2/select2/issues/3744

    • Graham Armfield 8:56 am on September 8, 2015 Permalink | Log in to Reply

      This is an impressive test and presentation of results – well done everyone.

      I’ve been doing some testing recently with Dojo UI components and Dragon NaturallySpeaking voice recognition software, and that testing has underlined some real accessibility issues when controls try to emulate select elements.

      I will endeavour to find some time in the next couple of days to test out Select2 with Dragon, and circulate the results.

    • chriscct7 1:31 pm on September 8, 2015 Permalink | Log in to Reply

      Fantastic job guys. I’ll help monitor the ticket where I can and update the trac tickets currently blocked on Select2

    • NateWr 3:16 pm on September 8, 2015 Permalink | Log in to Reply

      This kind of results reporting is eye-opening. Thanks for the detailed write-up.

    • Aaron Jorbin 10:30 pm on September 9, 2015 Permalink | Log in to Reply

      Thanks to all the testers. Very impressive work here. Irregardless of if WordPress will include select2, hopefully these results inform the Select2 team and help them create a better, more accessible product. Has anyone sent these results over to them or otherwise alerted them so that they know about the findings?

    • Rian Rietveld 7:11 am on September 10, 2015 Permalink | Log in to Reply

      Hey Aaron, yes, @joedolson opened an issue on the Select2 GitHub: https://github.com/select2/select2/issues/3744 which was received well and commented on and we even invited Mike Gifford from Drupal to join the discussion.

    • Graham Armfield 7:46 am on September 11, 2015 Permalink | Log in to Reply

      Yesterday I did some testing of Select2 using Dragon NaturallySpeaking – voice recognition software used by many people with motor impairments, and here are my results.

      I was using Dragon 14 Professional on Windows 8.1 with IE11. Dragon 14 (like Dragon 13 before it) features some support for ARIA although that is still evolving.

      Basic Dropdown

      The control looks like a dropdown but Dragon does not recognise it as such. Command “Click List Box” does not cause the control to be selected as would be expected with a real select box. “Click combo box” does not select the control either – technically it’s not a true combo box but you can type to refine search so I thought I’d try that.

      It is possible to “tab” to the control from other items, although “shift-tab” seems flaky.

      When focus is on control the commands “Show Choices” and “Expand List” do work as expected, although “Hide Choices” does not close up the selections as expected.

      It is also possible to use the “Mouse Grid” commands to click on the item – which opens up the list of choices. When the options are shown, it is possible to voice a state name and have that state name shown. Voicing an option that is not in the list does give the ‘No results found’ message.

      When options are shown it is possible to move through the options using the “Move down” or “Move up”. I can select an item by saying “Press Enter”. The list is collapsed.

      Multiple Select Boxes

      The Control look like a text box as there is no arrow icon associated with it. It is not obvious that I can select multiple items – presumably a label would prompt that.

      “Click Type Text” does work here so Dragon thinks it’s a text box. “Click List Box” does not work.

      It seems not to be possible to “shift-Tab” into the control with Dragon. But forward tabbing seems to work OK.

      Once the ‘select’ is open, as before I can use “Move Up/Down” commands to move through options and “Press Enter” to select one.

      Speaking the state name does not work properly though – only the last letter of the word I said is shown, and the state is not highlighted. The full word is present though – saying “Backspace” reveals the rest of the state name minus the last letter. Usually the state name you want is featured in the list below.

      To select multiples states with Dragon is possible, but you need to treat each additional state as a separate interaction.

      Trying to delete previously selected items using “Backspace” doesn’t work well at all in Dragon. You get partial state names, and for some reason Dragon will consistently interpret multiple “Backspace” commands as a command to go back to the previous page. This does not happen when interacting with text in normal text boxes.

      Actually it seems there is no way to delete previously selected items with Dragon. Using “Mouse Grid” or “Mouse Move” commands to home in on the small x (a very small click target) is possible, but then when the “Click” commands are spoken, the item ‘hovered’ over is not removed and the cursor is placed after the last previously selected item. With “Press Click”, the words appear in the text box. Somehow the control is interfering with how Dragon operates.

      Placeholders

      Not relevant for Dragon.

      Disabled Mode

      Yes I can enable/disable controls using the buttons in Dragon.

      Disabled Results

      The second option is missed out when I command Dragon to move up and down through the selection. So works OK.

      Select with a button

      I can issue commands to press the buttons OK and the desired result is achieved. However, when I mouse click any of the buttons they turn blue – this doesn’t happen when actioning the buttons with Dragon.

      Limiting the number of selections

      Yes that works OK

      Hiding Search Box

      Works OK

      Add choices automatically

      This doesn’t work well.

      I only seem to be able to interact with the control if I emulate clicking on it – using Mouse Grid. Tabbing to the control gives me the focus indication, but I can’t interact with the control until I emulate clicking on it.

      Clicking on the field opens up the list of options. I can select them successfully as with multiple select boxes.
      However, when I speak an option I run into the same problem as earlier, only the last letter of what I’ve spoken is shown – along with the same issues with backspacing.

      Issuing the “press enter” command does show what I have spoken, but when I “tab” away from the field my input disappears.

      Summary

      Most functionality is available to Dragon users when using the full variety of voice commands available, although it is not as straightforward as using native HTML controls – since they can’t always be referenced by type.

      However, deleting previously selected items is not possible with Dragon 14 using the Multiple Select functionality, and when adding choices automatically.

      The Add choices automatically functionality cannot be used either.

    • Rian Rietveld 7:53 am on September 11, 2015 Permalink | Log in to Reply

    • Sharon Austin 1:48 pm on September 11, 2015 Permalink | Log in to Reply

      This report….is a thing of beauty. Love it.

  • Joseph Karr O'Connor 8:15 pm on August 31, 2015 Permalink
    Tags: accesibility, ,   

    Team Chat Summary August 31, 2015 

    Headings

    More work is being done on headings in admin. Jeffrey de Wit created some tickets some of which are already patched and committed. Follow the headings discussion in #accessibility on Slack.

    Handbook

    Devised a strategy for building out the Make WordPress Accessible Handbook. Page leaders will help others build out the handbook.

    Twenty Sixteen

    Twenty Sixteen is on Github. Twenty Sixteen is also available in the theme directory. It’s not in trunk yet. According to David Kennedy ” I did a accessibility-ready review before it went on Github and the directory to make sure nothing was way off accessibility-wise. It’s solid. Takashi knows the drill.” We will ask the testers to test it. David Kennedy did an #accessibility-ready audit of Twenty Sixteen.

    Select2

    We continued a discussion about Select2 as an alternative to the autocomplete/tagging input field types. There are two main accessibility issues: it doesn’t do a good job of providing feedback to screen readers and it requires the ‘enter’ key to begin typing for autocomplete, a non-standard interaction. The testers have tested Select2 and it is not very accessible. Rian Rietveld will collect all the data and report next week.

    WordCamp US

    Several of us are submitting proposals for talks at WordCamp US and depending on funding assistance some of us will be attending. Today is the last day for submitting proposals.

     
  • Joe Dolson 4:39 pm on August 28, 2015 Permalink  

    Congratulations to Andrea Fercia on gaining guest committer privileges for the WordPress 4.4 release cycle! This is great news for WordPress and accessibility!

     
  • Joseph Karr O'Connor 5:03 am on August 13, 2015 Permalink
    Tags: , ,   

    Team Chat Summary August 10, 2015 

    New Structure Proposed

    Rian Rietveld wrote a proposal on how to structure our work better and plan ahead longer and we discussed it. What follows is examples from the proposal.

    Goals and Issues

    This will be a separate page on make/accessibility and also a main menu item. It gives an overview of our goals for the accessibility of WordPress, the work we (want to) do, how this is organized, how we test, a roadmap for the next year and how we track the progress of issues we are working on. An example of the roadmap for release 4.4:

    Release 4.4 (December 2015, Scott Taylor)
    • Finish still open issues focus from 4.3
    • Semantic heading structure Admin
    • The customizer
    • Handbook
    • Twenty Sixteen (?)

    Central Ideas

    Some central ideas also included in the proposal are keyboard focus, work on the handbook, color contrast, system to better follow tickets including splitting up tickets among team members on which to concentrate, and continue to develop code pattern library. Much more is included in the proposal and for now we will continue to work on the proposal to make it a more formal document to cover our activities over the next year.

    We also talked about the fact that having a planning document to refer to does not obviate the need to address all new features since there is a tight turn around towards the end of a cycle because that’s when the features going into the release are announced. If we don’t follow all new features we might miss one or more that advance to release at the very end.

    When we have it shaped up we will add the planning documentation to this blog in the form of pages and sub-pages to make it a community resource.

     
    • Samuel Sidler 1:43 pm on August 27, 2015 Permalink | Log in to Reply

      Just wanted to say that I love the idea of a longer term goals for this team! Short term goals are great, but it’s nice to be able to see the short term goals in context of where everything is headed. 🙂

  • Rian Rietveld 12:15 pm on August 3, 2015 Permalink
    Tags:   

    Accessibility Usertest: Export XML file 

    We wondered if people, using assistive technology, could understand the structure of selecting a range of posts or page in the export option with Tools/Export in the Admin.
    Related ticket: #33046

    Tests done on WordPress 4.3 beta 4 Nightly build from Juli 23 up to July 30 2015

    We asked the testers:

    Log into the test WordPress install and go to: Dashboard / Tools / Export
    Or directly to [..]/wp-admin/export.php
    Here you can download an export file with the content of the website.

    Export XML screen with options

    Select posts with:

    • Category “Uncategorized”
    • Authors: mwa
    • Start date: April 2013
    • End date: Januari 2020
    • Status: Publish

    And download the Export file.

    We want to know:

    • Can you do it? Or did you get stuck somewhere?
    • Did you understand how to select the posts and how to access the selection fields?
    • If there was anything you didn’t understand, please share.

    The testers who joined:
    Stephanie Watts, Heather Migliorisi, Daniel Montalvo Charameli, Cyncy Otty, Ruth Nisenbaum, John Sexton, Geof Collis, Shaun Everiss, Tobias Clemens Häcker, Michelle DeYoung

    Results

    No assistive technoloy

    Ruth: No problems at all

    Keyboard only

    Heather:

    • Chrome/Mac: worked well
    • Chrome/Mac: worked well
    • Safari/mac: worked well
    • FireFox/Mac: it is impossible to see what the focus is (the highlighting I see in the main menu in Chrome is not visible in FF)

    Michelle: Window 8/ FireFox: Works

    VoiceOver

    Heather:

    • Chrome/Mac – there’s no connection between ”All content” and the description below it (maybe add aria-describedby to link them)
    • Safari/Mac – The selects (categories, authors, ect) do not have labels linked (missing the for=“id”), so you have no idea what the drop downs are for.

    Cyndy: Safari – No problems navigating through and downloading the XML.

    SuperNova

    John: Windows 7 64bit PC using IE11 & Supernova 14.05
    I found it easy to use and select the options from the dropdown boxes. I have attached the downloaded file just for reference. You may also be pleased to hear using the same setup I have previously been able to use the import feature again with no difficulty

    Jaws

    Geof: JAWS 14.9/IE 11
    No problems at all, usually when I try to download all content my browser chokes.

    NVDA

    Shaun: NVDA latest version, Firefox, internet explorer latest builds and windows 7.
    Ok I was able to download the file no problem, everything worked.

    Michelle: Windows 8.1 /Firefox. I am getting inconsistencies when moving through the radio button and the fields under each other. Coming into the screen initially in virtual mode the radio buttons are announced as unchecked when navigating through them. When using the spacebar to select Pages or Posts, the number of items that unfold under them are announced when arrowing. I am unable to tab to them without being jumped to the Help button. If I tab again after the Help button, the focus is taken to the radio button and I hear a tone that signifies it is now in forms mode and I can then tab to the items in the section.

    When I navigate back to the Page or Post radio button it will say that it is selected, however I cannot arrow to the content for that section, but I can tab to the fields (poses a problem if you don’t know those items exist in the section). The arrowing will just take me through the radio button selections.

    Chrome Vox

    Tobias: Windows 7/ Chrome/Chrome Vox
    Worked perfectly, no issues at all.

    Window-Eyes

    Stephanie: Window-Eyes v. 9.2 screen reader along with ZoomText v. 9.0.
    I was able to complete the test.  For Window-Eyes, selecting combo box items requires users to move to the desired selection, press Enter to “activate” the combination (combo) box, use the arrow keys to move to the desired choice, then press Enter on that choice. Once I made my first choice, I tabbbed to the next option and repeated the process through completion of the task.

    Although I understood the directions, I am fairly proficient with Window-Eyes and a little less proficient with the NVDA screen reader. That said, I believe a “proficient” screen reader user would approach this task in a different manner than someone less proficient with screen reader applications. The more proficient user, for example, will try different strategies to achieve the goal whereas a novice screen reader user might conclude the WordPress application is not accessible if he/she fails to achieve the goal on the first or second attempt.  Consider creating instructional materials that specify to the screen reader the goal (e.g., select posts, uncategorized, dated from April 1, 2015 through April 30, 2015). Then you can specify that the method for selecting options depends on your specific screen reader application. This will free WordPress from the challenges associated with creating keystrokes specific to a particular screen reader application.

    Code reviews

    Daniel: In general it is easy to follow but I’ve got concerns regarding the way “Date range” combos are labeled. I think both <select> should have labels (the first being “Start date and the other being “End date”).
    Since “Date range” has been utilised as both visual and screen reader label, this is good. This gives a basic understanding of both lists, but I would deep a little bit on this by labelling both lists and hiding the complementary label information via the .screen-reader-text class or whatever is the method of your choice.
    I personally would not use “start date” and “end date” as the first selectable options, but as the complementary tags for screen reader users mentioned above.

    Summary test results

    Most testers had no severe problems.

    The issues that where mentioned:

    • FireFox/Mac: it is impossible to see what the focus is (the highlighting I see in the main menu in Chrome is not visible in FF)
    • Missing missing the for=“id” with the label for the select dropdowns
      <label>Categories:</label> <select name=”cat” id=”cat” class=”postform”>[..]</select>
    • One label “Data range” for both select <select name=”post_start_date”> and  <select name=”post_end_date”>
    • Tab order in NVDA is messed up (Michelle)

    Recommandations

    • Check the visual focus on the radiobuttons
    • Add a for= to the labels to link them to the select field
    • Find a different label structure for the data rage select fields
    • Try if Michelle’s NDVA navigate issues can be reproduced, and why this happens.
     
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
Skip to toolbar