Make WordPress Accessible

Updates from December, 2013 Toggle Comment Threads | Keyboard Shortcuts

  • Joseph Karr O'Connor 6:29 am on December 19, 2013 Permalink
    Tags: , ,   

    IRC Meeting: December18, 2013 

    Focus on Keyboard Accessibility

    The accessibility team met today to discuss a new initiative:

    • We will conduct an audit of keyboard accessibility and make those findings available to everyone
    • We will reach out to other teams to disseminate this information
    • Our short term goal is to add keyboard accessibility to everyone’s toolkit
    • Our long term goal is to institutionalize accessibility.

    Support Requests

    Two projects have asked for help from the accessibility team:

    • _Redd 12:29 pm on December 19, 2013 Permalink | Log in to Reply

      This…..is….fantastic! What a great way to channel the collective knowledge of the team and link it up to the developers. Thank you, Joseph! Best Christmas ever!

  • Matt Mullenweg 12:21 am on December 14, 2013 Permalink  

    Can anyone in the group take a look at the issues raised in this forum thread?


    • Joe Dolson 12:41 am on December 14, 2013 Permalink | Log in to Reply

      Not in a situation where I can look now, and I’m sure that the non-US contingent is not available right now, but will take a look ASAP. This is surprising; it was definitely something that got checked out earlier.

    • ceo 1:52 pm on December 16, 2013 Permalink | Log in to Reply

      The specific user’s issue has been resolved. Albeit inconclusively. Though, my guess is that it was resetting her browser’s zoom that fixed the issue by getting her out of the mobile view.

      In any case, there’s a ticket to address this bug. (Props to Rian.)

  • Joe Dolson 8:01 pm on December 12, 2013 Permalink  

    Remove title attributes trac tickets 

    I’ve created all new tickets for each file referenced from the original remove title attributes trac ticket (https://core.trac.wordpress.org/ticket/24766). I originally split it up into 17 separate tickets, but closed 3 of them already, because they had already been committed into 3.8 or earlier.

    I’ve added comments and/or patches, as relevant, on all of the remaining tickets – so please chime in with opinions as relevant! Many of these incorporate situations where a 2nd opinion would be valuable, because the title attribute incorporates relevant information and some alternative handling may be necessary.


    https://core.trac.wordpress.org/ticket/26549 – 2nd opinion
    https://core.trac.wordpress.org/ticket/26550 – 2nd opinion
    https://core.trac.wordpress.org/ticket/26551 – 2nd opinion
    https://core.trac.wordpress.org/ticket/26552 – 2nd opinion
    https://core.trac.wordpress.org/ticket/26553 – 2nd opinion
    https://core.trac.wordpress.org/ticket/26555 – 2nd opinion
    https://core.trac.wordpress.org/ticket/26558 – 2nd opinion
    https://core.trac.wordpress.org/ticket/26560 – 2nd opinion
    https://core.trac.wordpress.org/ticket/26561 – 2nd opinion
    https://core.trac.wordpress.org/ticket/26562 – 2nd opinion

  • Matt Mullenweg 5:27 am on December 12, 2013 Permalink  

    tl; dr: I think the team can prioritize its time and efforts better, especially around new development.

    At this point you’ve all probably seen https://core.trac.wordpress.org/ticket/26527

    If this had been raised a week ago, would have been no problem. Plenty of time to create and test a fix.

    The meta-issue is that this is an easy catch, and keyboard accessibility is on every basic accessibility checklist. It’s been present since the very earliest days of the THX plugin.

    As we do features as plugins, it’s really important that this group run and test those plugins every week to provide the perspective, experience, and patches to ensure the plugins meet the high standards of accessibility we set for ourselves. Even if a feature plugin never comes into core, it might become the canonical implementation of a given idea and be popular on its own right, and so worth investing time into.

    • Graham Armfield 10:14 am on December 12, 2013 Permalink | Log in to Reply

      Hi Matt,

      Whilst I share your frustration at the late discovery of the lack of keyboard accessibility on the new Themes page within the admin area of 3.8, it’s probably for slightly different reasons.

      To you, it seems as though we’ve failed to spot a fundamental accessibility flaw in a new piece of WordPress functionality. And I guess, judged on that criterion, we have.

      But from my perspective the frustration comes from an “Oh no, not again” place. Once again, a new piece of WordPress functionality has been developed from a concept through to a completed article without seemingly a single thought being given to how it would work for people who can’t see, or who can’t (or choose not to) use a mouse.

      You are right that keyboard accessibility is high up on every ‘basic accessibility checklist’, but I don’t see corresponding comments from you about this on the Make WordPress Core or Make WordPress UI blogs. It is vital that developers build accessibility in from the start.

      We’ve been here before. Think: custom menu builder, theme customizer, add media panel, etc. All of these functional pieces were keyboard inaccessible when first introduced. The add media accessibility issues are still oustanding a year after the functionality was introduced and many months after trac tickets were raised about it. The fixes for the other two mentioned are sticking plaster (band-aid) solutions that make life easier for some but do not address the issues for others.

      The role of the Make WordPress Accessibility team is multi-directional. We need to find accessibility deficiencies within the current WP setup and flag them up, We also need to provide resources that people can use to help them design and build with accessibility in mind. And yes, we need to ensure that new stuff is accessible.

      But we have a problem. And that problem is resourcing all that. The currently active membership of the Make WordPress Accessibility team is small, and as far as I know, none of us are employed by Automattic or Audrey. We are volunteers who care about accessibility and who care about WordPress. By and large we have other careers – whether it’s running a web development company or an accessibility consultancy business (like me) or working for someone else. Most of us are not hugely technical – some of us are not technical at all.

      The hours that we can give to improving accessibility within WordPress are (speaking from my personal situation) few. As a team we direct in areas that seem right to us – individually and collectively. Joseph (our team leader) helps to give direction here.

      I agree with you that jumping on the new areas and testing them is key, but your desire that we should “run and test those plugins every week to provide the perspective, experience, and patches” is really not going to happen with the current setup.

      We have been actively trying to attract new members into the team with some success. But I’m not sure how easy that will be if people think they might end up receiving what some might perceive as a public bollocking from the founder of WordPress.

      It is wrong that the responsibility for lack of accessibility within WordPress is laid at the door of the Make WordPress Accessible team. If anything it should be laid at the door of all the developers who contribute to building it. But I’m realistic to know that accessibility does not even feature on the radar of many developers – and not just within WordPress. That’s something that I’ve joined the team to try to change.

      The Accessibility team is here to help out, but responsibility must be shared with all those who design and create the functionality that we all know and love.

      I share your aspiration that WordPress should be a force for democratising the web. Let’s make sure it includes as many people as possible.


      • Matt Mullenweg 11:19 am on December 12, 2013 Permalink | Log in to Reply

        Not everyone can be good at everything, or even think of everything all of the time. I thought the team existed to specialize in the area of accessibility, and provide feedback in that specialized area. There are only four headline features in 3.8 — new index.php, new theme browser, 2014, and MP6 — I don’t know how long it would take to test as they were merged, or as feature plugins, but probably less time than the team’s weekly meeting.

        There has been plenty of Trac, P2, and IRC activity in this time period, just not on items slated for 3.8. I understand the point “everyone should be doing this, not just us,” but then why have a team if not to advocate? Knowing is half the battle.

        Could you link the tickets for custom menu builder, media panel, and customizer?

        • Marko Heijnen 11:58 am on December 12, 2013 Permalink | Log in to Reply

          I wouldn’t blame this on the accessibility team but on the teams that wrote the core plugins. They are responsible to have a finished product. And they should ask advise from the accessibility team. I would not see it as a task from this team to know when something is ready for testing. To me there is just a lack in communication with core and the rest of the teams.

          • Amanda Rush 3:42 pm on December 14, 2013 Permalink | Log in to Reply

            Re: communication with the rest of the teams: I haven’t been able to attend the IRC meetings for a while, although I’ve been looking at the logs afterwords. I’m also looking at the make.WordPress.Accessible page, and am wondering if we should have one email address, possible an alius at wordpress.org, so that other teams can contact the Accessibility team, and to have all of us on that alius? Also, should we maybe have at least a page here that lists who the members of the team are, and what their capabilities are so that other teams can also find out who they might need to contact to seek advice while developing new features or updating other parts of core?

            • Sam Sidler 5:17 pm on December 14, 2013 Permalink

              That’s what this P2 can/should be used for. If there are questions or comments that anyone from any team has, they can easily post them here and the accessibility team can respond. I don’t think an email alias is needed. (If email is a person’s preferred format, they can subscribe to this P2 via email.)

        • Graham Armfield 3:35 pm on December 12, 2013 Permalink | Log in to Reply

          Testing of changes ought certainly to be prioritized, but when I do accessibility reviews professionally I use the following AT:

          • NVDA screen reader – with Firefox (and sometimes Chrome)
          • JAWS screen reader – with IE
          • Voiceover on iOS with Safari
          • Dragon Naturally Speaking with IE

          as well as all the other keyboard testing, colour contrast, etc.

          The tickets for the areas you asked about are:

          Custom Menu Builder – #21289 which turned out to be duplicate of #14045

          Theme Customizer – #21283

          Add Media – #23560, #23561, #23562, #25100, #25101, #25102, #25103, #25104, #25105

        • Joe Dolson 4:34 pm on December 12, 2013 Permalink | Log in to Reply

          You mention that there are only four headline features in 3.8; and if that were the extent of our task as the accessibility team, that would be great. However, we’re also extensively looking at the accessibility problems throughout WordPress, not just within the latest features. We’d like to think that the feedback we’ve give on past features, such as concerning keyboard accessibility, could be drawn on for future features — giving the same comments and advice over and over is more than a little bit demoralizing.

          It’s fabulous to be able to get things fixed, but it’s maddening when new features are then introduced with exactly the same problems.

    • Rian Rietveld 11:25 am on December 12, 2013 Permalink | Log in to Reply

      Hi Matt,

      What Graham writes is what I think too. We are volunteers, the accessibility work we do is in our free time. We know how important is is, but we need to earn a living too.

      Speaking for myself:
      You are right: there should be more testing, more patches, more contribution. I see all those possibilities and work to do, but haven’t got the time to dig into it properly.

      If you are really serious about accessibility: please consider to hire someone like Graham for proper testing and advice. WordPress certainly deserves that.

      Kind regards,

      • Matt Mullenweg 11:54 am on December 12, 2013 Permalink | Log in to Reply

        The vast majority of the people who work on and test core are volunteers as well, including the person who reported the issue, and even those who might be employed by Automattic often contributing to core isn’t their full-time job, it’s something they do in their extra time. My leading of 3.8 has been in addition to all the normal non-release-lead work I do and the full responsibilities and commitments of running a 200+ person company. We all have limited time, which is why we should debrief when something goes well or doesn’t and see how we can use our time most effectively the next go-round.

        • Rian Rietveld 1:09 pm on December 12, 2013 Permalink | Log in to Reply

          Maybe it will be a good thing, when a core plugin is developed, the developer knows the functionality also must work without a mouse as a requirement: If not: fix it or provide an alternative. Then 99% of all accessibility problems will be solved. Saves us all a lot of time.

          Preventing problems by the developer is way easier than scanning the lot afterwards and puzzling into the code to find where the problems and the solutions are, and getting the blame of not seeing it earlier.
          We should help each other Matt.

    • _Redd 1:11 pm on December 12, 2013 Permalink | Log in to Reply

      Matt, first of all, thank you for your stated and public commitment to accessibility; the statement that
      “Accessibility is extremely important to the project…” made all the difference in the world to me at least, because until that point, I seriously wondered if there was support for accessibility from the top. The developers have been exceptional, every man and every woman, in making themselves available to us if and when we asked for help or guidance. I can’t speak highly enough of them as individuals—and I can’t speak highly enough of you, for having this conversation here, with us. That one statement you made on that ticket renewed my faith in WordPress, which I have to tell you, was beginning to erode as I saw the priority of accessibility tickets fall as work progressed.

      Okay, here it comes. I think the expectation that volunteers, especially in accessibility, can track, maintain expertise on, and contribute in a manner that dovetails with the pace of development that is going on with WordPress is not reasonable.

      First, the simple knowledge of accessibility issues is so broad, there is absolutely no one on the face of this earth who can know how to deal with all the different “kinds” of accessibility issues there are–physical, mental, emotional, all of which are dealt with through user interaction via different facets of development (coding skills for the physical problems, user interface problems for the mental and emotional problems–different skill sets). I first learned about (and am still learning about) screen reader technology because that seemed prominent with the accessibility group when I first joined, but most of what I need for the students requires knowledge of accessibility technology used by switch users–a different knowledge set is required for this. I won’t even talk about how one must know how to go through a matrix of operating systems, browsers, and so on for each of them. It takes a lifetime, and I do mean a lifetime, to understand in one’s guts what needs to be done.

      Second, the bar has really been raised for people like me who want to contribute. I think that the skills required for making a contribution may be taken for granted, when they should not be. A very, very, very serious time demand is made on anyone who wants to contribute. I’ve learned PHP on my own, but now, before I can contribute patches, I must learn a versioning software on my own time. This is no small feat. I work two jobs, neither of which have any benefits of time off (much less any insurance or retirement or anything like that) and most of my free time goes to either an ailing mother or a mentally challenged sibling. These are fierce time demands, because one must pursue a LOT of various appointments for basic things like keeping the financial books, taking them to the doctors (frequently) going shopping, what not. Most people have no idea how crushing the time demands are on anyone who has family members with disabilities, which is the bottom reason WHY I am in the accessibility group. Most people have to give up their jobs to take care of family members.

      Here’s the point of above: most of the people who understand accessibility problems understand them because they have first hand knowledge of the problem, but those same people are really hammered when it comes to time. Much, much, much more than the average so-called “busy” person. I give up very precious and dear personal time to work with WordPress, but this cannot go on forever. The ONLY free time I will have to learn versioning software will be during my Christmas break…a few days. There is so little time available to me, I can say this: anything I give to WordPress is at the expense of my family life, and social life. But it is that important to me, and I believe in the people who are at WordPress, and that these people want to do the right thing.

      Why am I here? WordPress gives me real hope. IF, and only IF, we can develop platforms that work in hospitals, AND we can create platforms that the disabled can use, then you would not believe how much good that does for the other family members.

      We few volunteers are always chasing emergencies. There is no “system” to the madness of keeping up. All we do is see fires and then run to put them out. It takes TIME to develop an understanding of accessibility issues as it relates to coding, as it relates to WordPress, as it relates to operating systems, everything. This schedule of 3.6 to 3.7 to 3.8 is, in my opinion, beyond the human scale of being able to digest the implications of the technology, and then apply it, much less test it.

      Thank you for listening. Your presence here, in this blog, makes all the difference in the world. Thank you again.

    • petervanderdoes 3:35 pm on December 12, 2013 Permalink | Log in to Reply

      Wow! To blame a group of volunteers pretty harsh.

      I blame this on improper change management and maybe a little bit release management.

      Release management:
      If the release manager, if there even is one, would have a list changes (I guess this would be Trac) and a checklist to make sure every team did their part, this would have been caught a while ago. How to know if a team needs to do anything, well that’s part of Change management.

      Change management:
      When a change is proposed, all teams need to be informed about the change, what the change is etc. Each team decides whether or not it has implications for their team. A change in DB structure would be very unlikely to have an impact on the Accessibility team, while a change in the UI would be very likely to impact the Translation team and Accessibility team and therefor they need to be informed.

      The point is that there needs to be somebody who knows the whole organization and can decide if a change impacts a certain team and inform that team. Teams themselves can not always make that assessment.

    • Ipstenu (Mika Epstein) 5:27 pm on December 12, 2013 Permalink | Log in to Reply

      I don’t think Matt was making an attempt to blame anyone. Rather, perhaps he intended bring awareness to the shared blame that was everyone missing this one.

      That said, I think putting the onus on a11y has backfired, and may not be the right direction for this. The reason these things weren’t a problem previously is, in part, that everyone tested trunk. Now they’re being asked to test trunk plus a ton of plugins, some of which they may not be aware of yet because there’s a lot of information flying around and, as we all know, it’s very easy to miss something.

      My suggestion: BEFORE a feature can be moved from Plugin status to Core, it should have a checklist that includes a11y testing.

      Now this would change the relationship of a11y and core a little, I know, because someone would have to be on-tap as a ‘release lead for a11y’ as it were, or in lieu of that, the a11y rep could fill in for that. The plugin dev would post here (or contact the rep to post) that such and such plugin feels they’re ready for core, and it needs testing for a11y.

      If it passes, it can go into core and then should continue to be tested as normal.

      Would that make sure the problems we have this time never happen again? Probably not. But it should reduce it a little.

      • petervanderdoes 6:29 pm on December 12, 2013 Permalink | Log in to Reply

        Oh I clearly see an attempt to blame the Accessibility team, he posted on their page and starts of with: “tl; dr: I think the team can prioritize its time and efforts better, especially around new development.”

        Which team is he talking about if not the Accessibility team?

        • Ipstenu (Mika Epstein) 7:34 pm on December 12, 2013 Permalink | Log in to Reply

          I don’t think the world ‘blame’ is appropriate. I totally see why it looks that way, but I really don’t think Matt wants to BLAME anyone, I think it was an intent to highlight.

          But I’m working hard to read everything with the best intentions 🙂

        • Matt Mullenweg 12:50 am on December 14, 2013 Permalink | Log in to Reply

          I do think the team can prioritize its time and efforts better, and I’d like to see the team’s volunteers impact be as high as possible for their scarce time. I wouldn’t spend my time sharing my thoughts here if I didn’t think it could make a difference. I would say the same thing if I saw a developer, designer, forum helper, or documentation writer doing the same.

          I’m not blaming anybody, because I’m not concerned about it being anyone’s fault. There’s no purpose or anything to win. What has happened has happened; I’m only interested in what happens next. Critical self-examination is at the core of why WordPress has remained at the forefront in the consumer sphere, I’d like to see that in the accessibility sphere as well.

          • Joe Dolson 3:17 am on December 14, 2013 Permalink | Log in to Reply

            The WP accessibility team is really just starting to get momentum, and find our path towards how we’re actually going to spend our time and make the biggest impact.

            There are 3 specific paths for us to follow: 1) “low hanging fruit”, which is to say easily accomplished tasks – simple, with minimal impact other than having an accessibility benefit. The remove title attributes ticket is intended to be this kind of thing: kill a bunch of title attributes that hinder accessibility, and serve no other purpose. 2) Touch on new stuff. This is something we didn’t do well in this latest release cycle — and that’s a communication problem, really — we need to become more integrated into the release cycle, and that’s both a push and pull responsibility. Mostly, this cycle we responded to requests for a11y feedback, but minimally investigated other new features. 3) Deal with outstanding, long-term issues that are fairly complex: such as getting the add media panel dealt with, etc.

            Because we’re so few, I think that dealing with the fast-paced new release cycle was a little overwhelming for us; but this conversation is, frankly, great for getting more sense of how the whole process works.

            Thanks for your involvement, Matt – this is very important to all of us, and finding our path is frequently a bit corkscrewed.

      • Andy 7:17 pm on December 12, 2013 Permalink | Log in to Reply

        Agreed. Something was missed; what can we do differently in the future to avoid it happening again?

        Riffing off of @Ipstenu‘s suggestion a bit…

        • Make a11y a criteria for plugins to go into Core.
        • Forces core team(s) to better understand a11y requirements.
        • Creates opportunity to educate core contributors on a11y.
        • More awareness = potentially more a11y team members.
        • More a11y team members = plugins get approved more quickly.
        • More a11y team members = ramping up other education efforts.

        There’s a disparity in team size, awareness, and understanding between Core and Accessibility. That’s a reality. Now how do we constructively work around that to improve the situation?

        • Graham Armfield 9:35 am on December 13, 2013 Permalink | Log in to Reply

          I agree with Joe, I think this is a great idea. And thanks also to @Ipstenu for the idea.

        • Tom Auger 4:03 pm on December 13, 2013 Permalink | Log in to Reply

          +1, in particular, the checklist criteria for plugins going into core (sort of a “plugin review” – similarly to the way themes in the repo get a “theme review”).

      • Joe Dolson 7:46 pm on December 12, 2013 Permalink | Log in to Reply

        I think that’s a great suggestion; and I think you’re absolutely right about why it’s so easy to miss features: with so many pieces to balance, it’s hard to tell which ones are actually in the puzzle…

    • _Redd 9:29 pm on December 12, 2013 Permalink | Log in to Reply

      Asking out of total ignorance here; is there any way that automatic testing can help us “narrow down” problems, or reduce the workload involved? See this article:

      Web Accessibility Testing: Do Automatic Testing First

      • Graham Armfield 10:39 am on December 13, 2013 Permalink | Log in to Reply

        I’ve read Karl’s article and he has some sound ideas in there. Yes there can be a role for automated tests but in my view it’s fairly limited – because accessibility is often about context. Automated testing can tell you if there is no alt attribute on an image, but if there is one present, it can’t tell you whether the text is appropriate.

        In my experience, automated testing works best on simpler web pages. I use the WAVE toolbar within Firefox and like Karl suggests, I always go to that early in my accessibility testing. But it’s only ever the bread stick before the main course.

        But within WordPress admin we’re now dealing with a much more sophisticated UI that uses and in some cases relies on a lot of javascript to function. I think you’d struggle to find automated tools that can deal with all that – but I’m happy to be proved wrong there.

        I tried WAVE with the new Themes page and it finds two errors – both relating to the label for the Search installed theme which is orphaned from its input field.

        The main issue that caused the rumpus in the Themes page is to do with keyboard accessibility – in that as originally created it was not possible to tab around the selection of themes and action them with keystrokes.

        So that points up the first accessibility test I would suggest that anyone does on any website or web app – “can I access and action everything using the keyboard only”. You don’t need special tools for that – just use the tab key, the enter key, the up/down arrow keys, and in certain situations, the space bar.

        The WordPress admin screens here, and in other places like Add Media and Theme Customizer have (sort-of) entered the world of Rich Internet Applications – by their non-native use of HTML constructs combined with scripting. This can be a dangerous area for accessibility. But there are solutions out there and that is where the ARIA techniques will need to come in.

        This leads on to the second accessibility test needed for all this new functionality – “even if I can tab to things and action them, what information am I giving to screen readers?” Making a

        element part of the tab order on it’s own is not enough as a

        has no native role, or state, or label, or description.

        If we’re going to develop UI like this then ARIA has to become second nature to all of us. ARIA support is growing across some assistive technology – screen readers, but not in others – voice recognition. There’s no doubt we will leave people behind.

        Sorry, this got longer than I intended.

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

      I agree on many of the points raised by Ipstenu and Andy.

      People’s time and skill levels will always be variables here so it’s important we remember that.

      That being said, I think the most important items we focus on are:

      • Placing accessibility requirements into the release cycle for Core, Feature Plugins, etc. Maybe we could have a tiered approach here like Basic, Medium and Advanced requirements? That way everything gets out the door with at least the basics in mind. Medium and Advanced things could come later in future releases.
      • Continuing to create educational resources for the developers and users of WordPress. That way, we have a place to send people so they can learn more when needed.
      • Try to organize our efforts better as an team. I’m not sure what this looks like, but maybe we have people lead certain aspects since accessibility hits so many areas. I’m thinking a Team Lead (Already have Joe on this! :)), Developer Advocate (Interface with other developers on code issues), Testing Advocate (Helps facilitate testing features and patches), Resources Advocate (Leads the development of accessibility resources in the Codex, Handbooks, etc.). Each of the Advocates could coordinate with other volunteers interested in assisting with certain tasks.

      Those are just ideas I’m throwing out there for consideration.

      We’re making some good progress on the accessibility front, so let’s focus on that rather than on a blame game. To continue that progress we have to keep weaving accessibility into the development process so it is a priority. It’s everyone’s job to care about accessibility and make it happen, but it’s the accessibility team’s responsibility to guide that process.

    • Sam Sidler 12:48 am on December 13, 2013 Permalink | Log in to Reply

      I think this team has done a good job with the resources they have. It’s sad something this major was missed, but I think that “miss” happened due to poor coordination, specifically, when the core team reviewed feature plugins for inclusion. I missed it too and for that I’m sorry.

      A few thoughts:

      @matt: Do you know what this team works on outside of core? There’s a lot involved in making accessibility better throughout WordPress. A huge part of that is obviously WordPress core, but this group works on a lot of other things as well. After all, what’s the point of a accessible WordPress without themes that are also accessible? (As one example.) Your post reads like you aren’t considering those other contributions.

      The “meta-issue” for me isn’t that this was an “easy catch”, it’s that several people weren’t considering accessibility during the feature plugin process. Part of that seems to be a fundamental misunderstanding of what accessibility is, why it’s important, and how to apply accessibility principles to WordPress (the project).

      This small team has tried to have a bigger impact by adding new theme review requirements (including getting a new theme tag added in WordPress 3.8), participating in the plugin and theme development handbooks to ensure they include accessibility best practices, and yes, working on WordPress core.

      Unlike most teams, this is an entirely volunteer team. Consider this: of the lead devs, all but one is employed to work on WordPress (arguably that one is too). Those who worked on UI this cycle were almost entirely employed to work on WordPress. Heck, the leads of the 3.8 feature plugins were all Automatticians and likely had most – if not all – of their time to contribute to core. A majority of the most active contributors to the support, docs, plugins, themes, community, and meta teams are employed to work on WordPress. Sure, some of those contributors have other responsibilities, but many can work part or full time on WordPress. The accessibility and polyglots teams are the only two that are entirely volunteer.

      My point is this: expecting this team to do “everything” related to accessibility isn’t reasonable. Accessibility is something everyone should think about, every step of the way, just as we think about UI every step of the way. That’s what this team has been working on and it’s what they should keep working on.

      There’s a few ways we can help to ensure a situation like this doesn’t happen again. Here are some suggestions:

      • As I’ve mentioned to some on this team individually, feature plugins need a person from the accessibility team to “follow along” and make sure accessibility is being taken into consideration. This does not mean active development.
      • As @ipstenu mentions above, feature plugins should not be included without accessibility testing. This should be on a “requirements” checklist.
      • Developers need a better understanding of how to develop with accessibility in mind. I recommend improving documentation like the core contributor handbook. There are probably other things we can do here.
      • Fundamentally, there are a lot of people in core who don’t understand why accessibility is important. This needs to change, though I don’t have a good suggestion as to how.

      On a more personal note…

      No one in my family is entirely blind, deaf, or unable to use a keyboard. But accessibility is important to me because I’ve seen that even small changes go a long way. For example, my mom uses trifocals to see. Often because of small type or poor contrast, she has to take off her glasses and literally put the computer an inch from her face to see what’s on the screen. My dad has a similar problem. I have friends with really bad carpal tunnel syndrome, necessitating the use of one hand at times. I’ve had my trackpad break in the past, requiring me to use only my keyboard until I could get it fixed. All of these situations are helped by good accessibility features. Despite what some believe, accessibility is not only for the blind, deaf, or disabled. Accessibility is for everyone. Collectively, we need to do a better job of making this point to WordPress contributors.

    • Dion Hulse 1:04 am on December 13, 2013 Permalink | Log in to Reply

      To come to Matts defense here… I don’t believe he was intending on blaming the team for any issues or lack of a11y in WordPress, rather a suggestion on how the team can be better integrated into the community and have a greater impact than it currently is. A way to improve the impact the team has upon WordPress.

      It’s more that the team HAS been active, as the discussions on this P2 prove. The problem is that most of the discussions are related to long-standing issues in WordPress, we should aim to be making new functionality accessible and fixing up old stuff in the time available along the way.

      I personally DID try using the new Themes page with Voice over, I failed to recognise the problems however as I’m not specialised in it. Accessibility IS in the minds of all the Core Developers, and conscious decisions are made all the time that are not visible, but we’re not experts.. and we don’t make the right decisions all the time, even if we think we are.

      Having a team like this one should mean that it keeps up with what’s happening in WordPress, there should at least be someone (..a team rep?) who is tasked with keeping up with the Updates Posts and filling the rest of the team in on whats coming up that should be looked at. Accessibility shouldn’t be something that the Core Team has to come request feedback for, if you notice something, you should be telling us that there’s an issue IMHO.

      To give some personal feedback.. A significant amount of time has been spent on Removing title attributes and meaningful links in the admin – both of which are long-standing, and mostly minor issues in the grand scheme of things.
      To take the meaningful links discussion for example, there’s very little input from the core team on that and has probably had way too many hours spent on something that the team probably shouldn’t be doing (Propose a HTML markup and translation method that works for all accessible users and other languages sure, but there’s really no need to write the code for us or work in magical methods.. Just say what’s needed and how it can be achieved, that’s good enough..)

      • Joe Dolson 3:38 am on December 13, 2013 Permalink | Log in to Reply

        I think a good question is: what do the lead developers want to hear from us? If we can just walk in, comment “x isn’t usable by keyboard”, and let you guys move forward until you have something you want us to take another look at, that’s awesome, and we can do that. Knowing how much information we need to provide is key, I think – when we need to elaborate the full scope of the access issues, that’s overwhelming; if we can just drop a note and know that it will be acted on, that’s awesome.

        I don’t think that Matt was blaming us; I think that Matt was writing quickly, when it was late, and with a bit of frustration. I do, however, think that we need to find a way to integrate this team more fully into the overall process. Like Sam said, we’re trying to watch a lot of stuff, and there aren’t very many of us, each only able to dedicate a few hours a week.

        • Sam Sidler 7:34 am on December 13, 2013 Permalink | Log in to Reply

          That’s the real question. I also don’t think Matt was placing blame here, but I can see how it came across like that to a number of people.

          That being said, it wasn’t clear to the accessibility team that processes should change. The status quo was working up until the 3.8 release cycle. When the overall development process changed, there was no direction that the team should do things differently. Perhaps it was deemed obvious, but clearly it wasn’t to this team.

          The lack of communication was one of the failures here and one of the places we can easily improve in the future. When the process changed, it should’ve been adamantly clear that this team needed to change their focus. (I explained some of this to individuals, but it wasn’t enough and it wasn’t from the lead developers, which would’ve been more effective.)

        • Amanda Rush 3:59 pm on December 14, 2013 Permalink | Log in to Reply

          OK, in order to help with communication with other teams issues, I have added the other IRC meetings, (docs, dev, ETC) to my calendar, and have slotted the necessary time to attend, as well as of course Accessibility. None of this is an attempt to steal extra credit or anything from other team members on my part, just trying to help, because I’d rather take some of Matt’s observations in mind and try to help with what he’s raising.

          • trishasalas 3:36 pm on December 17, 2013 Permalink | Log in to Reply

            I’m not sure where to reply on this lengthy thread but I would like to lend my voice…and my time. I am feeling the need to specialize in what I do for wordpress.org. To be scattered is to be less effective in my mind. Since I have a son who is legally blind this is something that affects me daily. I would like to learn more about the other areas of accessibility as well.

            I think it would be an interesting role to act as a liaison between the feature plugin leads and the a11y team but if that isn’t needed I am willing to pitch in wherever is needed. I posted to Amanda’s reply because it seems that she has spoken of a similar ‘role’ here.

            My biggest issue at the moment is that the BuddyPress dev meeting is the same time as the a11y meeting, so I will be there but my attention will be divided 🙂

      • Sam Sidler 7:53 am on December 13, 2013 Permalink | Log in to Reply

        I don’t think Matt needs defending here. I’m certain he wasn’t trying to place blame, as I’ve said above (below?). The phrasing did come across that way to a number of people on this team and elsewhere. But I don’t believe that was his intention.

        For the record, you may have tried Voiceover on the themes page (not understanding how it worked), but that doesn’t mean “all the Core Developers” are conscious of accessibility. And since you don’t have an understanding of how it worked, why wasn’t there an explicit question to the a11y team about it? Why wasn’t that one of the first things tested before THX went in? (Again, I failed here too.)

        The posts on make/updates are great but how often are they really updated? The last core team update was on November 14. Not that I’m great about my updates either, just pointing out they might not be the best way to know what’s going on in the project.

        Really though, I disagree that accessibility shouldn’t be something the core team requests feedback on. There’s too much happening in the project for any single team to follow, including the core team. Posts on make/updates help, but aren’t frequent enough to a be all and end all. I absolutely believe that “if you notice it, say something” should be a standard thing for the accessibility team, but it’s clear they didn’t notice the themes issue. I don’t think they’ve ever not said something, if they’ve seen it. Perhaps they should’ve noticed this issue, but they’re also (as I said above) much smaller than other teams and entirely volunteer. Because they’re different than every other team, why are we pretending they’re the same? I think we absolutely should request an accessibility review for new features.

    • _Redd 2:16 pm on December 13, 2013 Permalink | Log in to Reply

      We are making progress, real progress here, thanks to everyone involved. Greatly appreciated.

      Do you know what this team works on outside of core?

      For me personally, I have temporary work at a university that ends this month. I am/was part of the site architecture team, and set up a WordPress website under the direction of a design committee. I don’t consider the site to be accessible, but the group is learning more and more by working with me. For example, we have a search box that expands to multiple options through JQuery–but traps any one who doesn’t use a mouse via its lack of an escape key when the search is complete. I pointed that out to the lead code “author” of the site, who was quite surprised, and he will take care of it. I asked for a “Zoom Text” capability to be embedded within the site, but that was turned down, because the words “Zoom Text” disturbed the visual layout of the site. So, I watch a student take a bus or hitch a ride to come to the university to use a Zoom Text reader on our campus in order to do his work. This kills me. He could be doing the work from home if we had that simple little two words on our site. But the point is, I have lost most of my accessibility “battles” in setting up this WordPress site—but I think I’ve actually won “the war” through education. When I leave here, the site WILL be more accessible at to those with screen readers, and some of the switch users, due to the conversations I’ve had with the lead coder.

      My other temporary job is to teach online. Every single semester I encounter students with disability problems–and here’s the sad thing–many are not “officially” disabled, and therefore cannot receive disability assistance. You would be surprised how many people SHOULD be getting disability assistance, but are not. The economy plays an especially cruel hand to those in need. There’s no money to go around for these people.

      This is a critical point, and why I am so involved in making platforms that are accessible. If we can’t get formal assistance for these people, then, maybe the free, accessible platform of WordPress can do this. This would spare students from having to go through the the horrible time-consuming paperwork involved just so they can go to school. One of my best students typed long essays from his wheelchair, one finger-poke at a time…because his stroke took everything else from him. Bizarrely, we had no way to help him with studies other than to give him only 10% more time on timed test.

      Bottom line, my life and my jobs inform my knowledge on accessibility issues. I’m not saying I’m an “expert”, but definitely, I have a sense of what works and what doesn’t for those with disabilities—and this is important–those who support those who have disabilities; i.e. family members, institutions, etc.

      Web platforms are so, so much more than an online version of information—they are critical because they can DELIVER information to those who may not otherwise receive it. This is the game-changer that WordPress can be. For twenty percent—of–the–world. This is huge.

      What do I think that can be done to help out the situation?

      Make a matrix.

      Making a matrix will provide a powerful visualization of the task at hand–and in a sense, that very visualization tool will serve as an educational tool, bringing to light the enormity of the problem.

      And it will allow us to “prioritize” better.

      For example, if one person is an expert on screen readers, and another person is an expert on voice recognition systems, we can “divide and conquer” the task of making a feature accessible.

      And, if the solution is recorded somewhere, we can reuse that solution for the next version of WordPress.

      A matrix will also allow us to wrap our arms around the problem better.

      For example, if a solution for an accessible menu works in Chrome, will it work in Firefox?

      Another example–fine, the solution works in IE10 — does it work in IE11?

      You get the point.

      It is something I feel that the accessibility team SHOULD put together FOR the developers….it would allow everyone to really “see” the problem in an organized manner, and therefore, attack the problems in an organized manner.

      Finally, I do think a simple review of even common standards is in order. If a web platform works as it should by WCAG standards, that alone will greatly assist accessibility.

    • Joseph Karr O'Connor 9:29 pm on December 16, 2013 Permalink | Log in to Reply

      Late to the party but I was preparing for speaking at and traveling to WordCamp Las Vegas with my family.

      This is a great conversation. Much thanks to @jorbin for ticket #26527 “wp-admin/themes.php isn’t keyboard navigation friendly.” What happened with that ticket is the takeaway. People were willing to hold up production for an accessibility issue. This is progress. I once had a spiritual advisor who told me: it’s not the words, it’s the music. This conversation is music to my ears because the actions we take after this conversation will lead us to more accessibility and that is a wonderful thing.

      What will truly lead us to more accessibility is adding accessibility requirements at the beginning of the process. Support for that is essential. We should start out with this one example as our guide and require that everything is keyboard accessible when it’s done. That’s all we have to add to start. That may not seem like much, but believe me when I tell you that taking this one step toward accessibility will change the way we approach development. I’ve institutionalized accessibility at some very large organizations and can say that initially it only takes a small change in the way people approach development to start the process rolling.

      On behalf of the accessibility team I want to thank each and every one of you for this awesome opportunity to make WordPress more accessible. I’ve suggested an action we can take. The accessibility team will develop keyboard accessibility guidelines and make them available in the Codex and other places. With keyboard accessibility guidelines in place and support for adding this one action up front we will continue the process of institutionalizing accessibility.

      • Sam Sidler 9:53 pm on December 16, 2013 Permalink | Log in to Reply

        Accessibility guidelines (of any kind) should be in the Core Contributor Handbook. If they’re super long, perhaps you can break them down with simple descriptions and link to make/accessibility’s contributor handbook or individual pages on this P2 for the details.

        Side note: It’d be good if this team had a handbook at some point that directs people how to get involved with the team. See the Core and Mobile contributor handbooks for more on what they should look and feel like. It’s not urgent right now, but I believe it would help in the future.

  • Joseph Karr O'Connor 7:14 am on December 5, 2013 Permalink
    Tags: , , ,   

    IRC Meeting: December 4, 2013 

    Discussion about Analysis of what gets into the alt and title attributes when adding an image into a page/post by @grahamarmfield. Excellent work.

    Discussion about what is needed to move Create new tag: accessible-ready @sams suggested that we should find an owner and get it in as soon as 3.9 development opens. He also suggested that we look at the patch in #21442 to see what’s needed.

    Though we have had some new recruits to the team in the last week, we are still woefully understaffed compared to the speed, breadth, and depth of WordPress core development. We will continue to contribute where we can and are looking for more team members with deeper coding skills to help move some of the issues along.

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
Skip to toolbar