Codex Accessibility page
I’ve just been mercilessly editing the Codex Accessibility page. The aim is to try and create something that is suitable for non-technical site owners. The page was previously pretty technical and loaded with too many (often broken or outdated) resources.
So far, I’ve covered usage of headings, links, images, color and general readability with some simple suggestions for ways that authors can assess the accessibility of their own pages.
I’d appreciate any comments or suggestions on how the page can be improved further. What about something along the lines of “Don’t Use Your Mouse” to encourage authors to try tabbing around their own sites?
John Brandt 6:26 pm on August 23, 2012 Permalink
You need to mention the use of video and the need to have it captioned. I know this opens up a new can of worms, but it is part of the guidelines. You may also want to point out how the WP core has been developed to include accessibility (e.g., Skip to content feature).
esmi 9:22 pm on August 23, 2012 Permalink
Yes – video is a bit tricky. It’s going to be beyond many people to use standalone captioning software. What about referencing captioning YouTube videos? We could point to http://support.google.com/youtube/bin/answer.py?hl=en-GB&answer=100077 and http://support.google.com/youtube/bin/answer.py?hl=en-GB&answer=166810
Cyndy Otty 2:11 pm on August 26, 2012 Permalink
I find dotSUB is a better video service for captioning than YouTube.
Providing a transcript of a video is always nice, too.
esmi 9:29 am on August 28, 2012 Permalink
I’ve no doubt that there are better video hosting services than YouTube but YouTube is going to remain the most commonly used serves for the foreseeable future. So I think, if we are going to mention video captioning, it has to be in reference to YouTube.
Ipstenu (Mika Epstein) 12:48 pm on August 28, 2012 Permalink
Arguably if we put up video on VideoPress (i.e. official WP video stuff) we would address captioning with them.
esmi 1:22 pm on August 28, 2012 Permalink
Absolutely! Lead by example and all that.
Cyndy Otty 5:29 pm on August 30, 2012 Permalink
For the record, I wasn’t arguing which video service is better or worse; I was merely stating in terms of transcription, which is a service that is user friendly.
Though, I agree with Mike below about VideoPress so really my point is moot.
Joe Dolson 9:19 pm on August 25, 2012 Permalink
I’m not sure about this paragraph:
It’s not inaccurate, but I don’t think it conveys the importance that a theme plays in making a WordPress site accessible – the vast majority of problems I see with WordPress sites come from theme problems. I’d like to see this paragraph communicate the fact that whatever gains WordPress can make in terms of accessibility must be supported by high quality themes.
esmi 9:32 am on August 28, 2012 Permalink
Fair point but how would a non-technical user assess a theme for accessibility? Official policy is to point users towards http://wordpress.org/extend/themes/ but there’s nothing in the Theme Review process that looks at accessibility. So it would be misleading to imply that these themes are somehow more accessible.
esmi 11:28 am on August 28, 2012 Permalink
Nevertheless, I’ve added an additional phrase to that paragraph pointing back to the Theme Repository. Does that help at all?
Joe Dolson 3:11 pm on August 28, 2012 Permalink
It helps. At least the statement that a high quality theme is part of the solution is valuable. It may be a worthwhile movement to try and do something to catalog the general level of accessibility of themes. That’s a bit separate, but if there was any way we could point to themes with some degree of accessibility – even if nothing more than a basic star rating on accessibility was assessed – it would be very valuable.
Clearly the best place for this would be in the theme review process for the repository — but setting up an external process would potentially be worthwhile. I’d be willing to participate in that.
esmi 4:59 pm on August 28, 2012 Permalink
I did suggest this a while back but, at the time, the amount of work it would entail was simply too much. Now that we have a theme review team, perhaps this could be raised again with them – subject to enough people volunteering to carry out accessibility audits?
Tim Noonan 9:17 am on August 27, 2012 Permalink
All the above discussion talks to the front end of WordPress, so this should be explicit in any info about accessibility.
Overall the back end of WordPress is very difficult to efficiently use with screenreading software, and this is an increasing problem with each new release.
Popups and collapsed menues, inability to independently setup pulldown menues and difficulties editing and formatting posts are a few cases in point.
As a blind self-hosted wordpress site owner, I am disappointed at how access to site management has worsened increasingly since version 2.8 onwards. I chose WP because it was quite accessible in earlier versions, but now I find myself needing to pay people to assist in more of my site admin than ever before.
Tim Noonan
implies
esmi 9:34 am on August 28, 2012 Permalink
I think the discussion and documentation of the WordPress back end should be elsewhere – not in this particular Codex document. It’s focus is primarily on what site authors can do to maintain front end accessibility. As for the back end of WordPress, that is exactly what is being discussed elsewhere on this site