WordPress Accessibility

Kudos to WordPress for doing well in Joe Clark’s assessment of WordPress against the Authoring Tool Accessibillity Guidelines. The main complaint seems to be against the WordPress toolbar in the Write/Edit page in the admin, which I would argue needs further development. After all, there are cases where you want i elements instead of ems: for example, any proper title that you choose to italicize really isn’t something that you’re emphasizing; you’re just using italic type to alert the reader to the presence of a proper title.

The easiest way to summarize Clark’s finding is this: WordPress’s core commitment to producing standards-compliant markup makes it generally very accessible. The WP development crew should read Clark’s assessment, feel a sense of pride, and heed the minor suggestions and constructive criticisms provided.

Give TrackBack Some AJAX Love in WP 2.1 … Please?

As I’ve been using WP 2.0, the thing I find myself most wishing for is some AJAX love for TrackBack. Yes, many argue that TB is broken, and while I understand why, some of us are still true believers. Anyway, what is with this space-separated nonsense at this point? Seems like this would be a key place to dump an URI, hit a button, and have another form block open for the next one. It would be even cooler if there were a way for WP to check for the validity of the TrackBack URI upon a Save and Continue Editing run.

If you’re looking for prior art on this, I’m specifically thinking of the “Add URL” functionality in Alex King’s Tasks software.

Owen on Testing

In a larger post about keeping the scripts that produce WordPress’s syndication feeds up-to-date, Owen Winkler says the following:

Changes in significant areas of the software such as [comment- and category-focused APIs] would require exponentially significant testing. And as might have been noticed during our pains from the 2.0 release, WordPress could stand to have a bit more thorough testing generally. It doesn’t need the strain of testing on formats that we don’t even have an developer advocate strong enough to volunteer for coding and testing. Not only would someone have to adopt each of the four feed files, but we would need testers to focus on the changes in those areas. I don’t see enough people who care - Maybe you’re out there?

Owen, I don’t know enough about the ins and outs of these feeds to be of much use, but there are people who do. [Phil Ringnalda seems to care, and you could probably talk Sam Ruby into helping with test cases---and if nothing else, Sam's focus on it would get some interesting comments from Mark Pilgrim on the subject, and that would make enough of a kerfluffle to get some attention. ;)] But I am certainly arguing that we need to take time and figure out what testing needs to be done—fishbone diagrams, whatever.

It’s a Start

Matt’s put out a request for folks to sign up to help develop and test WordPress in particular areas. I need to look at where I can contribute, seeing as I’ve been arguing for this kind of thing.

I’m not sure that a wiki-based approach is the best way to go—I’m thinking something nice and hierarchical like Tasks is a better approach—but this could be because I don’t use wikis much but seem to live in my Tasks installations.

WordPress Needs Formal Pre-Release Testing

The debacle that has been the WP 2.0 release cycle to date—look at the comments on Owen’s “Why aren’t you upgrading?” entry if you haven’t seen the furor—has just driven home to me the need for a structured testing program for WordPress releases.

I especially want to point to Craig Hartel’s comment, which is what inspired me to write this entry today:

I see this same discussion after every major release, and always the answers are basically the same.

What can we do to address this repitition? I suppose one major thing would be to establish a formal testing program. I would certainly participate in that, if I knew how. I feel like I’m a WP user that kind of falls through the cracks within the WP community. I know enough to get myself into, and usually, out of trouble, but I can’t code my own plugin or do much more than change some settings within an existing one.

I’ve been with WordPress since the pre-1.0 days, and I think its development has been amazing. Sure, there are plenty of things to be critical about, but what good project doesn’t have things to work on?

Somebody, please offer your skills to mentor users like me who want to gain more knowledge and understanding to help contribute to a fantastic open-source community.

FWIW, I’ve never really hesitated to upgrade, and I’ve never really had any major issues either (knock on wood). My biggest concern with WP has always been security, and I feel that by and large, security issues have been dealt with in a reasonable fashion.

Upgrading for its own sake is not a good reason, IMO, but I did just that for WP 2.0, and I’ve not regretted it.

I’m right there with Craig—I’d help if I knew how. Help me help you!

Here’s what WordPress needs in terms of a testing system:

1. A release candidate period.

   If we had an RC period of, say, a week for users to download, install, and run test cases on a build of WordPress, then note all the bugs, things would be a lot better.

   What this takes, though, is a willingness to call for an RC, open it up to testing, and a specific bug-reporting environment for that RC alone. Nightlies and all can happen while the RCs are out, but you have to encourage your RC testers to stay away from the nightlies while they’re doing RC testing—everyone needs to be on the same page.

2. A set of test cases to run against.

   What’s broken WP in the past? I18N? HTML characters? Write up a fault tree. List every core feature to be tested, and give people targets to shoot at. If you have a ton of users running a bunch of test cases on all your features, you’ll likely find all the bugs you’ve got in there, including those that are server configuration-dependent.

   Since I mentioned config-dependencies, I think a lot of WP users and testers are on a LAMP structure, but I know folks run WP on various versions of PHP, MySQL, and sometimes on HTTP servers other than Apache. So, let’s encourage the people that have bugs in the past to help with testing! They’ve got an interest in helping you.

3. Patience and understanding on everyone’s part, and no date-driven releases. Goals and targets are great things, but sometimes you need more time.

What else is needed in coming up with a good test suite for testers? Testing needs good structure for us to have a clean .0 release.