WordPress.org

Ready to get started?Download WordPress

Make WordPress Accessible

Tagged: testing Toggle Comment Threads | Keyboard Shortcuts

  • 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: http://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. http://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! :-)

  • esmi 1:41 pm on February 14, 2013 Permalink
    Tags: , testing   

    Post Revision Timestamps 

    Following a suggestion from @Ryan McCue about making timestamps in post revisions human readable, I’ve set up a test case that uses both human readable and W3C recommended timestamp formats.

    All feedback and comments here, please.

     
    • _Redd 1:56 pm on February 14, 2013 Permalink | Log in to Reply

      1. Is it possible to differentiate between the original text, what has been deleted and what has been added?

      Yes very clear

      2. Are any of the timestamps perceivable?

      I don’t see time stamps on Firefox 10.0.2 , Chrome Version 24.0.1312.57 m IE9 , at least, not rendered as text on the page. Did you mean that the time stamps should be visible in code? I can view code and see time stamps

      • esmi 2:01 pm on February 14, 2013 Permalink | Log in to Reply

        The visual presentation is being controlled by Twenty Twelve and it is nice to see that it does a good job of it. But what about those who cannot see the visualisation? In theory, the ins and del tags should be rendered appropriately in screen reading software but I don’t know how (or even if) they render the attached timestamps. If they do, then the format of that timestamp may be critical. The sooner we can let the UI team know what format(s) they can (and can’t) use, the better.

        • _Redd 2:08 pm on February 14, 2013 Permalink | Log in to Reply

          Interesting. Hopefully, we’ll hear from some of our experienced screen reader users soon; in the meantime, I may just dig up the iPad and try to see what Voiceover does with that. …..it may have to wait until this weekend, but I think this is most certainly a worthwhile pursuit!

    • heidi 3:52 pm on February 14, 2013 Permalink | Log in to Reply

      in using JAWS screen reader with I.E. 8 and Firefox 18.0.2 two paragraphs are read but there is no indication of any revisions or timestamp present.

      • tady 4:52 pm on February 14, 2013 Permalink | Log in to Reply

        That’s very interesting Heidi. Can you tell us what version of JAWS you are using? I was under the impression that it should be able to support.

    • tady 4:53 pm on February 14, 2013 Permalink | Log in to Reply

      That’s great Esmi, it’s great to see it in context. Really looks like a great addition. Be interesting now to hear the feedback from people using SRs now, like Heidi here.

    • Heidi 9:05 pm on February 14, 2013 Permalink | Log in to Reply

      I am using JAWS version 13.0.1006

    • Heidi 9:34 pm on February 14, 2013 Permalink | Log in to Reply

      regarding Esmi’s remark: In theory, the ins and del tags should be rendered appropriately in screen reading software but I don’t know how (or even if) they render the attached timestamps. If they do, then the format of that timestamp may be critical.
      … I would think appropriate rendering would be for them not to read in the actual post but should show up in the code so as to appear on the back end … in the code the time stamps are showing, they are nonsense in the first paragraph but read properly in the second. I hope I am understanding the purpose of this test correctly

    • Amanda 4:58 pm on February 15, 2013 Permalink | Log in to Reply

      I just looked at the test page, and using IE9, and Jaws for Windows 13, the timestamps are not visible, and there is no way to determine that text has been deleted. So to go through the test questions:

      • There is no way to tell whether text has been changed, deleted or added, ETC.
      • Timestamps are not perceivable unless looking at the underlying generated HTML.
      • The timestamps are not rendered in an understandable manner, at least on the front end, which is where I’m assuming you want them to show up.

      Amanda

    • esmi 5:02 pm on February 15, 2013 Permalink | Log in to Reply

      Thanks Amanda & Heidi. Based on the feedback thus far, it seems that JAWS doesn’t render these tags when used with your current configuration. Can I ask both of you whether you are using JAWS in a verbose mode?

    • Heidi 7:02 pm on February 15, 2013 Permalink | Log in to Reply

      I am using JAWS in beginner verbosity mode

  • esmi 12:05 pm on February 14, 2013 Permalink
    Tags: , , , testing   

    IRC Meeting Summary: 13 Feb 2013 

    As per last week, we had a very lively and interesting meeting with the main focus being Custom Menus (again) and the use of hidden skip links. Thanks to all who took part — especially a couple of UI team members. The inter-team discussion is invaluable as it allows us to get a better perspective on the overall core development philosophies as well as the current development cycle goals. I think the more we learn about the development process, the more effective we can become at offering practical, effective, suggestions at the right times.

    User Testing

    @accessiblejoe will be looking at developing videod user tests for the CSUN conference based on the list provided by @GrahamArmfield and the alter discussion on IRC:

    • Logon and interpret dashboard and toolbar
    • Publish new post including use of headings, bold etc. Add categories and tags.
    • Edit post to add media (image or pdf) with caption, alt text etc.
    • Update user options including setting new password
    • Use Theme Customizer to change Site Title and background colours etc.
    • Creation of a simple custom menu; re-ordering of menu items including a single item sub-menu.
    • Logging out of WordPress.

    We hope that any videos obtained will help the core development teams to gain a better understanding of some of the issues faced by disabled users.

    Front-end Accessibility

    @joedolson is still working on an extension of the Theme Check plugin as part of the optional accessibility audit for all themes submitted to wordpress.org. He now has a modified version of the plugin available for testing and is actively looking for feedback.

    There was also a lively discussion of “hidden” links — including both skip links and the current log out link (which is effectively hidden in a dropdown) — and balancing link visibility with the need to avoid a cluttered interface.

    Finally, a reminder to all readers that, as a group, we are still stretched pretty thin and would welcome new members — both technical developers and non-technical disabled authors.

    #wordpress-ui log for February 13 2013

     
    • ceo 12:34 pm on February 14, 2013 Permalink | Log in to Reply

      Catching up on the chat after I left. I really like the idea of the visible Logout. Glad to see this brought up.

      And, in my experience, most of the screen reader users I know use Facebook and Twitter either via the mobile sites or apps because of the inaccessibility. I don’t really frequent many other social networks so can’t comment on them.

      • tady 5:03 pm on February 14, 2013 Permalink | Log in to Reply

        This is one that caught my eye too. I wondered about the possibility of integrating an icon font? (An example would be: http://fontello.com/ ) Would this be more beneficial? In this case, the under “Font Awesome” there’s a pretty decent icon to logout. Couple this with an anchor title and it could be small/discreet enough to go alongside the “Howdy, username [Gravatar]” easily. I would envisage a (slow) update of all icons across the dashboard to an icon typeface over time, which would result in this being second nature or intuitive.

        As many of these font icons are actually unique entities (i.e. it’s not like the logout symbol replaces the letter “L”), maybe this is creating an element of greater confusion? Perhaps an image with a proper alt/title would be more effective?

        • GrahamArmfield 12:31 pm on February 15, 2013 Permalink | Log in to Reply

          A small problem with using icons alone is that speech recognition users can sometimes find it difficult to action the link. Those users can usually access image links if they know what the alternate text is, but of course that is not always obvious.

          That said, in this case the alternate text would be very likely to be “log out” or “log off”.

          Speech recognition users do have other ways of activating links but they can get laborious.

          With icons there could also be the issue that they are not obvious enough for some users – maybe with cognitive impairments.

          • esmi 1:02 pm on February 15, 2013 Permalink | Log in to Reply

            A small problem with using icons alone is that speech recognition users can sometimes find it difficult to action the link.

            As an ex-VR user (try coding in Dragon for 6 months — it’s… interesting), I’m in two minds about this.

            Using Dragon as an example, if it is used with IE, all links on a page are given numbers within the browser so you can easily jump to a given link. As I’m a Firefox girl, I looked around for an FF extension that would give me similar functionality. So I’d argue that this really is an edge-case between the web page design and the user’s choices/software configuration. At worst, VR users should be able to TAB to any link in a page — so nothing should be ever completely inaccessible. And if an icon was used, it wouldn’t/shouldn’t be the link itself. The main link’s text would/should still be there to be used.

            • _Redd 2:29 pm on February 15, 2013 Permalink

              A friend and I were talking about this……

              1. WHAT exactly enables tabbing?
              2. Is the tabbing behavior consistent for screen readers, voice-recognition systems, and other AT?
              3.is it necessary to also add a:focus if you want the focus to be in sync with tabbing?

              I welcome any url links, authoritative sources, or insights on this. I know that between the two of us, we could not answer these questions between ourselves.

            • esmi 4:07 pm on February 15, 2013 Permalink

              1. It’s default browser behaviour. Just like web developers have HTML specs, browser developers have W3C User Agent specs that they need to follow.

              2. Pretty much, yes. Different AT might have their own inbuilt helper functionality (which, by & large, is outside of our remit as developers) but, by default, they should all fall back to the default tabbing behaviour.

              3. Yes. And if you want to support older version of IE (IE8 or below), you also need to apply the same styling to :active pseudo class.

              4. http://accessites.org/site/2007/05/keyboard-friendly-link-focus/

            • _Redd 4:37 pm on February 15, 2013 Permalink

              Awesome, thank you esmi from both of us!

      • GrahamArmfield 5:09 pm on February 15, 2013 Permalink | Log in to Reply

        I finished the plugin I was talking about the other day and after some initial teething problems it’s now available – through my own site initially but I intend submitting to WP plugin repository when I’ve worked out how I do that.

        The plugin places a Log Out link into the admin toolbar. I’ve tested it with Dragon Naturally Speaking and on an iPad and it seems to work OK.

        Originally I was attempting to get the Log Out link into the main menu – above the Dashboard link but I couldn’t get that to work properly.

        I’d welcome any feedback if people want to try it out – it’s available at: http://www.coolfields.co.uk/2013/02/wordpress-permanently-visible-log-out-link-plugin-version-0-1/

        • esmi 5:32 pm on February 15, 2013 Permalink | Log in to Reply

          Cool! Have you had a look at Plugin Submission and Promotion?

        • _Redd 7:55 pm on February 15, 2013 Permalink | Log in to Reply

          AWESOME!!! And so timely! Do you forsee any issues with multisite?

        • _Redd 2:56 pm on February 20, 2013 Permalink | Log in to Reply

          Good morning Graham, on one of my test sites (multisite set up) I have both yours and Joe’s plugin activated.

          So far, when I am “in” WordPress, the login and logout functions seem to be fine–however, one of the things I do is “View Page” to look at my work, and that opens in another tab.

          I get network access message errors when I try to log out through the “normal” logout screen on the new tab. I’m never sure if it’s an actual network problem, but you may want to check the function of the “standard” logout link, on a new tab, with the plugin installed.

          The difference between the logout message I get when I log out of a site WITHOUT the plugin activated is ……wp-login.php?loggedout=true

          The logout message I get when the plugin activated is….wp-login.php?action=logout&_wpnonce=e965affe42

          So it looks like processing a nonce may be the culprit

          That said, your plugin and Joes are some of the BEST are REAL progress for WordPress! Thank you thank you thank you!

          • GrahamArmfield 4:36 pm on February 20, 2013 Permalink | Log in to Reply

            Hello _Redd, thanks for the notes.

            To place the Log Out link in the toolbar I’m using the admin_bar_menu hook to call a function that calls the add_menu() function.

            One of the parms I’m passing is the link for the item which is provided by wp_logout_url(). I’ve left the redirect parm empty to allow the default processing. This seemed to me to be the safest way to get the appropriate link as I couldn’t track down the function where the existing logout links are added to the toolbar.

            This seems to be correct as per the guidance on the codex – notably: http://codex.wordpress.org/Function_Reference/wp_logout_url but if I’ve made a mistake I’d be grateful of any pointers to the correct way to generate a Log Out link.

            I have a test site without my plugin running and the existing Log Out link does include the reference to the nonce.

            • _Redd 4:53 pm on February 20, 2013 Permalink

              Thank you so much for the rapid response….a lot for me to learn from, personally, and a lot for me to chew on. And sadly, much is of this is over my head. I’m like a monkey looking at the back of a watch with a lot of this stuff! But! I’ll review the links you’ve provided, revisit this and get back with you for the results…..it might be a couple of days, but will definitely revisit.

              Thanks again!

    • George Nilsen 1:08 pm on February 14, 2013 Permalink | Log in to Reply

      I canot get access directly from http://myvikingdomain.com but can’t get more than ‘you had a typo’–which worked ONLY once. Now I have to go from a ’1 result’ menu (w/o seeing the result) by clicking on the ‘fb’ icon(linked to the domain) to get access. How can anyone get there to read my posts & pages, market my books?

    • esmi 2:12 pm on February 14, 2013 Permalink | Log in to Reply

      @George Nilsen: Sorry? I don’t follow you…

  • esmi 1:10 pm on February 7, 2013 Permalink
    Tags: , , , testing,   

    IRC Meeting: 6 Feb 2013 

    Thanks to everyone who managed to make the IRC meeting on #wordpress-ui yesterday.  We had a very productive discussion and — despite the entertainment provided by way of my terrible iPad typing — took the first steps towards organising the group along more formal lines.

    @GrahamArmfield will be looking after Trac. Time permitting, he will be monitoring the existing accessibility-tagged tickets and taking the lead on the submission of new Trac tickets to cover issues such as the problems within the current custom menus admin area. So if you are thinking of raising a new Trac ticket, can you raise the subject here first? That way, we should avoid unnecessary replication.

    @joedolson expressed a vested interest in the editorial flow area but, for the time being, will be concentrating on front-end accessibility via the proposed theme accessibility audit and an extension to the current theme submission checks.

    @AccessibleJoe will take the lead on user testing videos so that we can build up a library of video resources to support core developers.

    @esmi will continue to take lead on documentation (liaising with @Siobhan and @DrewAPicture) as well as working with @lessbloat and other members of the UI team to try to develop in-house user accessibility testing.

    We are, however, still stretched pretty thin. So if you would like to get involved, we would love to hear from you. Those of you with the skills to create patches will be particularly welcomed by the UI Team who are currently overhauling the Custom Menus and Post Revision areas.

    #wordpress-ui log for February 6 2013

     
    • Nelson 1:30 pm on February 7, 2013 Permalink | Log in to Reply

      I’m sorry, I was out yesterday! I missed so much! I am so so glad to see this move forward, and I will coordinate to help however possible. I’ll be in touch. Thanks to all for the committment to accessiblity.

      • Redd (formerly Nelson) 1:53 pm on February 7, 2013 Permalink | Log in to Reply

        esmi, I am reading through the IRC Ui-channel chat entries from yesterday, trying to catch up. I found the following statement: esmi

        Does anyone else read the other core P2 blogs regularly?

        What are the P2 blogs? Are they the same thing as the IRC logs?

    • Sharon Wachsler 3:43 pm on February 7, 2013 Permalink | Log in to Reply

      Hi. I was hoping to stop by yesterday just to listen, but kept forgetting to go to time zone converter to figure out what time it was. I don’t think I have much to offer right now as I’m still learning a lot of the terms you’re using. But I’m grateful this group exists.

      >>So if you are thinking of raising a new Trac ticket, can you raise the subject here first?>>

      Since this seems to be a general request, would you mind explaining what it means, so I can try to comply?

      • ceo 4:04 pm on February 7, 2013 Permalink | Log in to Reply

        Trac is where bugs are reported and other changes to WordPress are, well, tracked. It can be intimidating for those unfamiliar with it, so if you are not comfortable submitting a bug we ask that you report things here. Also, we want to avoid duplicate tickets. (An example of an ongoing Trac right now, is the Custom Menu enhancements.)

        For reference: http://codex.wordpress.org/Reporting_Bugs

      • esmi 4:19 pm on February 7, 2013 Permalink | Log in to Reply

        We’d love to have your input at the meetings but if you can’t attend, there should always be the posted summaries the day after. Plus I’ll try to always include a direct link to the IRC logs for that day & channel so you can read the full discussion at your leisure.

    • Sveta 10:09 pm on February 7, 2013 Permalink | Log in to Reply

      @AccessibleJoe will take the lead on user testing videos so that we can build up a library of video resources to support core developers.”

      Regarding videos, will they be accessible via captions? There are developers who are deaf. Thanks!

    • esmi 10:35 pm on February 7, 2013 Permalink | Log in to Reply

      Yes. We’ve already discussed this at some length both at the meeting yesterday and via email today. We will ensure that captioned versions of videos are widely available.

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