Work starting on WordPress 3.5 – Now is the time to raise those accessibility tickets.
Published: | 12 Comments
Reading Time: 2 minutes
I’ve read in a WordPress update this morning that the release of WordPress 3.5 has been pencilled in for early December 2012. The work stack for this release is coalescing now so I think it’s important to get as many accessibility related tickets into the WordPress Trac system as possible, and to bump up and comment on the ones that are still open but have been forgotten about for months/years.
After my presentation to WordCamp UK last weekend (July 15th) there already seems to have been some movement on the ones that I have raised and a couple of the old ones that I’ve commented on.
Is accessibility taken seriously?
Now I know some of you may well have had poor experiences in the past trying to get accessibility issues within WordPress taken seriously and corrected, and I myself have experienced some of that around the start of 3.4. But when I demonstrated to nearly 150 WordPress developers a selection of the accessibility issues – especially in the sparkly new areas like Theme Customizer and Custom Menus – it really seemed to generate a bit of steam.
Maybe I’m being ridiculously optimistic and maybe the planets aren’t really in alignment but I want to have a go. But I can’t do it all on my own – I need your help and perspective on the issues.
Raising a ticket
If you’re unsure how to raise a WordPress Trac ticket the please see Raising a WordPress Trac Ticket for Accessibility Issues that I posted the other day.
Please could you have a go? The right time is now whilst things are still fluid for 3.5.
Thanks
Graham Armfield
Some other WordPress posts
- Building Accessible WordPress Themes – Featured Images - Apr 28th, 2019
- How to Build an Accessible WordPress Theme - Apr 28th, 2019
- Accessibility Checklist - Apr 7th, 2019
Share this page (Links open new windows/tabs)
12 Responses to “Work starting on WordPress 3.5 – Now is the time to raise those accessibility tickets.”
Like to leave a comment?
Please note: All comments are moderated before they will appear on this site.
Previous post: WordPress and Web Accessibility: Why It’s Important – WordCamp UK 2012
Next post: WordPress 3.5 Accessibility Update – November 2012
Hello,
I have recently written a LinkedIn article that defines the three fundamental principles of accessibility for interactive web design, and illustrates the differences between
keyboard and screen reader accessibility for developers, viewable at
http://lnkd.in/jYnkZq
This is geared for developers, so hopefully the concepts will be helpful for the engineering team.
Sincerely,
Bryan Garaventa
I think it’s a good idea for this to finely happen. I have created 4 websites over the past year or so and the pop up menus although usable in safari can not be suddenly usable if you click the collapse link. Although plugins have been designed to get around the fly out menus, it would be nice if wp could just not use them, or use pop up boxes or something. I’m not a good thinking on ideas but those are my thoughts nevertheless.
good job on the post and hope this can work.
I don’t know if it’s really going to further the cause of accessibility to essentially flood Trac with tickets. I think it’s fine and well if it really is a bug report, but suggestions and such have their own venues on the WP site. There’s the ideas section, where there is a post devoted to WP accessibility already as well as make.wordpress.org where there is an entire sub-blog devoted to accessibility. If you’re really wanting to help get WP more accessible become more active in the community as a whole. Post on the forums and in the UI blog on make.wordpress.org regarding accessibility or the Themes blog if you’re more concerned with the front-end.
But please don’t advocate to flood a system that is used to help monitor and track actual bugs and security threats simply to get a point across. It’s not going to be helpful and it just looks bad for all of us who actually need those accessibility improvements.
[…] on Twitter I saw a link to this blog post and it really bothers me. I left a comment there about my qualms, but it’s currently in the […]
Hi Cyndy, thanks for your comment.
I appreciate your concerns about the tickets flooding the Trac system. I have decided to do this in response to the debate after my recent presentation to WordCamp UK during which someone who I believe (not 100% sure) was a WordPress core developer stated that the WordPress developers would not necessarily be aware of these issues unless they featured in Trac tickets (I’m paraphrasing). This person actually raised the ticket on the Theme Customizer there and then. Other WordPress core people were definitely in the room too and none of them expressed concerns about this.
So taking that at face value I started to add some tickets and to publish the instructions for doing so to others who (like me) had never done it before.
In emails and other communications on the WPUK (aka WordCamp UK) mailing list I have received supportive comments on my tickets from Andrew Nacin (amongst others) and there has been a flurry of activity around some of the tickets I’ve raised or commented on. The approach of raising a ticket for each small, self-contained issue seems to be what they want – rather than a catch-all “Fix accessibility in WordPress Admin” ticket (and there is one of those). One key aspect though is that I’m told that making suggestions for fixes to the issues will improve the chances of the tickets being taken forward.
The tickets I’m raising are primarily concerned with the admin screens. In my view the accessibility of the front end is more down to which themes and plugins are used – and indeed to what the content authors do in their posts and pages.
I myself have contributed accessibility suggestions to various forum threads on WordPress.org before and I have watched while the issues get debated and then not taken up. In my view the situation with http://make.wordpress.org/accessibility is not helpful. As far as I can see there is no way to actually start a new thread on there and once again suggestions that I and others have made have not been followed up.
Andrew Nacin himself wrote in an email “The time is now…” – hence my encouragement to others.
Regards
Graham
Hi again Graham,
First, let me stress that I am fully in support of getting the admin panel more accessible. As a blind user, it’s frustrating that it’s become MORE difficult to use with each version. And I agree, the front-end is less an issue since it’s more theme and/or plugin dependent.
I think it was the phrasing that threw me, mostly. What you’re saying about Trac is definitely not the reaction I received when posting tickets, but I haven’t really been active with development in many years. (Starring at lines of code and continually breaking my website to hunt and peck for issues or whatever just isn’t as interesting to me now that free time is less available.) But it would seem that’s not the case anymore and I’m fully on board with doing whatever I can to help get the developers to take notice. I’ll poke around some though and see what I can add.
The Make Accessibility blog is less useful than the others; I would definitely poke your head into the UI blog and start commenting, though.
Regarding the actual issues as I see them, I’ll state them again just for the record: The Theme Switcher really needs something like the “accessibility mode” that the Widget screen has. Honestly, if the entire admin panel had that feature I’d probably die from joy. It’d also be great to have a way to expand all the menus so the fly-out didn’t cause a screen reader to be ineffective. But frankly, my number one issue has and continues to be the visual editor. At some point they changed the ability to disable that within the options and moved it to the profile page, making it dependent on each user. It sounds great on paper, but for a site with multiple authors or blogs who can’t use it and already have issues navigating the admin panel it’s an added and frustrating step. (I once hacked the code even and fully disabled it only to have an upgrade break things quite spectacularly.)
Hi Cyndy, thanks again for your comments.
Re your issue with the flyout menus, I’ve seen a post on Linked from a visually impaired person in Canada who had found a plugin to help with that. Typically I can’t track that down at the moment but I’ve sent him a message to ask which plugin it was. Hopefully he’ll come back to me soon and I’ll pass the details over.
Have you tried my Admin Menu Accessibility Plugin? The overt focus highlight might not help you so much but it also puts a skip link at the top of the page so that you can jump straight into the ‘business area’ of each of the admin pages. I’ve had some feedback that this is useful.
Graham
You mean the Expanded Admin Menus plugin? Yes, I’m using that. My point was more that I wish such options weren’t only available through plugins. Something like adding a line in functions.php a la disabling the visual editor would even be more acceptable in my opinion. But it is better than nothing at all.
I’ll check your plugin out!
My contact in Canada suggested this one Ozh’ Admin Drop Down Menu but I’ve not tried it out yet.
Ah, I’ll check it out. The expanded menus does cause a lot of scroll if you have residual vision.
Did you know that your plugin reordered my admin menu a bit?
Also, if you haven’t seen this post before, the most recent comments make me very happy.
I’m in contect with Rian – she’s starting to raise some tickets herself.
There has been some action of the last couple of days on a number of the tickets I’ve raised, and others. Access the latest list.
[…] Graham Armfield replied to my comment and explained his why he is specifically advocating using the Trac system. Essentially, it seems to […]