WordPress.org

Make WordPress Accessible

Tagged: testing Toggle Comment Threads | Keyboard Shortcuts

  • Rian Rietveld 4:37 pm on February 25, 2016 Permalink
    Tags: , , testing   

    Accessibility Usertest Create and edit links inline 

    In WordPress version 4.5 there will be a new way of adding links in the content: create and edit links inline. The URL input and the search field are now one and the same.
    This is similar to what Google Docs does. Search results are shown as an autocomplete dropdown.
    Related ticket: #33301.
    The test are done from Februari 18 until Februari 24 2016.

    Conclusions are at the bottom of this post.

    To test this for accessibility we set up a WordPress 4.5-alpha nightly install.
    And asked our testers:

    • Can you access the little window with the input field for the link
    • Can you understand how to add a link using this inline window
    • Can you understand how to search for a page using a search word using this inline window
    • Is this usable with your assistive technology?
    • If you use a screen reader: can you hear the search result if you enter a search word instead of an URL
    • Are you missing functionality to make this work for you
    • Which browser and operating system did you use (for example Safari on Mac)
    • Which assistive technology did you use for this test

    Testers who joined: Jeff de Wit, Geoff Collis, Tobias Clemens Hacker, Reagan Lynch, Ruth Niesenbaum, Gabriela Nino, Michele DeYoung, Sirisha Gubba, Wim Moons and Marco Zehe.

    Test results for keyboard

    Wim Moons: Windows7 & FireFox with loupes.
    If you type a word, a list appears. If you walk through the list with the arrow keys the text in the search field disappears. I found this confusing.

    Geoff Collis: JAWS 14.5 IE 11
    A bit confusing at first but I managed to do it. I wasn’t sure what happened, all I heard was “apply” after doing it so moved around and found out I could type the url, needs some work to let me know where I was after the keystroke command.

    Of note:, when I first typed in the url and used tab to go to the apply button it didn’t work, took me right out of the edit box, when I came back I was able to get to it by tabbing this time.

    Jeff de Wit: In Firefox, with just a keyboard:
    You specifically have to tab to the submit button to add the link without issues. If you press Enter on the input field, it will also add a linebreak where the cursor is when you opened the link dialog (in addition to adding the link). Here’s a video of that:

    What I’m doing in the video:

    • Select some text
    • Hit Ctrl + K to open the link dialog
    • Type in the URL for Google
    • Press Enter
    • Press Ctrl + Z to “revert” the random line break that appears

    Also not super clear how to remove the link this way, since you can’t actually get to the pencil / remove icons. It’s not impossible to remove links though, but not sure how “obvious” it is that you can also remove the URL text and hit apply to remove the link.

    Michele DeYoung: Firefox 44.0.2 and Windows 10.
    Using the spacebar instead of Enter when creating a link using the keyboard will make it so a line break does not occur after the text link.

    Test results for screen reader

    Jeff de Wit: In Firefox, with NVDA enabled:
    It seems to announce really well. It even makes it clear when you’re moving your cursor to a link. Not sure if it’s a good idea here to also announce what URL it’s linking to (Not what links usually do, and it may add too much noise, but it’s editing content and it may help with spotting broken/mistyped links).

    One thing I did notice though, is when I hit the “Advanced” button NVDA only announced “alert” for me. It doesn’t say anything about the text field I have focus on (even though it’s supposed to, and I do see it in the NVDA speech log, so it may be related to my NVDA settings).

    Gabriela Nino: Mac + Safari + VoiceOver

    • After using cmd + k to open the window: The window opens but Voice Over does not announce it. So is not clear for a non sighted user what exactly is happening.
      Right after the window is opened, the focus is supposed to be on the URL input text. But this behavior is not consistent, the focus is sometimes on the input text and sometimes not. When is not on the input text, I managed to give it focus using the tab key. But a non sighted user might not be able to figure this out.
    • Voice Over is sometimes announcing the input text placeholder, but mostly of the times it does not.
    • On the advanced window, when searching for existing content, Voice Over does not announce the results found.
    • It was impossible to access to pencil / remove icons, tried using cmd+k but instead of allowing me to access the pencil and remove icons, it opens the little window with the input field for the link. Without mouse or when using Voice Over, I’m not able to select those icons.

    Michele DeYoung: Firefox 44.0.2 and Windows 10.

    I can understand how to add a link using this inline window, but only if the focus is in the url input field. After adding multiple links, when other text is selected to create a link, the inline window focus was on the last element in the window that was used, for example – the Advanced button. This will be confusing for screen reader users when the window launches and it voices “Advanced” or “Apply.”

    Note: When the inline window opens and the last focus was on the Advanced button or Apply button, and Advanced is selected, the pop-up for the Advanced selection will open, however, the keyboard focus remains in the window behind it. Keyboard focus is correctly in the pop-up when the starting focus point in the inline window is in the input field.
    The pop-up is not announced as a dialog, and a heading should be announced with it.

    Advanced Pop-up: When the search is entered, if I tabbed I would go to the results container, however, NVDA would just voice that number of items in the list. It would be helpful to know that it is the results list. When arrowing through the list each item was voiced.

    Another way: when using the down arrow to move from the search entry, I can move into the search results list (still not clear that it is the results list), but when I arrow to each item in the list I just hear the search entry repeated for each one.

    Tobias Clemens Hacker: Chrome Vox/ Chrome on Windows 7
    The buttons have no distinguished voice output. I don’t know which one is “Apply” and which one is “Advanced”. For some reason the aria-label in the containing div is not being output.
    I miss distinguished voice output for the buttons.

    Reagan Lynch: Windows 7 running IE 11 with JAWS 17.
    If I paste a link into the text field the raw link appears in the text of the post, but the word I highlighted is a link with the link pointing to <a href=”http://example.com”>highlited text</a>
    I was unable to insert a link using the new method. I was able to get into the advanced dialog like we currently have, but only after pressing ctrl+k and then arrowing right and exiting forms mode, and then my text highlight was gone.

    Sirisha Gubba: IE and FireFox with NVDA

    • I can access the window with keyboard in FF but not in IE. AT with short cut keys provided
    • I can’t understand with NVDA as it announces “Toolbar” and focus is taken to the apply button.
    • I can see the placeholder in FF. With NVDA it is not announcing as soon as the small window gets opened but if user uses back arrow it reads the instruction.

    Ruth Niesenbaum: Chrome and NVDA with Windows 10.
    It was not clear how to enter data: I started entering a word and it did not tell me that it found options, when I went down to the options it did not read them loud so it does not say the When I press the down arrow and enter the list of urls it says : unknown 2 of 7 and it does not read the name of the post

    Conclusions

    Some issues are already fixed in the current version, using these test results.

     

    The issues that remain are according to @afercia (Andrea Fercia)

    Reagan Lynch Using Windows 7 running IE 11 with JAWS 17:

    If I paste a link into the text field the raw link appears in the text of the post, but the word I highlighted is a link with the linnk pointing to
    highlited text

    Andrea: after last changes I’m not even able to insert a link with IE 11

    Jeff de Wit:

    If you press Enter on the input field, it will also add a linebreak

    Andrea: maybe fixed, but I’m pretty sure it still happens when *pasting* a link in the input field and then pressing Enter

    Also not super clear how to remove the link

    Andrea: totally agree

    Michele DeYoung: NVDA Firefox 44.0.2 and Windows 10.

    Using the spacebar instead of Enter when creating a link using the keyboard will make it so a line break

    Andrea: it’s a legitimate expectation since it’s announced as “Button” it should work also with spacebar

    Jeff de Wit: In Firefox, with NVDA enabled:

    when I hit the “Advanced” button… (it’s about the Advanced modal dialog)

    Andrea: yeah, the link modal dialog still needs some a11y treatment. We should fix that but it’s a bit unrelated

    Gabriela Nino: Mac + Safari + VoiceOver

    It was impossible to access to pencil / remove icons, tried using cmd+k but instead of allowing me to access the pencil and remove icons, it opens the little window with the input field for the link. Without mouse or when using Voice Over, I’m not able to select those icons.

    Andrea: we should make more clear the Alt+F8 shortcut, maybe it’s a bit confusing now

    Gabriela Nino: Mac + Safari + VoiceOver

    After using cmd + k to open the window: The window opens but Voice Over does not announce it. So is not clear for a non sighted user what exactly is happening.
    Right after the window is opened, the focus is supposed to be on the URL input text. But this behavior is not consistent, the focus is sometimes on the input text and sometimes not. When is not on the input text, I managed to give it focus using the tab key. But a non sighted user might not be able to figure this out.
    Voice Over is sometimes announcing the input text placeholder, but mostly of the times it does not.

    Michele DeYoung: NVDA Firefox 44.0.2 and Windows 10.

    I can understand how to add a link using this inline window, but only if the focus is in the url input field. After adding multiple links, when other text is selected to create a link, the inline window focus was on the last element in the window that was used, for example – the Advanced button. This will be confusing for screen reader users when the window launches and it voices “Advanced” or “Apply.”

    Andrea: totally agree, already in my list

    When using the down arrow to move from the search entry, I can move into the search results list (still not clear that it is the results list), but when I arrow to each item in the list I just hear the search entry repeated for each one.

    Andrea: works for me using Firefox + NVDA

    Andrea: additionally:

    • after 36703 in IE 11 can’t insert a link
    • we’d recommend to add an audible confirmation message when a link is successfully inserted from the inline toolbar; also, when a link is successfully selected in the advanced modal dialog; of course messages need to be different since in the modal the link is inserted only after users press the “Update” button

    And further: For next tests we will ask the test team not to test with ChromeVox anymore. This screen reader is too limited in functionality. And if a tester uses NVDA: the preferred browser to use with this screen reader is FireFox.

    Update March 2, 2016: additional tests

    Marco Zehe: Safari and Chrome on OS X with VoiceOver. That is, Chrome + VoiceOver, not ChromeVox.

    I can confirm the brokenness of the search results when arrowing up and down. I do get the focus into the combobox consistently, though. And here’s the thing: In Chrome, while that has a nasty bug with no text being read out when typing or arrowing, the search result widget works. So whatever is going wrong has something to do specifically with Safari’s interpretation of WAI-ARIA.

    A few ideas:

    1. I assume you are using aria-activedescendant when pointing at the various search results when arrowing up and down, right? Are you also adding tabindex=”-1″ to these role “option” items to make them focusable, but not include them in the tab order? If not, add them ad see if that makes a difference.
    2. Are you using aria-owns? If so, that may be interfering somehow, see if you can do without that.
    3. Or are the items spoken via a live region? I do not know the code, so these are just some things that popped into my mind as possible reasons.
     
  • Rian Rietveld 7:13 pm on November 10, 2014 Permalink
    Tags: testing   

    Design of the on focus admin menu and plugin activation links Test session Nov 10, 2014 

    This week we discussed two tickets in our weekly test session.

    #28599 Better Visual Focus Indication in Admin Menu:
    @florianziegler, @afercia and @michaelarestad designed proposals we discussed. @michaelarestad came up with a mockup that needs more contrast but is beautiful.
    We will discuss this further with the ticket and on Wednesday at the a11y team meeting (Nov 12). Hopefully some designers can join in to give their opinion.

    #26167 Plugin activation links need to contain plugin name and the “Plugin” column should be marked as row header:
    There is a new patch, a refresh of the one by @bramd. @arush tested it with a screen reader and it works perfectly.

    And from today Slack is also accessible for a screen reader, so @arush could join us in the chat.

     
  • David A. Kennedy 6:11 am on May 2, 2014 Permalink
    Tags: testing   

    WordPress needs automated accessibility testing 

    The Make WordPress Accessibility Team needs help wrapping its arms around WordPress Core as new features get created while helping refine the existing codebase to make it more accessible to people with disabilities. Our small team can’t be everywhere and test everything, but we’re working to gather an accurate picture of what needs our help the most.

    Once we have a better idea of what needs our attention the most, how do we maintain a good grasp of it? Automated accessibility testing can help in a big way here, and I’d like to start working to incorporate it into Core. I brought this up in our last Accessibility Team chat.

    What’s automated accessibility testing? Similar to unit testing, this would allow developers to run a set of tests during their local development workflow of patches for WordPress via a command line tool. These tests would output results that would alert developers to potential errors and help them fix things like missing alt attributes or unassociated form fields and labels. Automated accessibility testing isn’t perfect and it won’t help us overcome all of our challenges, but it can help us find simple, easy-to-fix errors, alert us to large trouble spots within the codebase that need more manual testing and allow us cover a bit more ground. It’s a nice compliment to the manual testing and education we’ve done so far.

    What do we need to consider when selecting a tool?

    WordPress Accessibility Team member Karl Groves has a nice blog post about this. He says you should consider three things:

    1. Flexibility and Freedom. These tools exist for one reason only: to work for you. Every single second you spend learning the UI, figuring out how to use it, or sifting through results is a second of development time that could go into actually improving the system. The tool must be flexible enough to offer the freedom to use it in any environment by any team of any size in any location.
    2. Accurate. Developers of accessibility tools want to find every single issue they possibly can. This unfortunately often includes things that are, in context, irrelevant or of low impact. They also may require an additional amount of human effort to verify. This is a disservice. Tool vendors need to understand that their clients may not have the time, budget, or knowledge to sift through false positives. The user should be able to immediately eliminate or ignore anything that isn’t an undeniable issue.
    3. Understandable The user of the tool needs to know exactly what the problem is, how much impact the problem has, where it is, and how to fix it. Overly general, overly concise, or esoteric result descriptions are unhelpful. If a tool can find a problem, then it can make intelligently informed suggestions for remediation

    I think these are good goals to try to hit. Ideally, we want something that will have little to no impact on a developer’s workflow, allow us to select different test criteria and deliver accurate results we can act on.

    As research, I’ve spoken to Jesse Beach. She’s a Senior Front End Engineer at Acquia Inc., a Drupal contributor, a contributor to QuailJS (a tool Drupal uses for automated accessibility testing) and a member of the Drupal Accessibility group. She’ll help us look at QuailJS as a possible automated accessibility testing approach. And hopefully, we can share accessibility knowledge between these two awesome open source projects! We talked about what we (WordPress Accessibility Team) want to accomplish with automated testing, how a tool might fit into a WordPress developer’s workflow, the future of QuailJS and a bit about accessibility in our different open source projects.

    One other possibility on the short list of tools besides QuailJS includes Pa11y. We will likely look at others as well.

    Next steps

    • Firm up a list of requirements for a tool
    • Experiment with some tools
    • Meet with Core team members to discuss
    • Develop test criteria

    Your ideas and feedback are welcome!

     
    • Aaron Jorbin 5:55 pm on May 5, 2014 Permalink | Log in to Reply

      I like the idea of expanding our automated tests. For each of the possibilities (QuailJS, Pa11y possibly others), I think it would be good to lay out the requirements, benifits and costs.

      Personally, I would like to see whatever tool we use fit into our existing testing flow. This means that it could be run from the command line so that we can run the tests on travisCI and as a part of the grunt precommit command.

      • David A. Kennedy 3:24 pm on May 7, 2014 Permalink | Log in to Reply

        Integrating into the existing testing flow is a high priority, probably only below selecting a tool that has accurate, configurable tests.

        Do we have guidance on selecting or integrating with tools that may not be fully open source. For instance, maybe the tests we write/modify are all open source, but we hit a third-party api to actually get results that isn’t open source.

        Selecting something that’s fully open source/GPLV2 compatible has preference of course, but I thought the question is worth asking.

    • Matthieu Faure 8:10 pm on May 9, 2014 Permalink | Log in to Reply

      Hi David,

      I’m interested in accessibility, WordPress and testing. I’m a follower of @WPaccessibility and I’ve read the last “Accessibility Team Updates” on the blog. Here are a few information you might find helpful for the topic.

      You could find some help with Tanaguru, an opensource accessibility checker (disclaimer: I’m its creator). Tanaguru offers different kinds of audit like page and site-wide audit, but for the expressed need to test the backoffice of WordPress with ATAG, you could use the “scenario audit”. For short, you record a scenario a user could follow (e.g. creating a post, adding an image, modifying the alt, publishing), and send it to Tanaguru, that in turn replays it. Scenario can be replayed when you want. (Technically speaking, it is based on bricks of Selenium.)

      For the needs of automation, you can also plug it with continuous integration tools. We are actually playing with our own Jenkins (that we use for building Tanaguru).

      Here are a few links (hope they’re ok for comments):

      We know a bit WordPress as it runs our corporate site and our blog. I’d be really happy to contribute to “Make WP Accessible”.

      Hope to exchange with you soon on the subject

      Matthieu

      • David A. Kennedy 2:15 am on May 13, 2014 Permalink | Log in to Reply

        Hi Matthieu,

        Thanks for your comment and for filling us in about Tanaguru. It definitely sounds like it should be on the list. I’ll add it and we’ll take a closer look once we get to that point.

        My contact info is on my site. Feel free to reach out.

  • Graham Armfield 5:46 pm on March 24, 2014 Permalink
    Tags: , , , , , testing,   

    Digital Accessibility Centre Visit – Part 3: The Blind Perspective 

    This is the third post documenting a recent visit to Digital Accessibility Centre in Neath, South Wales organised by fellow team member Siobhan BamberThe first post can be found here, and the second post here.

    Three of the staff from DAC gave us feedback on using the WordPress admin screens. Each of the three have a particular impairment, and the visit was a valuable opportunity to learn about ways we could improve WordPress for everyone.

    In this post we take feedback from Carly who is totally blind. She showed us how she used a screen reader and gave us some great feedback on using the WordPress admin screens with a screen reader.

    (More …)

     
    • ceo 6:19 pm on March 24, 2014 Permalink | Log in to Reply

      Looks like there’s lots to chat about. 🙂

      It is important to let people know when a new panel or window is to open – eg Add Media.

      I’ve only been saying this for, well, ever. Though, to be fair, it was even worse before when these kinds of things popped up and you literally could navigate out of the window with the screen reader but still have it open. (At least, I don’t encounter the issue any more, personally. It might still be broken in some places.)

    • _Redd 8:09 pm on April 1, 2014 Permalink | Log in to Reply

      Graham, this is sheer gold. I hope we can chat about this in the next IRC meeting. Thanks again for everything you’ve done here.

  • Graham Armfield 2:40 pm on March 24, 2014 Permalink
    Tags: , colour contrast, , testing, text resize   

    Digital Accessibility Centre Visit – Part 2: Poor Vision 

    This is the second post (of three) documenting a recent visit to Digital Accessibility Centre in Neath, South Wales organised by fellow team member Siobhan Bamber. The first post can be found here.

    Three of the staff from DAC gave us feedback on using the WordPress admin screens. Each of the three have a particular impairment, and the visit was a valuable opportunity to learn about ways we could improve WordPress for everyone.

    In this post we take feedback from Gary who has poor vision.

    (More …)

     
  • Graham Armfield 10:54 am on February 4, 2014 Permalink
    Tags: ah-o2, help, testing   

    AH-O2 Accessibility Testing 

    I’ve been doing some accessibility testing with version 0.4.0 of the AH-O2 plugin which adds tooltips to some links and input fields within the admin area where it’s felt appropriate.

    I’ve commented on my findings directly into the Docs blog. You can see my comments here: https://make.wordpress.org/docs/2014/02/04/ah-o-update-3-february-2014/

     
  • Graham Armfield 11:30 am on November 28, 2013 Permalink
    Tags: , , testing   

    Analysis of what gets into the alt and title attributes when adding an image into a page/post 

    There was some debate in last night’s IRC chat about trac ticket 26270 raised by @yaelkmiller. Her original point was that when adding images to pages and posts, the Alt text box should have more prominence than the Title box – the alt attribute being an important accessibility feature.

    Personally, I think the idea is a good one, but discussion and comments by @helen also revealed some interesting behaviour when inserting images concerning what text ends up in the title attribute of the image, and what text ends up in the alt attribute.

    I’ve done a series of tests using different use cases and they are presented in the tables below – including my expected results and the actual results.

    Uploading images

    Test No. Use Case Graham’s Expected Result Actual Result in Page
    1 Upload image, add it to page with no change to Title box or Alt text box Title attribute set to image name minus suffix Title attribute absent, alt attribute set to image name minus suffix – ie what the Title box was set to
    2 Upload image, add it to page but change Title box, not Alt text box Title attribute set to amended value Title attribute absent, alt attribute set to amended Title box value
    3 Upload image, add it to page but change Alt text box, not Title box Title attribute set to image name minus suffix, alt attribute set to amended value Title attribute absent, alt attribute set to amended Alt text box value
    4 Upload image, add it to page but change both Alt text box and Title box Both title and alt attributes set to amended values Title attribute absent, alt attribute set to amended Alt text box value

    Using images from media library (previously uploaded) without amendment

    Test No. Use Case Graham’s Expected Result Actual Result in Page
    5 Add image from media library that has Title box set but not Alt text box Title attribute set but not alt Title attribute absent, alt attribute set to whatever Title box was before
    6 Add image from media library that has Alt text box set but not Title box Alt attribute set but not title Alt attribute set but not title
    7 Add image from media library that has both Title box and Alt text box set Both attrubutes set Title attribute absent, alt attribute set to whatever Alt text box was before
    8 Add image from media library that has neither Title box nor Alt text box set Title attribute absent, alt attribute empty Title attribute absent, alt attribute empty

    Using images from media library (previously uploaded) but making amendments

    Test No. Use Case Graham’s Expected Result Actual Result in Page
    9 Add image from media library, that has just Title box set, update Title box Title attribute set but not alt Title attribute absent, alt attribute set to whatever Title box was amended to
    10 Add image from media library, that has just Alt text box set, update Alt text box Alt attribute set but not title Title attribute absent, alt attribute set to whatever Alt text box was amended to
    11 Add image from media library, that has neither Title box set nor Alt text box set, update Title box Title attribute set but not alt Title attribute absent, alt attribute set to whatever Title box was amended to
    12 Add image from media library, that has neither Title box set nor Alt text box set, update Alt text box Alt attribute set, no title attribute Title attribute absent, alt attribute set to whatever Alt text box was amended to
    13 Add image from media library, that has both Title box and Alt text box set, update Alt text box Both attributes set Title attribute absent, alt attribute set to whatever Alt text box was amended to
    14 Add image from media library, that has both Title box and Alt text box set, update Title box Both attributes set Title attribute absent, alt attribute set to whatever Alt text box was originally set to

    Looking at the results

    Using the Add Media Panel to insert an imageThe first revealing thing about these tests is that my own view of how I thought WordPress worked is at odds with the actual results in most cases.

    The second thing that’s become obvious is that it’s actually impossible to set the title attribute for an image whilst using the Add Media panel. The title attribute never appears in any of the results.

    Actually the only way to set a title attribute image within pages and posts is to use the older image edit dialogue box once the image is placed within the page (or to manually update the HTML obviously).

    I think the confusion comes from the labeling of the Title input field in the Add Media Panel. Helen refers to this in her comments on the trac ticket I believe. Maybe to avoid confusion this box should be given another label – ‘Image name’ maybe. I confess that I hadn’t noticed this change in WordPress behaviour – it did used to be possible to directly influence the title attribute of an image when uploading and adding it to a page/post.

    I’m sure that I’m not the only one who didn’t appreciate this situation. There is a plugin called Shutter Reloaded that I’ve seen on a couple of sites, which uses the title attribute from the image to provide a caption beneath the image when the full size is shown. Obviously this plugin is broken if site admins don’t realise the title attributes aren’t being written into the <img> tags – and the plugin author perhaps doesn’t realise either. I can’t comment on other lightbox plugins.

    What do you think? Is this what you expected? Is this the right way to go?

     
    • Rian Rietveld 3:23 pm on November 29, 2013 Permalink | Log in to Reply

      Hi Graham,
      The addition the title attribute to the element img was removed a few versions of WordPress ago, which is a improvement to my opinion.

      I use the title only for labeling the images in the Media Library, yes, maybe image name is a better description for that input field.

      And it seems logical to add the images name into the alt field if the alt field is empty, but that can result in alt texts like IMG_123. Maybe the best way is to leave the alt text empty unless a user entered a value there.
      An alt=””is always better than an alt=”IMG_123″.

      Rian

  • esmi 3:25 pm on May 23, 2013 Permalink
    Tags: , testing   

    IRC Meeting: May 22, 2013 

    Another small but busy IRC meeting on #wordpress-ui where discussion focused on assessing the translate.wordpress.org site for possible accessibility issues.

    If you have a little spare time, please do try to contribute to the site feedback request. Any observation — no matter how small — is valuable. If you need some ideas on what to look for, please check out our Site Feedback Guide.

    #wordpress-ui log for May 22, 2013.

     
    • flick 7:54 pm on May 23, 2013 Permalink | Log in to Reply

      Thank you for the log. Am only just beginning to get acquainted with the Accessibility side of WP so every little helps. I am confused by the naming of GlotPress but perhaps it could be because I haven’t read enough about it. Is there a glossary somewhere one can refer to? Thanks.

      • esmi 8:20 pm on May 23, 2013 Permalink | Log in to Reply

        GlotPress is just a name — like WordPress, or BuddyPress. I think the problem we have here is that 3 different — but related — resources are all called “GlotPress”.

        Glad to hear that the IRC log was useful. We’d be more than happy for you to join in the meetups at any time.

    • flick 12:01 am on May 27, 2013 Permalink | Log in to Reply

      @esmi: Thank you for the welcome and for the clarification. I will be sure to try and attend an #irc meet up soon – just need to remember to put it into my Google calendar and be in 🙂

    • TDM 3:30 pm on May 28, 2013 Permalink | Log in to Reply

      Any idea when the next one will be ?

    • esmi 3:38 pm on May 28, 2013 Permalink | Log in to Reply

      Tomorrow – 19:00 UTC in #wordpress-ui

  • esmi 8:55 am on May 17, 2013 Permalink
    Tags: , , testing   

    Site Feedback Request 

    We have been approached by the folks over at translate.wordpress.org. They are keen to ensure that it is accessible as possible and would like our help to identify any problems with the current site.

    So please take a little time, between May 17 & May 31, to have a look at translate.wordpress.org and give us your feedback via comments on this post. In order to support you and provide some structure to the feedback, we’ve prepared a Site Feedback Guide that should help.

    We look forward to your contributions.

     
    • Lauren 12:20 pm on May 17, 2013 Permalink | Log in to Reply

      Readability:

      For the homepage, I recommend a section similar to Projects for the Getting Started Guide as the heading, including link to the guide. For the link list, I also recommend space above and/ or below the links.

      Maybe, a brief introduction or summary for each project and the Getting Started Guide can be inserted for educating the users about the products before clicking.

      Also, there isn’t a search tool or a privacy policy link/document on homepage.

      Accessibility:

      Every link needs at least a description, or more information about what it is. For example, alternate text, “Project: bbPress” is not enough description if I do not know what bbPress is. How will I know to click on it?

      When I click on bbPress or any other link, it opens to a dashboard-like page. Maybe, there should be a guide also about the layout explaining that the left column is a list of sub-projects and the right column is the list of translations in progress. Also, this guide can explain the attributes in the table.

      Hope this helps,
      Lauren

    • seablackwithink 10:54 am on May 19, 2013 Permalink | Log in to Reply

      Readability

      the homepage, Projects for the Getting Started Guide as the heading, including link to the guide….then maybe space above and/ or below the links.
      summary for each project and the Getting Started Guide can be inserted for educating the users about the products before clicking.
      Add users guide /explanation link
      Accessibility:
      Every link needs at least a description “Project: ____ is not enough description if I do not know what project____ is, possibly, add a guide about the layout explaining that the left column is a list of sub-projects and the right column is the list of translations.

    • esmi 3:04 pm on May 23, 2013 Permalink | Log in to Reply

      The following is the result of a fairly cursory audit of the site for potential accessibility issues. I did not attempt to differentiate what issues were generated from user-added content and what issues might be present in the GlotPress application itself. If you have any further questions or I can help in any way longer term, please let me know.

      Markup
      In general, the HTML markup is solid with good use made of list tags. Where it does breakdown is when you get into individual project translation tables (example table). As these are fairly complex data tables, I feel that it’s essential to ensure that best use is made of id for table headings and the headers attribute for individual cells. This should allow assistive technology software to render the tables in a far more meaningful manner as well as allowing disabled users to move around the tables far more effectively. Two excellent resources on this subject are Making Tables More Accessible With HTML5 and Accessible Data Tables.

      Contrasts
      On pages like Projects → WordPress, the contrast for the (definition) description of each sub-project is far too low at only 3.5:1. Even I’m straining to read it. It needs to be increased to at least 4.5:1 (try #777).

      Readability
      Generally speaking, I’d like to see an increase in the text sizes. A body font size of only 14px is a little on the small side. In some areas — such as the descriptions for each sub-project on the individual project pages — the text really is becoming hard to read without using Zoom.

      User Support
      When you first hit the site’s front page, there is an overwhelming feeling of “Where am I? What’s this all about?”. The site really doesn’t explain it’s purpose upfront, so it’s easy to imagine many users being somewhat bewildered and unsure of where to go next. Some of the initial content from Getting Started with translate.wordpress.org could really be moved from that page and placed at the top of the site’s front page to clearly establish the site’s purpose.

      Navigation
      This site really doesn’t have an effective navigation system. Instead, a breadcrumb is used in place of a more standard navigation menu. Whilst this is functional, it does force users to navigate to and from the site’s front page all of the time — which could impose an unnecessary burden on some keyboard navigators. I also noted that there is no way to skip this breadcrumb/navigation menu when entering a new page. Yet another issue for keyboard navigators.

      Some disabled users also rely on the title tag (as displayed in the browser tab) for primary navigation. Once you drill down into sub-sub-projects, this tag uses text like “3.5.x < GlotPress" — which isn't exactly informative. 3.5.x of what? In other areas, the title is far more helpful — "Translations < Dutch < Twenty Twelve < GlotPress". At the risk of increasing redundancy, perhaps a solution to this would be to re-address the headings on (for example) the WordPress project page, so that they used a “WordPress 3.5.x” format? This should create page title along the lines of “WordPress 3.5.x < GlotPress".

      And Finally…
      There's the issue of the site's name — GlotPress. A name also shared by an official wordpress.org blog and the open source content management application being used to generate content on translate.wordpress.org. I’ve left this until last because I feel that this definitely overlaps into usability but could still impact heavily on some disabled users groups. If I link to GlotPress, which of the three resources am I linking to? If you cannot tell without clicking the link, then we have a problem. I’d like to see each of these resources use their own unique names. Perhaps translate.wordpress.org (currently the only way I can clearly reference a specific resource) could be renamed “WordPress Translate”?

    • flick 7:49 pm on May 23, 2013 Permalink | Log in to Reply

      I would also like to put in my tuppence to second/third that it would be great to have a short introduction to the project(s) on the main page of Translate, rather than having to click through to the next section.

      And although it became obvious (a few seconds later) that one should click on the headings of e.g. https://translate.wordpress.org/projects/wp/dev to sort the data, perhaps it may be helpful to have arrows as a visual guide?

      Thanks

    • _Redd 9:55 pm on May 29, 2013 Permalink | Log in to Reply

      First of all, absolute hats off to the team at wordpress.translate.org for doing this. This is a really, really great thing, and no small feat to accomplish. Thank you.

      1. Getting Started with translate.wordpress.org
      Logical page order, with appropriate h-level headings. Easy to read text as far as color contrast, and font size were concerned. However, navigation in and out of the page wasn’t obvious, and could perhaps be strengthened. The “logo” for GLOTPRESS was great for returning home, and at least the alt tag announced it’s URL as http://translate.wordpress.org. A bit of “renaming” links may help with navigation. For example, The name of GLOTPRESS with a link to translate.wordpress.org led to a little confusion for me, and the links at the top, next to the login link titled, “Need Help?” was a dead-end link to the page I was already on. I had not expected this, as the title of the page was “Getting Started…”, and I would not have expected a hyperlink to a page I was already on. Elsewhere in the site, this was not done, so the lack of consistency would also contribute to a bit of confusion about linked areas.

      2. Projects Page
      Very clear, easy to understand.

      3. Sub-projects Page (Glotpress) This was difficult to read, mainly due to low contrast of the color choice of the text, and of the font size, which was small. Personally, I was unable to read it. When using NVDA screenreader, it read “Development” as a list with two items in it, but never read the two items.

      4.Development PageThis was listed as active, but when I went to this page, it said that it had no translations. I was a little confused at first, and figured out the sense of what was meant. That said, a revisit to the terminology used for an active page with no translations may help alleviate some confusion.

      5. WordPress subprojectNVDA screenreader announced that “Development” was a list with fourteen items, but I never heard the items announced.

      6.Development GuideVisually speaking, very easy to understand. Using a screen reader, it was easy to follow once I was inside the table, as the headings were announced, and the logic went across rows (kudos) but getting to and from the table was difficult. At one point, I tried to go back over the page by simply going to the “hide” link, just as a way to get back to the top of the page. When I did so, the “hide” link faded away, and I couldn’t get it back. Then I was really stuck in the table with no way to navigate around on the page via the screenreader (please note, I am a sighted user….another user familiar with a screen reader would have probably known how to exit out of the table much more easily than me–but I never figured out how to get to the small menu on the left hand side for the different themes).

      7.Translation of Chinese (Taiwan)Visually speaking, very well organized. There were some gray boxes with no corresponding legend on the bottom of the page, which I think would have helped. For example, the words “post revision title extra” was in a gray box, and in order to understand why it was cued that way, I looked at the bottom of the page at the legend, which had a green, orange, yellow, pink, and striped code, but no gray code. Consider, for the sake of consistency, when text is color-coded, to include the meanings behind the color-coding consistently. As far as the faint words, “Double click to add”, I almost didn’t see them (but the screen reader read them just fine). When I double-clicked within, just to see what followed, I tried to get out of it using the back button (a common behavior) and I was taken out, all the way back to the Development main index page, rather than back to the page before, the Translation of Chinese page. The same problem happened when I had hit one of the “details” links within one of the rows.

      8.Translation of Chinese (Taiwan) in Chinese mode for NVDA the screen reader only reads the links at the top of the page, then the table headers, and from there, only the “Details” column. It doesn’t tab over to the text. Using the mouse, I was able to click on the sixth row down, to the Chinese, and listen to the screenreader announce the contents in Chinese, but I relied on sight and a computer mouse to get there.

      I just have to say, I am in awe. This is an amazing project, just amazing. Thank you so much for what you’re doing here; it’s really appreciated, and it’s going to make a difference to so many people. Thanks again.

    • _Redd 11:13 am on May 30, 2013 Permalink | Log in to Reply

      One other item I forgot to mention, is that when using colors to code, if you could, please, use colors that are very distinct from one another in terms of lightness or darkness. A color-blind person would not have been able to tell the light green, from the pink. etc. Consider a visual coding system that is independent of color. Again, though, thank you for this amazing, awesome project!

  • Graham Armfield 10:31 am on April 4, 2013 Permalink
    Tags: , , , , , , testing   

    Accessibility IRC Chat – 3rd April 2013 

    A few of us took part in the IRC chat yesterday (see transcript here). Not surprisingly the main subject was the Add Media Panel accessibility, and the format of the chat turned into a live screen reader test on the functionality performed by @_Redd and @arush (and myself).

    @lessbloat had kindly had a go at implementing my quick and dirty pragmatic ARIA solution – for which we are truly grateful. Once we’d got access to an environment where the changes were in effect we could see that vast improvements had been made to the accessibility.

    I’ll save the detail to the blog post about Add Media Panel but to summarise:

    • Keyboard-only users can now tab through the items in the media list and select/deselect using Enter key
    • Screen reader users were getting some useful information but possibly only the newest versions can fully use this functionality.
    • Voice recognition users can at least use the tab commands to move around the list and select them.

    The key decision now is whether the functionality is useful and solid enough to include in 3.6. A couple of extra enhancements would make the solution better for screen reader users – once again see previous post.

    My vote would be to run with it if we can get the small further enhancements. We can hopefully address the rest of the accessibility issues within 3.7.  But what do you think?

     
    • _Redd 11:39 am on April 4, 2013 Permalink | Log in to Reply

      RUN WITH IT! Enhancements are for plugins!!!

    • Joe Dolson 3:23 pm on April 4, 2013 Permalink | Log in to Reply

      This is great Graham. I’d agree with _Redd – this sounds like a great improvement. I don’t see any reason to wait for perfection; this is an important step forward.

    • _Redd 2:29 pm on April 5, 2013 Permalink | Log in to Reply

      I have the 3.6 beta up, and, as one who is ignorant of screen readers, I can at least say that my version of NVDA announces itself nicely in the Add Media area. Thank you, Graham and lessbloat, this is a jaw-dropping leap forward! 🙂

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