WordPress.org

Ready to get started?Download WordPress

Make WordPress Accessible

Updates from esmi Toggle Comment Threads | Keyboard Shortcuts

  • esmi 12:39 pm on September 2, 2013 Permalink
    Tags: ,   

    IRC Meeting: August 28, 2013 

    The main focus of the meeting ( and the group) was still on one of our primary objectives — the development of a global accessibility statement for WordPress. After reviewing Drupal’s accessibility statement again, it was decided to begin work on drafting our own statement that can then be presented to the wider community for discussion.

    (More …)

     
  • esmi 9:00 am on August 9, 2013 Permalink
    Tags: , ,   

    Title Attributes Galore 

    The patches for Trac ticket 24766 are slated for addition to WordPress 3.7. This is great news for assistive technology users who have been forced to wade through a sea of unnecessary title attribute verbiage. But we need to ensue that the patches cover all unnecessary title attributes and that those deliberately excluded from the patches do not present any accessibility issues.

    Currently, the excluded methods, functions and scripts are:

    • the_author_posts_link()
    • rss.php
    • wp_fullscreen_html()
    • get_adjacent_post_rel_link()
    • _walk_bookmarks()
    • get_image_tag()
    • the_shortlink()

    (More …)

     
    • David A. Kennedy 12:02 pm on August 9, 2013 Permalink | Log in to Reply

      I’m wondering if we missed any? I believe some functions, like

      get_the category_list

      and

      edit_post_link

      have title tags built in as well. I’m not as familiar with core so looking through the diff makes it hard to tell. Commenting here to get opinions and not junk up the ticket.

      • Amy Hendrix (sabreuse) 3:53 pm on August 9, 2013 Permalink | Log in to Reply

        Both of those functions are included in the patch that’s currently on the ticket — you can see the full list at the ticket link.

        The list in this post is just the ones that I left off the patch, either because they’re deprecated functions (which means aren’t actually used in core anywhere, and we normally wouldn’t make any changes to them unless it was for something like security), or because the title attributes are being used for help and not just labels (and in that case, they should get a better solution rather than just being deleted without any kind of fallback).

        It’s definitely not a problem to get this batch in, and still pick up any that were missed in subsequent patches.

        • esmi 4:16 pm on August 9, 2013 Permalink | Log in to Reply

          Understood, But my concern is how to handle wp_fullscreen_html()

          • Amy Hendrix (sabreuse) 5:08 pm on August 9, 2013 Permalink | Log in to Reply

            Yep, got that — I was just trying to answer David’s question about other functions that didn’t appear in this post.

            On with the wp_fullscreen_html() discussion, which is definitely a tougher case than most of these!

    • Joe Dolson 8:58 pm on August 10, 2013 Permalink | Log in to Reply

      I think we need to consider some alternatives for the wp_fullscreen_html labels and interface generally — this is definitely not a simple case of removing the title attributes alone. It should probably be pushed as a separate ticket; it’s related, but it seems sufficiently different that treating it independently is worth while. Thoughts on that?

    • Joe Dolson 5:55 pm on August 21, 2013 Permalink | Log in to Reply

      So, went to work on this to create the ticket, and decided that I first needed to create a ticket on keyboard focus — there are a lot of problems with keyboard focus in the full screen editor, so it’s nearly impossible to use with a keyboard. Ticket 25111.

  • esmi 2:58 pm on August 8, 2013 Permalink
    Tags: , , ,   

    IRC Meeting: August 7, 2013 

    A very busy & productive meeting. We’ve identified two high priority areas that we’d like to focus on in the next couple of months.

    (More …)

     
  • esmi 9:34 am on July 19, 2013 Permalink
    Tags:   

    Accessible Polls and Surveys 

    We are always looking at ways to increase feedback from disabled users of WordPress. The more we know about the issues that people face every day, the more we can advocate for positive changes.

    We also appreciate that it can be very daunting to post a comment on a blog like this one. So we would like to look at using short surveys and simple polls as a way of allowing people to give us their feedback as simply and as easily as possible. That, however, raises a whole new set of potential problems. We need to ensure that whatever tools we do use are as accessible as possible.

    This where you come in.

    Please tell us about any accessible survey and poll applications that you know of.

     
    • jebswebs 3:06 pm on July 19, 2013 Permalink | Log in to Reply

      I like SurveyGizmo. They were the first to make their survey tools accessible long before any of the others even knew what accessibility meant. They have several templates that are designed specifically for accessibility and some decent mobile templates as well.

    • After Gadget 3:19 pm on July 19, 2013 Permalink | Log in to Reply

      I can’t think of any survey tools that are particularly accessible. The one I’ve used the most is survey monkey, and I couldn’t seem to make it work with Dragon, though I was much less proficient at Dragon at the time, so maybe it is actually better than I think. I had to fill it out though because it was the Census. But I did want to let you know that I am happy to fill out whatever survey you come up with. :-)mouse window

    • _Redd 4:51 pm on July 20, 2013 Permalink | Log in to Reply

      @After Gadget That would be AWESOME help! Thank you SO much!

  • esmi 11:10 am on July 18, 2013 Permalink
    Tags:   

    IRC Meeting: July 17, 2013 

    Long time no meetup update! Our regular IRC meetings have still been taking place every Wednesday at 19:00 UTC But we’ve been so busy that it’s been hard to stop and provide updates.

    Last night’s meeting focused on how to gain a better insight into the real problems that some WordPress users face every day. We also discussed ways to increase the flow of information from those users so that we can advocate high priority changes on their behalf. We’ll be posting about some of our ideas and asking for your help shortly.

    #wordpress-ui log for July 17, 2013

     
    • _Redd 1:53 pm on July 18, 2013 Permalink | Log in to Reply

      As usual, another great meeting. Thank you so much for everything you do.
      In reference to what was discussed last night, I came across this survey from Adobe on screen design that I thought might be a good model to start. I don’t know how “accessible” it is yet, but we can find out!

  • esmi 8:01 pm on June 25, 2013 Permalink
    Tags: , ,   

    Next IRC Meetup 

    Just a quick reminder that the next IRC meetup will be on Wednesday, 26 June at 19:00 UTC in #wordpress-iu.

    Everyone welcome!

    If you have never attended an WordPress IRC meetup before, you can find all of the details you will need to join in the Codex’s IRC page.

    One topic for discussion is likely to be the development of a proposed accessibility statement for WordPress. To whet your appetite and give you an idea of what we could aim for longer term, have a look at Drupal’s accessibility statement.

     
  • esmi 12:49 pm on June 25, 2013 Permalink
    Tags: html5,   

    Should We Be Dropping the Role Attribute in Twenty Thirteen Yet? 

    Your feedback is requested on Trac Ticket 24629.

    Cited example: Should the Twenty Thirteen drop the use of the role attribute on the HTML5 nav element on the grounds that the element, by definition, has the role of navigation? Or should role="navigation" be retained in order to support technologies that are not yet HTML5 aware?

    My own opinion that the role attribute should be retained for the time being in order to support the widest range of technologies. Dropping it would offer only a marginal benefit in reducing page bloat. Please do weigh in with your opinions on the ticket.

     
    • tady 12:59 pm on June 25, 2013 Permalink | Log in to Reply

      Deffo not. The role attribute is still as important now as it was pre-HTML5. A cited counter example: The main element (<main>) has only just been introduced to the HTML5 spec and is recommended it take the format:

      <main role=”main”>

      Personally feel that it doesn’t make any more or less work to include it. I wouldn’t be in such a rush to remove attributes such as this any time soon. The spec has a long way to go and will change again before it is fully RC, so I reckon removing helpful attributes like roles have the possibility of shooting us in the foot at some point in the future.

    • _Redd 1:17 pm on June 25, 2013 Permalink | Log in to Reply

      Don’t drop it. We’re finding that HTML5 attributes are starting to gain support, and we’re including it in our sites.

    • ceo 2:54 pm on June 25, 2013 Permalink | Log in to Reply

      While I don’t think we should be bound to supporting users with outdated software, which isn’t to say state-of-the-art is fully supporting HTML5 anyway, I think the pros of keeping it far outweigh the cons of not.

    • gogreener 1:40 am on June 26, 2013 Permalink | Log in to Reply

      Agreed. Is it possible to set a reminder to review it again at a later date?

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

    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: , ,   

    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!

  • esmi 11:25 am on May 9, 2013 Permalink
    Tags: ,   

    IRC Meetings 

    Just a quick post to remind everyone that we are still holding a weekly IRC meeting in #wordpress-ui every Wednesday at 19:00 UTC.

    The meeting on May 1 covered the variations in form handling across different screen readers as well as a recent issue reported with the Jetpack plugin. As a result of the latter discussion, we now have a representative on the Jetpack Beta Group and Trac ticket #1710 has been created.

    #wordpress-ui log for May 1, 2013.

    On the May 8 meeting, discussion centred on the draft Site Feedback Guide. The guide is intended to both add structure to any site feedback as well as provide some support for non-technical disabled users who would like to join in. We hope to test the guide out later this month.

    #wordpress-ui log for May 8, 2013.

     
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