Mike Cherim and Jonathan Fenocchi, creators of the GrayBit service for showing a site design converted into grayscale, needed to move on. The time and expense of maintaining GrayBit was too much – and since Mike Cherim has moved out of the web development and accessibility world, it was necessary to make some changes. They recently shut down GrayBit.com, not having received any word that anybody wanted to take the site over.

I was too late to save the domain, which is now a travel magazine, but I have saved the service: GrayBit can now be found at http://gray-bit.com. I just did the move this morning, in about an hour, so there may be issues still to be seen – let me know if you encounter any problems!

For now, I’ve moved the service from being advertising supported to being donation supported; so, if you’re a supporter of GrayBit — please consider making a donation! I don’t know yet just what this service might end up costing me…

Admin Notice: The showkey, shownav, showjump, and toggle shortcode attributes have been deprecated. Use above and below instead.

If you’ve recently upgraded My Calendar to version 2.2.0, you may be seeing this notice at the top of your public calendar. This is because I’ve introduced a change in version 2.2.0, and although those four shortcode attributes will continue to work for now, I do intend to remove them completely down the road — so I need people to stop using them sooner rather than later.

The notice is only displayed for logged-in administrators – but it is possible that if you’re using a caching plug-in that the caching plug-in could pick this up; so it’s not impossible for it to be shown to the public.

To make it as easy as possible to switch, I’m going to explain right here (for those who do a search on this error message), what they need to do.

If you’re seeing the message, it means that the shortcode that’s producing your calendar uses one or more of these shortcode attributes:

• showkey (controls the category key)
• shownav (controls the previous/next navigation)
• showjump (controls the quick navigation jumpbox)
• toggle (controls the list/grid format toggle)

Rather than require a separate attribute to control each of these features, I’ve introduced two simple new attributes: above and below. With these shortcodes, you simply define which fields you want to see, in which position. This gives much greater control — you can now have your previous/next navigation both above and below if you want. You can place the format toggle before the navigation, or after.

Both new attributes support seven values, used as a comma-separated string. The replacement attributes for the original four are:

• nav (turns on prev/next navigation)
• toggle (turns on format toggle)
• jump (turns on quick navigation)
• key (turns on category key)

There are also three new attributes, configuring additional features:

• timeframe (toggles to switch between month, week, and day)
• print (turn on the print view link)
• feeds (turn on the RSS and iCal feed links

Some of these features — in particular the print view and the feed links — will only show up if they have also been enabled in settings.

Hope that’s helpful!

After over 3 months since my last release in the 2.1 series for My Calendar, I’m finally ready to release the next version of My Calendar. There are a lot of changes in this new version — and I think they represent some distinct improvements.

The complete list of changes can be seen in the Change log. That document goes through every change of substance I made. However, some of the more key items include:

• Basic event search: It’s not complicated, but it sets the stage for future updates.
• Simple integration with WP to Twitter
• Time frame toggle: switch your view between month, week, and day view.
• Variable recurrence schemes: No more “weekly or biweekly” — events happening every 3 weeks or every 6 months are equally supported.
• Set the order of regions above or below the calendar: No longer just turning nav on or off; now, you can set whether nav is above or below the calendar, whether it’s before or after the jumpbox, etc.
• aria-live support for AJAX navigation
• Many other changes and bug fixes!

It’s been a long haul with a lot of testing, but I’m sure it’s not 100% bug free. Find something? Let me know!

I may have a low threshold for managing information, but I find that with seven plug-ins in the WordPress repository it’s a struggle to keep my local information on those plug-ins always up to date. I have a page here about each plug-in, and it’s not uncommon that I’ll publish an update and go to check my local information just to find that my own page on that plug-in is six months out of date…

One way to keep that information nicely in sync is to actually import it directly from the WordPress plug-in repository’s information API. The API documentation is available, if you want to roll your own, but here’s a very basic bit of code to grab it yourself.

Creating a shortcode in WordPress is crazy-easy:

add_shortcode( 'plugin', 'get_plugin' );
function get_plugin( $atts ) {
    extract(shortcode_atts(array(
        'slug'=>''
      ), $atts));
    if ( $slug ) return show_plugin_info( $slug );
}

Woo hoo! You have a shortcode. This shortcode takes one attribute, “slug”, which will be the plug-in slug as seen in the repository. Now, technically speaking, what you have right now is a fatal error, because we haven’t actually defined the ‘show_plugin_info’ function. Fair enough — let’s do that.

function show_plugin_info( $slug ) {
    $body = (object) array( 'slug' => $slug );
    $post_data = array('action' => 'plugin_information', 'request' => serialize($body));
    $return = wp_remote_post( 'http://api.wordpress.org/plugins/info/1.0/', array( 'body' => $post_data ) );
    $plugin = unserialize($return['body']);	
    $return = "
            <p>Current Version: $plugin->version<br />
            Requires: $plugin->requires<br />
            Tested to: $plugin->tested<br />
            Downloads: ".number_format($plugin->downloaded)."<br />
            Last updated: $plugin->last_updated</p>";
    return $return . wpautop($plugin->sections['description']);
}

This is a pretty simple bit of scripting -- and, practically speaking, it's customized to show what I actually do on my own site. You may not want to even use this much code!

I'm using the WordPress wrapper for http requests to get the data -- this is much more reliable than using something like cURL or fopen, because the wrapper will query whatever transport is actually available, rather than depending on the specific wrapper you've defined.

The API is looking for very simple information -- just the slug for the plug-in, and the knowledge that we're accessing the plugin_information API.

With that, we retrieve an object containing all the basic information for the plug-in, largely drawn from the plug-in's readme.txt file. I've only chosen to incorporate a few fields into my site - but you can also grab several other fields this way. These fields are detailed at Dion's API information site, so I won't repeat them here.

This is a very basic shortcode -- simply place [plugin slug='wp-accessibility'] in your post or page and you'll get all the information about the plug-in you referenced.

Not sure how many other people are likely to find this useful...but for my purposes, it's pretty handy.

It’s official – I’ll be speaking at WordCamp Minneapolis 2013 on April 27th, talking about WordPress and Accessibility. Speaking locally is pretty rare for me, so I’m really looking forward to meeting some other local WordPress people at the event. Oh, and the learning. That, too.

The official description of my talk, in the ‘Continuing Education’ track, is:

Covers a wide range of accessibility topics including but not limited to implementing best practice accessibility in theme building, discussing current progress and goals from the WordPress Accessibility P2 group, and address general principles of accessibility that might be of interest to WP developers and designers.

The organizers of the WordCamp are still setting up their speaker matrix, so I don’t yet know yet what my target audience will be — so this is a good time to think about who wants to learn!

Integrating Accessibility with WordPress is a broad topic — and the description reflects it. Are you attending WordCamp Minneapolis (just say yes) and have something you really want to know? Let me know in the comments or via Twitter! I’m listening!

WordCamp Minneapolis 2013
April 27th
Minneapolis Community & Technical College
1501 Hennepin Ave,
Minneapolis, MN 55403

After a trip to a great accessibility conference like CSUN, I inevitably end up with massive lists of great ideas for things I could work on to promote and improve accessibility.

It is equally inevitable that I will forget some of these and fail to complete others — but documentation helps.

Coming out of the conference, here are a few of the great ideas I’ve talked about with other people here or just had pop into my brain without warning.

• Incorporate the QUAIL project for dynamically detecting accessibility issues into my WP accessibility plug-in.
• Develop a WordPress plug-in for using the new WAVE5 API to generate statistics and analysis of WordPress site accessibility.
• Establish a blueprint-like language for designing wireframes and web design proofs that include accessibility information that is not visibly part of the design. Came out of a conversation with Mike Guill on the problem with developers who only build what’s shown on the wireframe/proof.
• Finish my already 75% written accessible video management plug-in for WordPress
• Finally learn more about working with others* through Github or Bitbucket so that I can take advantage of others expertise to improve my accessibility projects.

There’s a good probability that there are other things I’ve thought about this week that aren’t in here. Most likely, I’ve already forgotten them, and will think of them again next year…

“Works well with others” was not a comment my elementary school teachers ever wrote on my report cards.

Whenever I update an application on my iOS or Android devices, I feel a certain nervousness about whether the learning I’ve put into the current app will go out the window. The same is true about any software: is my user interface learning going to become obsolete with this update?

When it comes to major software, like moving to Windows 8, you must expect major updates. But it can be maddening to update an app you’re working with on daily basis — and find that the new version is radically different from the previous.

This issue is made worse when you take accessibility into account: not just whether your interface learning will continue to be applicable, but whether it will still be possible to use the application at all.

I just came out of a session at the CSUN conference (California State University Northridge International Technology and Persons with Disabilities conference) in which Mika Pyyhkala and Mark Reumann demonstrated the accessibility of a number of iOS applications. During the course of the demonstration, one recurring comment was that various iterations of apps had varying levels of accessibility.

These apps did not develop accessibility in a linear manner – version 1.2 might be great, version 1.3…not so hot. One would hope, in an ideal world, that any application would be initially launched with fabulous accessibility. Lacking that, I would certainly hope that the accessibility of an app would be constantly improving. Unfortunately, the reality is different from the ideal. (I know, this is shocking news.)

Why do we get this experience of “yo-yo” accessibility? Why is one version accessible, but followed by a version with less accessibility? Madness!

I’m not going out on a limb here, I suspect — but I want to connect this issue to work flow. Following up from a conversation with Karl Groves, and the content of his presentation on automated accessibility tools, there’s an incredible importance to integrating accessibility into the standard workflow. When accessibility is a separate process, it’s easily skipped, ignored, or reduced in importance. When it’s a standard part of the project workflow, part of an integrated process, then skipping or reducing the importance of accessibility becomes a burden.

These apps undoubtedly broke their accessibility because it was not in their process: they did a new design or added a feature, and it wasn’t accessible because the people who worked on it didn’t happen to know accessibility — and nobody was checking this.

When the argument is that accessibility is a burden, then everybody loses. If the argument is that leaving out accessibility is a burden, then everybody wins.

Now, accessibility is currently an expert-driven process. As such, it has limited integration capability. Your developers should not need to be experts on accessibility in order to avoid making these mistakes.

Here are just a few ideas of work flow changes you can look at to keep accessibility inside the work flow, instead of depending on outside expertise:

• Create reusable code blocks – Standardized blocks of code that represent how your organization structures form fields, buttons, labels, headings, etc. Nobody should ever have to write a form field: at worst, they should have to copy and paste some code that has already been established as accessible.
• Use tools that check work throughout the process – Checking accessibility only with a finished product is a broken process; use tools throughout.
• Provide documentation of techniques geared towards your team – Different users need different information. Content creators need to know how to structure content, but shouldn’t need any information about the framing structures. Interface developers need a lot more information. The language of that information needs to be geared towards those users in specific.

What you can do is going to vary enormously dependent on your organization: the presentation by Karl was based on large organizations looking at massive auditing tools with six figure budgets; the topic of our conversation, on the other hand, was about plans for integrating a check of the accessibility of authored content into a plug-in for WordPress. (Can’t give a lot of details yet; but it’s in the works.)

The point is that if you can be notified of issues while you’re working on your project, it’s much quicker and cheaper to get the fix implemented than if you’re notified of the same issues two months after release.