Make WordPress Accessible

Category: Status Updates Toggle Comment Threads | Keyboard Shortcuts

  • Joseph Karr O'Connor 8:45 am on July 8, 2015 Permalink
    Tags: , ,   

    H1 in the admin

    For 4.3 there will be an H1 in the admin. #31650: Missing H1 heading in the admin. Assistive technology users look for the H1 for way finding. Though there is the page title, when AT separates out elements such as links, lists, and headings, the info needs to be there too. Two weeks ago we ran this by Mika Epstein @Ipstenu and she helped us understand heading levels and plugins. Mika spot checked some plugins and it showed that they are using H2 and her opinion is that “we can post about that in make/plugins to try and spread the word.” Thanks Mika. More work will be done on the rest of the hierarchy.

    Main Open Tickets

    We also briefly discussed:

    • #31661: Quicktags: Can’t add them using just a keyboard in IE,
    • #26601: Inappropriate content in headings on admin screens,
    • #32152 List table: sortable column headers accessibility,
    • #26601: Inappropriate content in headings on admin screens, and
    • #31336: Customizer: separate navigation from options UI for better UX by removing accordion behavior.
  • Joseph Karr O'Connor 2:38 am on May 2, 2015 Permalink
    Tags: , ,   

    Weekly Meeting Change

    This week during the Wednesday meeting we decided that the Monday testing meeting is now where the action is so we decided to stop having the Wednesday meeting. On Monday, May 4, we will all meet in the #accessibility channel in Slack at 18:00 UTC. We are also using Slack throughout the week to work on tickets and patches, ask questions, and discuss anything that comes up. First register for the WordPress forums and then follow the steps on the WordPress chat instruction page to get set up. Then find your way to #accessibility. See you there!

  • esmi 1:05 pm on April 12, 2012 Permalink  

    I’ve only just realised that Admin Bar links contain tabindexes. That’s bad enough but they’re not really in an intuitive/logical order. Can they be removed in a future version?

  • Jen 3:43 pm on November 28, 2011 Permalink
    Tags: 3.3   

    WordPress 3.3 is coming up on RC1 (meaning it’s close to launch). We tried to catch as many accessibility issues as we could, but chances are we missed things. If anyone would be willing to run 3.3 beta through the paces and report back on how it does/what fixes need to be made, that would be great. If you’re not set up with an svn install, you can download the beta tester plugin to put the beta on a test site.

    • Andrew Nacin 12:45 am on November 29, 2011 Permalink | Log in to Reply


    • Graham Armfield 9:40 am on November 29, 2011 Permalink | Log in to Reply

      Are you primarily thinking back end or front end or both, and should we reply here – or elsewhere?

      • Jane Wells 11:55 am on November 29, 2011 Permalink | Log in to Reply

        Mainly the dashboard, since that’s where the changes are in 3.3. Responses in comments on this thread.

    • Graham Armfield 11:05 am on November 29, 2011 Permalink | Log in to Reply

      Not accessibility I know but not sure where to put this…. It seems impossible to switch comments off at the individual page level.

      General settings are to allow comments. I edit a page and uncheck Allow comments and then Update the page. I’m returned to the edit page again and the comments checkbox is checked again. Not sure if it’s theme dependant but it happens on both twentyten and twentyeleven.

      • Jane Wells 11:53 am on November 29, 2011 Permalink | Log in to Reply

        Hi Graham. Please don’t use this blog for non-accessibility bugs, feature requests, etc. Try the support forums for troubleshooting. https://wordpress.org/support

        • Graham Armfield 11:21 am on December 2, 2011 Permalink | Log in to Reply

          Hi Jane. Understand that I’ve missed the boat on accessibility updates for 3.3. So looking forward to 3.4, please can you outline the correct route for people like myself to suggest accessibility enhancements. In order to get accessibility as right as possible I believe it’s important to design it in as early as possible.


  • Jen 2:32 am on November 28, 2011 Permalink  

    Changed a couple of settings:

    • Must fill in name and email, but removed the ‘must have previously approved’ setting so now comments go live immediately instead of waiting to be moderated.
    • Close comments on posts older than 14 days old. Comments go unnoticed, and no action gets taken. Hopefully discussions can get to agreement within 2 weeks (well before, if we’re lucky) and the resolution can make its way over to the appropriate trac ticket.
  • Jen 2:11 am on November 28, 2011 Permalink
    Tags: dashboard menu,   

    Do people think it is better for the dashboard menus down the left side to work as described in A, B, or C:

    • A. Tabbing goes from top-level item to its subs and cycles through them, then proceeds to the next top-level item, etc., and hitting Enter/Return acts as clicking on the link to whatever item you’ve tabbed to; or
    • B. Tabbing goes from top-level item to top-level item, and hitting Enter/Return ‘opens’ the subs and then you can tab through them?
    • C. A more accessible suggestion that we haven’t thought of?

    Please leave your vote/suggestion/comments in a reply to this post IF you work professionally in the accessibility field OR you need to access WordPress without a mouse/trackpad/rollerbar/other mouse-like input device (generally due to disability). If you don’t fit in one of these categories: while your opinion is valuable, it’s not the one we’re looking for at this particular time. So regular designers, developers, and users, please don’t distract from the pros and the target population on this thread. If you are an accessibility pro and have not introduced yourself on this blog before, or a keyboard access/screen reader user, please add a note about your qualifications/experience (for pros) or your typical setup/environment (for users — which screen reader, do you use keyboard shortcuts in addition to tabbing etc) so that we can put your suggestions in context. Thanks.

    P.S. Please don’t derail the conversation by using this thread to suggest other features.

    • Steveorevo 2:22 am on November 28, 2011 Permalink | Log in to Reply

      B – hitting enter twice would then activate the given top level

      P.S. Support for touch ala mobile devices in widget drag n’ drop would be nice, but hiring me would be nicer! 😉

      • Jane Wells 2:36 am on November 28, 2011 Permalink | Log in to Reply

        Can you let us know your experience with accessibility so we have some context for your participation? Thanks.

        P.S. This is not the place for feature requests. The regular forums have a whole section for that, and this blog is very specifically focused on accessibility.

        • Steveorevo 2:57 am on November 28, 2011 Permalink | Log in to Reply

          Sorry about the request here Jane. Noted.

          I’m afraid I don’t have the accessibility background, however my “related field” is UI, specifically simulation, and formerly 3D gaming engines along with some early telephony APIs (E911, etc.). This means catering UI systems to humans visually, audibly, and sometimes tactile. I guess that is a far cry from accessibility. WordPress is now my passion.

          I’d agree with Chris that K (below) that ‘B’ proposes a feel for structured hierarchy. Although you pointed out that this is strictly accessibility, part of accessibility (as in Section 508) is catering to individuals with visual and cognitive disabilities. Cognitive would relate to the acquiring of knowledge and the experience of a laid out UI. I would imagine the perception and grouping (and acting on that grouping with ‘Enter’) would influence accessibility. My reasoning behind choosing B. The implication for screen readers would reflect this as well, not unlike the structured top-level menus one would hear when navigating a voice assisted phone system.

          • Jane Wells 3:00 am on November 28, 2011 Permalink | Log in to Reply

            The UI group is where we focus on issues of hierarchy, design, etc. Most of our designers and developers (myself included) are not particularly experienced with screen readers and keyboard access rules/guidelines, which is why this separate blog exists and really is meant to be kept specific. If you are interested in more general UI stuff, you may want to follow/join in at https://make.wordpress.org/ui

    • Chris Kankiewicz 2:25 am on November 28, 2011 Permalink | Log in to Reply


      From a usability standpoint this would give the navigation a structured feel of hierarchy. I’m not sure what implications this would have on screen readers.

      • Jane Wells 2:34 am on November 28, 2011 Permalink | Log in to Reply

        We’re looking strictly for accessibility (as in Section 508) feedback here, not general usability.

        Can you let us know what your background with accessibility includes so we have some context for your participation? Thanks.

        • Gooitzen van der Ent 7:16 pm on January 7, 2012 Permalink | Log in to Reply

          Hello Jane,

          A bit difficult to jump in on a conversation somewhere. Read you were looking for people to help out.

          Made an inventory of accessibility within WordPress. Sure it can be improved. Feel free to use it where you can. Hope it helps.

          • Gooitzen van der Ent 7:21 pm on January 7, 2012 Permalink | Log in to Reply

            Of course adding the link to the blog post might help…. :duh:: 😉

            Blog post title: Accessibility & WordPress
            Blog post link: http://ecodelphinus.com/2012/01/07/accessibility-and-wordpress/

            I have multiple years experience designing for accessibility. However, at the moment a bit stretched for time and means to do any testing and take on volunteer jobs at the moment. Will try to keep an eye on things, and help where possible.

            Would like to add or see added a, clearly marked, accessible and WCAG 2.0 theme to WordPress.com if possible. Seems to be missing at the moment.

    • Larry Thacker Jr. 2:28 am on November 28, 2011 Permalink | Log in to Reply

      Not all screen readers are very good at handling dynamic content, so the simpler the better. Thus I prefer the first option. I am not an accomplished web coder, but perhaps using heading levels would help a screen reader user approximate the second option by heading level navigation, which all screen readers I know of can do.

    • SG 2:54 am on November 28, 2011 Permalink | Log in to Reply

      C. I think a mix of A and B would be more efficient, as explained below:

      Most admins keep their most-used top-level items expanded most of the time. Tabbing should work as described in B, jumping from top-level to top-level, and hitting enter expands any non-expanded groups. When tabbing arrives at an already-expanded group, it should work as described in A, and tab to each sub-level element. Hitting enter on an expanded element should collapse it.

      My 2 cents. 😉

      • Jane Wells 2:56 am on November 28, 2011 Permalink | Log in to Reply

        In 3.3, there’s no more click to expand/keep expanded… everything is done with flyouts (unless you don’t have javascript enabled) so that everything is (for mouse users) one click away.

        • Steveorevo 3:00 am on November 28, 2011 Permalink | Log in to Reply

          Forgot about that in the latest beta sounds like B would even be more to the point as A would entail excessively long tabbing operations. :-)

        • SG 5:39 am on November 28, 2011 Permalink | Log in to Reply

          Jane, in that case A does work better, but I still think it could be augmented.

          How about when tabbing over the top-level items, the currently selected item is automatically expanded (to show what’s inside). If the user wants to go down, they hit enter, if not, they keep hitting tab to traverse the remaining top-level elements. Naturally each auto-expanded item is then auto-collapsed upon tabbing away from it.

          Have you thought about allowing the use of arrow-keys once the user has ‘tabbed’ into the menu area? Down to jump down to the next element within the current hierarchy (eg. top-level items), right to go down into sub-elements, and left to go back up to the top-level parent.

    • Peter Bossley 2:56 am on November 28, 2011 Permalink | Log in to Reply

      I am a screen reader reliant user of Word Press and I believe option B is preferable, assuming that you can make this function properly with a wide range of screen readers which might be difficult, but possible. Heading navigation would be good in this context since screen reader users are used to navigating by headings to skip to the next set of controls, etc. While keyboard shortcuts are nice to haves, because of screen readers heavy use of keyboard hooks for quick navigation mode they are somewhat less useful for screen reader reliant users out of the box. In other words they have to know the shortcuts are there and then activate bipass mode to pass the keystrokes directly to the browser.

    • Graham Armfield 10:47 am on November 28, 2011 Permalink | Log in to Reply

      My gut feel is for A as tabbing is surely the lowest common denominator of keyboard accessing links etc on a page.

      B sounds appealing but how do you intend to convey to keyboard users (both sighted and non-sighted) how the menu functionality works before they come across it? If that can be squared successfully then I’d probably favour B.

      Another technique I’ve experienced is using the space key to open menus, but I guess that’s less useful these days with touch screens.

    • Everett Zufelt 11:08 am on November 28, 2011 Permalink | Log in to Reply

      I think that B would be the easiest to use, provided that you can provide some type of affordance to educate users about the functionality. The common paradigm, as I currently experience it, is that tabbing cycles through all items in a superfish style of menu. That being said, the assistive tech / keyboard only user that is tabbing through a page is * incredibly * inefficient.

      I think he problem should be ‘How can we provide an affordance to indicate to users that the top level menu items, when activated, expose a sub-menu?’. Once the menu is exposed I would think that the ability to tab through the sub-menu items would be expected by most users.

      Drupal Core Accessibility Maintainer, 7 years experience using screen-readers.

    • Léonie Watson 11:47 am on November 28, 2011 Permalink | Log in to Reply

      Option B would be the preferable default solution IMHO. To offer a really good experience, give people the option to enable option A if they wish though.

      ARIA could be used to build in the affordance needed to make option B really usable, for recent screen readers at least. Check out the menu, menubar and menuitem roles:

      Headings really shouldn’t be used to represent the menu hierarchy. It’s semantically incorrect for one thing, and it negates the usefulness of headings as a navigation mechanism within the content of the page for another.

      • Graham Armfield 12:05 pm on November 28, 2011 Permalink | Log in to Reply

        Hi Léonie, do you have an example site that uses option B and ARIA to ‘build the affordance’ that you would consider to be accessible. I’d be really interested to analyse that.


    • Bob Easton 12:42 pm on November 28, 2011 Permalink | Log in to Reply

      previously: consultant for IBM’s Accessibility Center – now: recently retired

      Many of us favor B because the function feels right. Screen reader users (blind and low vision) are the most difficult to accommodate. Implementing choice B with conventional HTML, and even with script supplemented HTML is not only difficult to do well, but leaves us with the problem several have noted: how is the visitor informed of how the structure behaves.

      Léonie’s answer is the best because ARIA does exactly what is needed. ARIA was designed specifically for bring accessibility to dynamic implementations. The key is the “role” attribute. Just as screen readers (can, if enabled) announce HTML elements, they can announce ARIA roles. And THERE is how the visitor learns of the behavior. The screen reader will announce to the visitor that the top level is a menu, and that lower elements are menuitems.

      Graham: many examples can be found with a Google search for “aria menu example.”

      For anyone else not familiar with ARIA, the WAI-ARIA Overview at W3C is very helpful.

    • Sharron Rush 2:14 pm on November 28, 2011 Permalink | Log in to Reply

      +1 for Leonie’s suggestion. B is the best of those offered. Consider adding a level of access to the sub-menus that is operated using arrow keys. So you tab through the top, main navigation level and then use the down arrow to open and explore sub-items. You can see this type of navigation in action on our web site http://www.knowbility.org. And congratulations WordPress on providing these accessibility options!

      Sharron Rush
      co-author, Maximum Accessibility
      Executive Director, Knowbility, Inc

      • Graham Armfield 6:20 am on November 29, 2011 Permalink | Log in to Reply

        Thanks for the link Sharron. I’ve had a look at the navigation and it works as you say. But I’m wondering how you’re informing people that they need to use the up/down keys when the flyout menus appear?

        I’ve also tried with NVDA and JAWS in Firefox but I’m not getting any audio prompt to indicate that a submenu is there.

        • Bob Easton 10:50 am on November 29, 2011 Permalink | Log in to Reply

          Do you hear “menu” spoken? That should be the clue. Once the visitor hears that word, they should know there are menuitems reached by arrow keys. Unfortunately the blind have to know a lot more about how things work than most of us. Hearing an ARIA role announced, they learn / know to take the right action.

    • esmi 3:27 pm on November 28, 2011 Permalink | Log in to Reply

      I’ve already argued strongly against option A and for option B on the wordpress.org support forums as I think A would create significant problems for keyboard navigators. I do like Leonie’s suggestion of using ARIA as an enhancement – just as long as there is no reliance on this additional functionality. Not all non-mouse users will be using screen reading software.

    • Jane Wells 3:41 pm on November 28, 2011 Permalink | Log in to Reply

      Looks like B is the clear winner, which is handy since that’s what went into core over the weekend. We’re at the end of beta, pre-RC right now in the 3.3 dev cycle. We tried to catch as many things like this as possible, but there were a lot of changes with the admin menus and admin bac/toolbar, so we may have missed something. If anyone would be willing to put the 3.3 beta through its accessibility paces, if we missed other things we can try to hit them before we get to RC. Will start new thread for that, though.

    • Everett Zufelt 6:14 pm on November 28, 2011 Permalink | Log in to Reply


      You say that B went in over the weekend. Can you say how you’ve addressed the requirement for there to be an affordance to assist sighted and visually impaired users about the functionality of the top level menu links?

    • sam C 11:56 pm on November 28, 2011 Permalink | Log in to Reply

      D. I think the WordPress admin menu should work the same way the Fluency Admin plugin (https://wordpress.org/extend/plugins/fluency-admin/) works it. Because when user clicks a link, it doesn’t take em back to the top.

      • Jane Wells 12:35 am on November 29, 2011 Permalink | Log in to Reply

        The point of this thread is to deal with non-click situations, when there is no mouse or equivalent input device.

        • Sam C 10:24 pm on December 10, 2011 Permalink | Log in to Reply

          Thanks for that clarification. I was alluding to the fact that, that mention plugin has short-cut keys. But when you said “Tabbing”, I first thought of the Tabs or buttons in general, but I now know you actually mean the “Tab” Key on my keyboard. In my UX experience when developing AIR applications (that’s, of course, when I’m not developing WordPress sites. 😉 ) it seems to be standard that the tabbing on menus that have sub-menus go as choice “B”, but the “spacebar” key usually expands the parent tab just like in the [+] to [-] show/hide links does on many sites. However the “Enter” key is what executes the selected item.

          Thanks Sam

    • Everett Zufelt 3:47 pm on November 30, 2011 Permalink | Log in to Reply

      Since option B has been implemented, I am curious if anyone has tested it? In particular, I am curious about what affordances are available to indicate the functionality of the link?

      • Andrew Ozz 8:37 pm on November 30, 2011 Permalink | Log in to Reply

        The full “first run” version went in yesterday evening. It implements role=menu, role=menuitem and aria-haspopup on both the top menubar and the left-side menu.

        The functionality is still enhanced with JS: Tab to select, Enter to open submenus that have role=menu, Tab to go through submenu items when opened (visible) , Esc to close the submenu and return to the top menu (and select it), then Tab to go to the next top menu item.

        As always we would appreciate more testing of this, especially by people that work in that field or by screenreader users.

        • Jane Wells 10:37 pm on November 30, 2011 Permalink | Log in to Reply

          Bearing in mind that today is RC, so no more enhancements. Only addressing blocker bugs that are bad enough for enough people to prevent moving forward for the rest of 3.3 (less than 2 weeks).

          Any enhancements at this point will go in the dot release or 3.4.

    • Everett Zufelt 10:21 am on December 1, 2011 Permalink | Log in to Reply

      I don’t rally have time, but if someone can provide me with credentials to a installation to test I will test these menus. My intuition tells me that you will have some confused users. Particularly since menu and menuitem are ‘widget’ roles (interactive), and can cause screen-readers to work in a way that some users may find disorienting.

      The menu / menuitem roles are really designed to mimic a menu in a desktop application (think the ‘File, Edit, View, etc.’ menus in Google Docs).

      • Jane Wells 11:51 am on December 1, 2011 Permalink | Log in to Reply

        We don’t generally set up test installations for volunteers to QA on, as the main point is to see how things work on real setups (vs our own protected/quirky environment). The beta tester plugin can turn any WP installation into a test site running trunk: https://wordpress.org/extend/plugins/wordpress-beta-tester/

        If the Aria stuff is likely to confuse people we can delay release to pull it out, but it was added at the suggestion of comments on this thread. We released RC early this morning and are not supposed to still be making changes, so I would say either make a very specific suggestion that you think will address the problems you’re anticipating and provide a link that will explain the how-to so @azaozz can look into it, or hop into IRC today to discuss real-time. irc.freenode.net #wordpress-dev Thanks.

    • Everett Zufelt 12:50 pm on December 1, 2011 Permalink | Log in to Reply

      @westi on #wordpress-dev setup a test environment for me. I tested with FF 8.0 / JAWS 13.

      1. I logged into the site.
      2. I was taken to the Dashboard.
      3. There was nothing identified as ‘menu’
      4. There was a ‘list of 14 items’ near the top of the DOM.
      5. The first item ‘Index’ had a sub-list of 2 items, but they had no content (no words / links / anything).
      6. Activating another item in the first list (Users) took me to a new page.
      7. @westi told me that ‘Posts’ is one of he top level menus, JAWS (control + f) could not find ‘Posts’ on the Dashboard page.
      I hope this feedback helps.

  • esmi 1:53 pm on November 7, 2011 Permalink


  • esmi 9:34 pm on October 17, 2011 Permalink

    Try to figure out why it was considered necessary to add the title of an image as a title attribute to the image markup when inserting images into a post. Whose idea was that? The image’s title attribute serves no real purpose for sighted users but creates a whole load of completely unwanted noise for some screen reader users. Additionally, the title attribute is completely inaccessible to sighted non-mouse users.

    So what’s the point of it?

  • Jen 4:32 pm on May 6, 2011 Permalink
    Tags: atag 2.0, w3c   

    Hello, accessibility experts. We were recently contacted by Jeanne Spellman, one of the editors of the w3c ATAG guidelines. The Authoring Tool Accessibility Guidelines (ATAG) 2.0 Working Draft was published on April 26. The update is almost finished and they will be taking comments until May 24, 2011.

    They also have a companion document, Implementing ATAG 2.0 to define how authoring tools can help developers produce accessible web content that conforms to Web Content Accessibility Guidelines (WCAG) 2.0. It also defines how to make authoring tools accessible so that people with disabilities can use them.

    It would be great if we could try to meet the new guidelines with 3.2 as much as we can.

    • tady 4:17 pm on May 9, 2011 Permalink | Log in to Reply

      Looking forward to it Jane! I’ve studiously skipped around ATAG for the moment, but as the intention is to make the front end AND backend more accessible, I look forward to studying it more!

    • Tady Walsh 8:18 pm on May 11, 2011 Permalink | Log in to Reply

      Thanks for the link Jane, certainly one of the interesting elements to study, but I find it very interesting how many of the items say “If this is applied in a web application, please refer to the WCAG 2.0 guidelines” (not in so many words, but you know what I mean). Still, I know there’s more to it than just that so further study will have to ensue!!!

    • Sylvia Egger 2:02 pm on June 12, 2011 Permalink | Log in to Reply

      Is there any Update on the accessibility effort until now? It seems to be a little bit quite so far …


      Sylvia Egger

    • Elpie 1:23 pm on June 16, 2011 Permalink | Log in to Reply

      Since you asked, here are the results of my test with the new admin UI….

      I use keyboard navigation all the time as this speeds up my work. I also work with users who have disabilities.

      At the moment, the dashboard contains 9 (yes, NINE) links with Tabindex=1.
      Tabbing through gives no indication of where you are until you hit the Quick Press when the cursor suddenly appears for the first time, but there’s no focus or highlighting to tell you where the heck it is.
      It takes 3 tabs to get off the index.php, then another two to take you off edit.php. Once either is selected I haven’t a clue where the cursor goes to.
      The only clue that the cursor is even on a link on the dashboard is the name of the files showing at the bottom of the browser.
      To most people, these file names won’t say much. In order, this is the tab navigation:

      post-new.php (well, thats a new post but has a disappearing cursor if you select it)

      Then nothing to indicate that the cursor has jumped over to Quick Press title. Nothing shows in the browser to indicate the cursor has moved.

      Tab through Quick Press – can’t get to reset. No focus on “Submit for Review” and the colour hides the fact that the cursor is there.

      Next, back to index.php
      Then /?unfoldmenu=1
      Followed by edit.php
      Followed by /?unfoldmenu=1
      Followed by profile
      Followed by tools
      Followed by /?unfoldmenu=1
      Ending with site URL (outside of admin, with no warning that this is happening).

      For each menu, navigating by keyboard to submenus doesn’t happen. unfoldmenu doesn’t inform the user about what this is for or does.

      I’ve spent a couple of hours trying to work out how to use keyboard navigation in the new UI, and not having any success. I keep getting totally lost because I can’t see where the cursor is going.

      • Jane Wells 1:41 pm on June 16, 2011 Permalink | Log in to Reply

        Which browser(s) did you test with?

        • Elpie 10:25 pm on June 16, 2011 Permalink | Log in to Reply

          Opera 11.11, Firefox 4.0.1, IE9.1, Chrome 12.0.742.100, and Safari 5.0.5.

      • Andrew Ozz 11:32 pm on June 16, 2011 Permalink | Log in to Reply

        @Elpie are you testing 3.2-RC? The “/?unfoldmenu=1” is gone from the menu there, but don’t think many tabindex attributes have changed. As far as I can tell we can drop tabindex almost everywhere making the tabbing “flow” better. Exception will be the title on the write/edit post screen and few others.

        We can try adding some kind of CSS highlighting to selected links and buttons perhaps even have a setting for more accessible admin.

        • Elpie 1:32 am on June 17, 2011 Permalink | Log in to Reply

          @Andrew – I just did after posting this here. For some reason, I’d missed seeing the later release or the change in trac at https://core.trac.wordpress.org/changeset/17943

          Removing the “/?unfoldmenu=1″ anchor has helped a bit but the backend is still a nightmare for keyboard navigation.

          I don’t recommend the use of tabindex. It is one of those attributes that came into favour with people jumping on an accessibility band-wagon without giving any thought to structure and site architecture. WebAIM has this to say about it:
          “The tabindex attribute was created to allow web developers to customize the tab order of web content. Most of the time, tabindex is not necessary. It should only be used in cases where the default tab order is not ideal and when the tab order cannot be changed by rearranging items in the content and/or by altering the style sheet to reflect the best visual arrangement. These cases are rare. In almost all circumstances, WebAIM recommends against using tabindex. ”


    • Elpie 1:29 pm on June 16, 2011 Permalink | Log in to Reply

      Relating to the new TwentyEleven theme – this cannot be navigated using the keyboard.
      Also, for accessibility, it’s too soon to use many HTML5 elements. As of May, the findings in this report were still correct. http://www.accessibleculture.org/research/html5-aria-2011/
      I recommend that the theme development team and UI working group reads that article.

      • Elpie 1:38 am on June 17, 2011 Permalink | Log in to Reply

        Reply to self – the latest RC provides reasonable keyboard navigation of the frontend. There are a couple of places on single pages where focus gets lost and so does the user.

        However, the plethora of H1 tags is bad, bad news. HTML (5 – to clarify) is still being developed. hgroup tags have been in and out of the spec and are very likely to be replaced. No browser recognises them anyway. There are debates amongst those of us working with HTML 5 over the use of heading tags but general consensus is that it is too early to mess with the document outline. Screen readers see those h1 tags as top-level so, for accessibility, it is far wiser to stick with the h1-h6 hierarchy until HTML 5 is further developed.

    • Elpie 1:45 am on June 17, 2011 Permalink | Log in to Reply

      9th August, 2009, this was posted to the wp-accessibility list. I am reposting it here because it contains links to information I feel is important to keep, especially since the mailing list is being retired.

      Re: http://joeclark.org/access/webaccess/WordPress-ATAG-evaluation.html

      Quote me:
      “WordPress has moved on, and so has both the understanding of accessibility and the guidelines themselves.

      The three sets of guidelines we really need to focus on are:

      ATAG (specifically the backend) http://www.w3.org/WAI/intro/atag;
      WCAG 2 (both frontend and backend) http://www.w3.org/WAI/intro/wcag;
      WAI-ARIA (again, applies to both frontend and backend)

      Ironically, since Joe wrote that evaluation, WordPress has gone backwards in some areas, despite making up a lot of ground in others.
      It would be great to do a new evaluation against the current guidelines – this could help provide focus for this group.”

  • Jen 12:03 am on May 6, 2011 Permalink
    Tags: , review, , twenty eleven   

    If anyone would like to take a stroll through 3.2 or the new default theme, Twenty Eleven, and identify any accessibility issues, now would be the time if we want to patch them before release. You can access 3.2 trunk by using the beta testers plugin: https://wordpress.org/extend/plugins/wordpress-beta-tester/

    Any accessibility professionals interested in being part of the new accessibility working group, please leave your info in a comment on this post and I’ll get you added to the blog so you can introduce yourself.

    • Chuck Reynolds 12:33 am on May 6, 2011 Permalink | Log in to Reply

      I still really dislike the big circle comment count thing…

      in /themes.php?page=custom-header the header image at top shows as a broken image. source shows

      On single posts, the entry-content seems like there’s too much padding on top… the separation from the h1 to the post content is a pretty big gap.

      I’ll mess with it more later. nav and search expanding seem fine – tried to break that but seems alright.

      • Jane Wells 12:53 am on May 6, 2011 Permalink | Log in to Reply

        I think you misunderstand this blog’s purpose. It refers to accessibility as in section 508, screenreaders, visual acuity issues, manual dexterity disabilities, etc. This is not about usability or design preferences, so the comments above are not really what we’re looking for here. That kind of stuff is dealt with over at make.wordpress.org/ui.

    • Barry Johnson 1:37 am on May 6, 2011 Permalink | Log in to Reply

      Accessibilty Specialist. Federal 508 SME

    • Bidhan Adhikary 4:01 am on May 6, 2011 Permalink | Log in to Reply

      Hello, I am a technology blogger. I would like to be a part of the new accessibility group.

      • Jane Wells 4:52 pm on May 6, 2011 Permalink | Log in to Reply

        Hi Bidhan. Thanks for your interest. Do you have experience as an accessibility professional? That’s really what we’re looking for in this group.

    • Tady Walsh 8:49 am on May 6, 2011 Permalink | Log in to Reply

      Hiya guys, I’ll give it a check over for you. I’ll check it against WCAG 2.0 and test for common accessibility issues (we don’t use Section 508 in Ireland). I’ll install locally and give you a report later. Any particular method of contact or is this forum ok?


    • Tady Walsh 10:08 am on May 6, 2011 Permalink | Log in to Reply

      Ok guys, had a quick review of the code there.

      On first impressions, I must say, VERY impressed at the improvement in overall accessiblity levels which have greatly added to my overall impression of WordPress. I’m also delighted to see HTML5 implementation in the Twenty Eleven theme, it looks great and will be a great example of a CMS moving with the times. There are one or two VERY small accessibility suggestions I would make.

      First, there is no label on the Search field. You could argue that with the placeholder text, it’s not really necessary. For absolute conformation with the requirements, I’d recommend you add it. It can be hidden using an “accessibility-hidden” class or something to that effect which would have the following CSS in it:
      margin: 0 0 0 -1px; padding:0; height:1px; width:1px; position:absolute; overflow:hidden;clip: rect (0 0 0 0);

      Second, a minor issue on the theme colours. The edit button’s text against the background colour has a luminosity of 2.3:1. For AA WCAG, this should be a minimum of 4.5:1 and for AAA, it should be 7:1. Many other colours I checked that I thought wouldn’t pass do (and do by some margin, a learning experience for me!), so this is, I would suggest, a small change to make.

      On this, there is a question doing the rounds of the accessibility community which is, if an element is styled like a button, why is it’s fallback not a but, i.e. why are we styling anchor links to look like buttons. It seems the most logical fallback on an element styled like a button is that it should be a button. Personally, I don’t have a problem with this, as using a button would require a javascript onClick event, which has it’s own inherent accessibility concerns (what if the user is one of the 2% of people not using JavaScript!).

      Finally, I’m not sure how accessible you require the dashboard/backend of WordPress to be, but on the assumption that you do (to some degree), I would suggest that the code regarding the toolbar at the top of the page be moved, in the code, to the top of the page! Screen readers and the like will read the content from the source code in hierarchical order, regardless of style, so if this is the case, the very last thing the user will get to is the toolbar. There is the alternate arguement that they will have to tab through the toolbar before getting to the content, so maybe you could have another (hidden) skip link, that brings you to the toolbar at the footer, which is only shown when logged in.

      I hope this has been some help. If I get a chance over the weekend, I’ll take another longer look at it. Otherwise, I think it is a vast improvement and well done on taking the time to do this.

      • Jane Wells 3:39 pm on May 6, 2011 Permalink | Log in to Reply

        Thanks for the helpful feedback! Will try to get tickets started for these things asap. And yes, we would like the back end to be accessible. :)

      • Mark Jaquith 3:56 pm on May 6, 2011 Permalink | Log in to Reply

        There are serveral reasons for having the admin bar at the bottom, HTML-wise (listed in no specific order). One is speed. Putting the HTML (and the JS that powers it) at the top results in “blocking,” which makes pages slower to load. And if the HTML is up top, but the JS is at the bottom, then the bar doesn’t work for a variable amount of time. Second, it is better for search engines. Content should be nearer to the top, not buried under menu bars. Thirdly, it is better for accessibility, as you noted, in the respect that people don’t need to continuously get past all that HTML to get to the content.

        Your hidden skip link idea is an interesting one! Thanks for the feedback.

        • Tady Walsh 4:25 pm on May 6, 2011 Permalink | Log in to Reply

          No problems, glad to help. Fair points made there Mark, and I do agree with you completely about the load times, etc. I kind of thought about it while writing the suggestion, and it made more sense to me to have it at the bottom while I wrote my thoughts, which is why I suggested the skip link. I think it’s the only way to ensure accessing the toolbar (accessibly) from the top of the page.

    • Sylvia Egger 10:28 am on May 6, 2011 Permalink | Log in to Reply

      Using WordPress for many years I decided last year to make WP default theme Twenty Ten more accessible with a child theme (Accessible Twenty Ten): http://accessible.sprungmarker.de/2011/01/accessible-1-0/

      I also made the html5 default theme Twenty Ten Five more accessible (http://accessible.sprungmarker.de/2011/04/accessible-five/).

      My special accessibility interest is of course the WordPress front end, but I also try to get WP editor more accessible developing plugins as MCE Accessible Language Change (https://wordpress.org/extend/plugins/mce-accessible-language-change/) which makes it easy to integrate language change in the content of the editor.

      I would wish to contribute in WordPress accessibility, especially in developing the new default theme more accessible than Twenty Ten.

      Would be great and I am glad that WordPress developers now will have a stronger focus on accessibility.

      Sylvia Egger

    • Keith Hinton 10:41 am on May 6, 2011 Permalink | Log in to Reply

      Hi folks.
      I’m simply a user of WordPress, and hope to test out the accessibility of the upcoming stuff you mentioned on the comments.
      I’m a totally blind user, and primarily use three different Windows-based screenreader programs.
      NVDA (Non Visual Desktop Access) JAWS for Windows from Freedom Scientific, also called (jfw) and also have in the last year began working with SystemAccess, from Serotek.com.
      I was working with GWMicro.com’s Window-Eyes screenreader, but I’m growing tired of waiting around for them to rewrite the browse mode, stick aria support into there product, and such.
      Until they do this, I will not be actively testing it with things.
      Primary browsers I am using:
      Internet Explorer Nine and Firefox Four.
      I mention this information because is primarily what I have at my disposal for accesibility testing.
      I’d like to know more information on how I can test (since I am blind) I won’t be able to ehlp you folks with visual based questions like color, and other little issues like that.
      They’ll need to be about thigns like: if I can’t navigate by heading, if form feeleds are not properly labled, and so on.
      One thing (though I could be wrong) was when I began using WordPress a few months ago, sometime last year, was that I found switching to a new theme to be toally inaccessible, no matter what screen-reader I used.
      Has this ever been looked into?
      I’m also curious if a time limit exists as far as gaining access to WordPres through the beta-tester plugin.
      I ask because I don’t have WordPress presently installed.
      A friend of mine is giving me access to a web hosting platform where I ‘ll be able to set this up.
      As soon as I do, I’ll happily grab the beta-testing plugin you meitno, so will be saving this page to my favorites (assuming this post doesn’t go down soon) so I can remember exactly where to grab the plugin.
      Searching the plugins is nice, but having the direct location is far better!
      Take care everyone!
      If using my primary email, I won’t accept spam. I get enoguh spam messages from epople I don’t know as it is. :) Just a point.
      You’ll find my email in the comment submission form!
      Well labled by the way, although I have one suggestion in future development right now on the comment form.
      The last labled form you have is the “website:” edit box.
      The comment box only says “edit” perhaps lableing it “comment:” would be better, so that all screenreaders would say “comment”?
      Just a thought!
      Having an unlabled edit box in any case is a bad idea (especially because it is probably to the majority fo new users who are blind and such using wp they might not know that you wish a comment to be present in that feeled. So they might think: “What”?
      Anyhow that’s that!
      One other public feedback for everyone here:
      The replybutton however is labled so only the comment editbox is not.
      Can anyone confirm if this is always the case ( regardless of theme)? If so, then this small but seirous adjustment needs to be made by the primary coders of WordPress (of wich I am not.)
      I can only test. I cannot implement my own suggestion about a small suggestion like insuring that in future software releases beta or otherwise that the comment box is labled like this: “Comment:”
      Without the quitees.
      Our screen-reader will identify the box as an edit box if you folks code it properly, so just typing:
      as the lable is good enoguh in future releases.
      Please submit this feedback to Mat and th other primary developers, I’d appreciate that as a first-step of the future of WordPress accessibility!
      Thanks a lot!

    • Tady Walsh 10:51 am on May 6, 2011 Permalink | Log in to Reply

      Typical! Should have read that properly. I misread “leave your info” as, leave your info about the accessibility of the theme.

      Gimme a shout if I can be of more assistance. @tadywankenobi

    • Azizur Rahman 12:23 pm on May 6, 2011 Permalink | Log in to Reply

      I have found one issue. you got my email and I am on twitter @azizur

    • esmi 3:15 pm on May 6, 2011 Permalink | Log in to Reply

      OK – first test I ran and it failed miserably! Please, please, don’t assume that every keyboard navigator is using a screen reader. The vast majority of them won’t be. The skip link isn’t available visually (and that’s a pretty basic fix these days) and there is absolutely no link highlighting. End result: you’re completely lost within about 3 keypresses (?sp).

      And while you’re looking at highlighting for sighted keyboard navigators, what about some highlighting on form imputs that have focus? Again, very simple to implement but with a major impact on overall accessibility.

      Contrasts – why black text on a white background again? That’s going to cause major problems for most dyslexic users and a significant number of visually-impaired users (ie those using screen magnifiers). A contrast of 21:1 really isn’t necessary for a default stylesheet. Dropping #000 down to #404040 (or even #505050) would still comply with WCAG 2 AAA requirements in terms of contrasts. Bizarrely, all links fail AA contrasts miserably (only 3.6:1), so I’m struggling to find the logic here.

      The :visited link pseudo styling is also missing. I’d argue that could be an access issue for those with reading, language or learning difficulties. As could the removal of the underline on links. Mouse users don’t really need the underline onhover. They get feedback from their cursor. Some color blind users, however, may have trouble locating non-underlined links. Try greyscaling a page and you’ll see what I mean.

      Not sure I agree with the plethora of H1 tags in terms of providing a logical and hierarchical header structure in order to convey a mental model of the page, either. Navigating the main posts page via a Headings List is going to be real fun!

      Overall and after an initial scan, I’d describe my reaction as “disappointed”.

      • Jane Wells 3:38 pm on May 6, 2011 Permalink | Log in to Reply

        This is super helpful, thanks! Bear in mind that the theme team are designers by trade, not accessibility experts, so let’s not assume any decisions were made to impede accessibility — they were made to make a great-looking theme. If we all assume the best, not the worst, intentions and keep our tones in line with that, it makes critical feedback much easier to take gracefully.

        • esmi 2:31 pm on May 19, 2011 Permalink | Log in to Reply

          Sorry – I hope that implication didn’t come across in that way. If it did, it’s probably born out of frustration as these are some of the issues I’ve been trying to battle against over many years. I think the situation regarding accessibility might well be summed up by a comment I published some years ago:

          My own personal feeling is that, because visually impaired users have been early adopters of assistive technology and have, very successfully, highlighted the problems that they face, the balance within accessible web design has become somewhat skewed in their direction.


      • Jane Wells 3:47 pm on May 6, 2011 Permalink | Log in to Reply

        @esmi: Do you have a good link to information about why black on white text is problematic? If we can point the theme designers to information that can help rather than just telling them it’s bad, that would be helpful.

        Body text appears to be #333, not #000; which text are you considering problematic? Could you take a picture of the issues as seen with a screen magnifier?

        • Tady Walsh 4:21 pm on May 6, 2011 Permalink | Log in to Reply

          It’s been found that very stark contrast between text and background can be of hinderance to people who suffer from extreme dyslexia. This is often aided (especially for kids in school) by using glasses with tinted lenses to change the background colour in relation to the foreground i.e. printed text on paper. Reducing the foreground colour “softens” the text against the background and can aid making it slightly easier to read.

          I would hasten to add that, like fingerprints, not all types of dyslexia are the same, in the way that not all colourblindness is the same. There will be no “one fix, fix all” solution for this but esmi’s points are quite valid.

          I would point out to esmi though, that the CSS style sheet does have “:focus {outline: 0; }” which is accompanied with the comment “remenber to define focus styles!” This does push the responsibility back on the developers of the site to ensure that a focus style is provided for both keyboard and clicked indications.

          As HTML5 has changed the use of headers to apply within specific articles or sections, there is now no longer a requirement for single H1’s on the page, but I agree with esmi, there should still be some rationale behind their application. I fear that removing the strictness of their hierarchy will lead to worsening accessibility support, but this is a conversation to be had with the HTML5 gods! WebAIM recently completed a survey with users who require screen readers and found (surprisingly) that just over 50% (of ~1250) expected to find two H1’s on the page. I think this is a conditioning thing; the developers have put two H1’s on pages for so long, that the users who require screen readers have come to expect to find them. That’s not to say it’s correct, but I think this is where the reason arises.

          Hope this helps…

        • esmi 2:26 pm on May 19, 2011 Permalink | Log in to Reply

          Sorry for the slow response. Been semi laid-up recently. The information I have came from some research I carried out about 4 years ago on contrasts generally (I was looking at scoptic sensitivity & dyslexia particularly) . Check out the comments from Pat Rees on http://blackwidows.co.uk/blog/2006/10/03/does-w3c-get-its-contrasts-wrong/

    • John Brandt 4:07 pm on May 6, 2011 Permalink | Log in to Reply

      First, I would like to congratulate WP for creating an opportunity allowing input from users to test the accessibility of upcoming releases. I will be encouraging my colleagues to take a look and provide input.

      As for my own testing: I have downloaded the plugin and read the directions, but I am reluctant to activate and update my own WP blog with the new version for testing since it is not a test site and I need for it to work flawlessly. I don’t have a WP test site set up at this time so I’m wondering if others who have downloaded and tested the new beta version would be willing to post the URLs of their locations so I can have a look.

      Another comment is that it looks like you have gotten some good feedback already. The issue of correctly labeling input boxes is critical and absolutely must be fixed – this has been a problem for a long time. I am less concerned about the Skip to Content issue – I understand there are others who are passionate about this. I’ve blogged about this recently – anyone really interested can seek that out. That said, I would encourage consideration of creating the WP core be written so that naturally the content would appear at the beginning of each node and the navigation at the end. The CSS of the theme can be used to relocate the navigation to where ever on the page you desire, but screen readers will “see” the content first thus removing the need for the “skip to” link.

      The only other observation is to ask reviewers to please separate their discussions and recommendations regarding theme/styling issue from core function issues. Some of the concerns about contrast and layout are theme issues. While I understand that it is necessary that the initial install WP theme be accessible “out of the box,” let us remember that just about every WP user will install a new theme after they install the core. There are currently few theme builders out there who have build accessible versions – I hope more will appear in the near future. I suggest making the initial theme as “vanilla” as possible.

      My last comment is that I believe good universal and accessible web design means allowing users of all types to be able to easily and effectively access content using whatever assistive technology they have. By this I mean attempts at creating a design that is focused on one group over another should be avoided. It also means attempting to employe assisting techniques (such as text enlarger widgets and color style changer widgets) are not necessary. Lest we not forget that a fully accessible website can be rendered inaccessible – or less accessible – by one user posting something. Accessibility requires vigilance and training/education just as much as it mean good initial design.

      John Brandt

    • Sylvia Egger 9:56 pm on May 6, 2011 Permalink | Log in to Reply

      Hi – I checked your demo site and my own installation on a11y issues:

      first of all template accessibility is quite good – there are some issues – I will tell about them. But getting the WordPress front end fully accessible is always a combination of templates, editor, plugins and widgets – a complex process. Let’s just keep that in mind.

      I want only to bring issues for Twenty Eleven and it’s templates – of course one has to fix a11y issues in default widgets and plugins …

      Most of the a11y issues are known and not took in consideration for a long time now – the better they will fixed soon. :)

      1. color and contrast issues – even if you only take WCAG 2 AA in consideration there are some issues which are easy to fix:

      the blue link color
      grey text in input field
      main navigation is not very readable
      reply button and text
      subheadline grey on white

      If you get further to level AAA you can add image caption text, comments header text, footer text colophon, default widget titles grey, article post meta grey, comments headline etc.

      I tested only the light version so far …

      2. keyboard focus: an ever lasting topic of WordPress :) keyboard focus is so easy to realize but never was – was also mentioned already in comments here.

      no visible skip link on keyboard focus
      aside normal links there is no keyboard focus – a keyboard user does not really know where he is on the website
      there is one on forms – a transition making labels and required asterisk vanish. :) this is a really nice thing, but one has to remember what the field is for and if it is required.
      drop down menu (main navigation) is not keyboard accessible – this is a heavy problem, because WordPress is not that good in orientation issues. And how should a keyboard user get to a sub level in main navigation apart from accidentally?
      show room slider is keyboard accessible, but you get no focus to know that this is a slider :)

      Also link hover and active state could be improved – it’s only css so far :)

      3. heading structure
      First I was really “shocked” that every headline was H1, but you are of course using html5 elements as aside which can contain a H1.

      But JAWS doesn’t recognize this until now and has only to much H1 elements.
      Also NVDA doesn’t interpret the html5 hierarchy until now.
      There should be a choice if one keep the “old” hierarchy model to support screenreader users better than having a lot H1s elements. I know it’s not that easy to decide …

      4. without color: content should work without color information

      – showroom slider works only with background-color, so without there is only a white area.

      5. Zooming: I tested page zoom and text zoom separately

      – text zoom: the text in reply button get’s cropped, slider navigation in showroom’s featured post get’s over the post.
      Also IE9 does not zoom the text in pixel – so it would be better to make text via css more flexibel.

      – page zoom: slider navigation in showroom’s featured post get’s over the post.

      6. Screenreader

      search field and placeholder – JAWS and FF 4 is reading placeholder, JAWS and IE9 not, although I like this html5 form attributes, I fear the search field should have a title attribute to – while not having a label. And why is the search button integrated with display: none? Put him out of viewport would make a search for screenreader user more accessible …
      required asterisk: also current screenreader support aria-required to mark a field as required, you should have a kind of fallback: the asterisk – but it should be put into the label to be read by a screenreader in form modus – also should there be a kind of info what the asterisk mean …
      header image: should have a filled alt attribute – it is big and not in the background and the pictures are very nice – so every one should get them. :) Unfortunately there is up till now no possibility to add alternative text to the header images …

      So – this was a quick review and for a more detailed analyses I have to have more time. :)

      Hope this helps and greetings from cologne germany,

      Sylvia Egger


    • ramseyp 12:33 am on May 9, 2011 Permalink | Log in to Reply

      Hi all,

      First off – Bravo to the folks at WordPress for making this effort. It’s just awesome to see this happening.

      My first run through TwentyEleven, I see a few things that could be fixed, in terms of improving the accessibility.

      1) The Search Form:
      a) Put a label tag on the search form. If that just can’t be done, put a title attribute on the text input field. This input needs to be properly identified to assistive technology.
      b) If hiding the Submit button must be done, position it off the viewport, do not set it to “display:none”. Use “position:absolute; margin-left: -9999px;” That way, it is still accessible to assistive technology. Jaws, for instance, has, in the past, recognized display:none & won’t know the element is there.

      2) Links:
      a) Please underline them by default. Begin from the position of improved accessibility. Let users remove the underline if they so choose.
      b) Everywhere there is a style rule for “a:hover”, you should add “a:focus” to it. Keyboard navigation doesn’t :hover. If I’m tabbing through a site, the :focus selector is recognized. Which brings me to

      3) Outline:
      Setting the outline to 0 removes a handy device for non-mouse navigation of a page. While I like the acknowledgement of the need to set it in the stylesheet, Like the underlining of links, I would go ahead set it, allowing users to remove it if desired. What harm is done enabling it by default?

      I’ve got some notes on making changes to the administrative side of WordPress – I’m presenting at Knowbility.org’s AccessU 2011 in Austin on accessibility in WordPress. It’s a brief talk, mostly focused on accessibility in theming. I’d be glad to share my notes & slides.


    • Dominik Paszkiewicz 6:37 am on May 12, 2011 Permalink | Log in to Reply

      Hi Jane and all,

      My main focus is accessibility testing and consulting in this area. Currently I’m leading the large team of testers in the huge project of testing accessibility of 200 public administration websites in Poland.

      I’m also an avid WordPress fan and developer (3-4 websites per year on this platform) and I’d like to contribute to make WordPress more and more accessible tool for publishers and readers.

      I can not only contribute with my expert skills but also test with many disabled friends using large bunch of assistive software and equipment.

      I’d like to be added to the group focusing on accessibility.

      All the best,

    • Jeffrey K 2:00 pm on May 12, 2011 Permalink | Log in to Reply

      Hi, thanks for doing the work to make the template accessible. A dyslexic coworker explained it to me as seeing the foreground and background switch when using black and white. That is, the white background moves forward. Muting the colors seems to help, although you must keep the contrast up. Good tools to use are available from Juicy Studio at http://juicystudio.com/.

      Jeff K.S.

    • Felipe 1:47 pm on May 15, 2011 Permalink | Log in to Reply


      I’m Philippe Vayssière from Strasbourg, France. I work for a web agency (alsacreations.fr) as a web accessibility expert and front-end developer and in my spare time, I volunteer as an admin for alsacreations.com, a french speaking community dedicated to web standards and accessibility. This year I also dedicate time to the Libre Software Meeting that’ll take place in July in my town.
      Recent projects in the web agency I work for were all made with WordPress 3.x: yay for the Custom Post type and the ease of use for our clients :)

      I downloaded WP latest, installed it and the beta tester plugin locally, then reviewed the twenty eleven theme from an accessibility point of view and modified it a bit. More or less, I came to the same conclusions than Tady Walsh, esmi and Sylvia Egger.
      I’m going to install this modified theme online, that’ll be far easier to show and explain the modifications (:focus-related CSS rules, text zoom up to 200%, form elements, skip links moved and shown without breaking the design).

      I couldn’t test things like featured post and image, .page-link, .recent-posts, .ephemera. I guess I’d have to create more (sub-)Pages, categories than I already did and maybe activate widgets, but maybe such a dummy content already exists (for automated tests by example)? Can such a thing be imported in a blank installation?

    • Bob Easton 10:57 am on June 19, 2011 Permalink | Log in to Reply

      My experience in “taking a stroll…” is about the same as the last time I tried this (with Jane’s call to accessibility experts back before 3.1).

      As with accessibility consulting nearly everywhere, one part of the organization asks for improvement while another wants to march on to the latest and greatest technology instead.

      It ends up being a huge waste of time and interest when the accessibility consultant’s suggestion is answered with “I think that we are taking this ticket away from the subject and going back instead of forward. WordPress already stepped into HTML5 and this big improvement must not be degraded in any way, …” (see: https://core.trac.wordpress.org/ticket/17611#comment:58)

      Jane, you can’t expect accessibility experts to stick around and help when they’re met with these kinds of attitudes.

    • Graham Armfield 6:10 am on July 2, 2011 Permalink | Log in to Reply

      Bit late to this page I know, but just wanted to highlight a couple of points:

      Firstly the issue of keyboard accessibility. There are so many sites using the default WP theme now so it is imperative that any dropdown (or flyout) menus are keyboard accessible. The default theme ones are not. This means that parts of many sites can be impossible to reach – for example at http://www.crowncourtchurch.org.uk/

      It is possible to do accessible flyout menus. Have a look at: http://www.diggersworld.net/ which is built using WP.

      Use of Title attribute.

      I have read some comments from blind users very recently that putting the title attribute on text links as a matter of course is an annoying feature of many sites – including many (most) WP sites (including my own admittedly). The issue is that the title attribute is read out by screen readers as well as the link text. Perhaps there could be an easy option to suppress that in WP menus?

      Hope this helps.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc