The new version of WP Accessibility has just been released. Updates include the inclusion of Chris Rodriguez’s a11y toolbar, as previously announced and support for a custom WordPress administrative stylesheet.

The first item, the accessibility toolbar, falls into a category of accessibility I rarely pursue: the front-end accessibility widget. I’ve written (negatively) about the concept before, in my article When More is Less. Having previously opposed accessibility widgets, I wanted to talk a little about why I think including this one is a good idea.

The Problem of Accessibility Widgets

The problem with accessibility widgets is that they are not an optimal solution. If the problem is that the text on your site is too small, then the optimal solution is to make the text larger. Providing a widget so that your users can make the text larger is clearly not the best possible solution.

But my WP Accessibility plug-in is in no way an “optimal” solution. While some of the elements of the plug-in involve creating an easier way of incorporating standard accessibility methods into a WordPress site, others are really about inserting improved accessibility into a site which is otherwise sadly lacking.

Don’t get me wrong: because WP Accessibility fixes some issues in the WordPress core code, it’s valuable in any WordPress site. However, a lot of the additional use cases for the plug-in are about patching accessibility into a site because the skill, time, or budget required to do it natively in the theme is lacking.

This is where the accessibility toolbar comes in. It may not be the best option for a site — but it may be the only realistic option.

If I may hypothesize a scenario:

You’ve just been hired by a company to manage their web site, after a previous developer left. They recently spent many thousands of dollars developing a new web site — but they didn’t really consider accessibility in the process. A complete revamp of the site isn’t something they have the budget or desire to engage on, but convincing them to install a plug-in that will have very little visual impact but improve accessibility is an easy target.

This accessibility toolbar is well designed – Chris did a great job. It’s subtle, simple, straightforward. I’m glad to be able to incorporate it.

WordPress Admin styles

Including a custom admin stylesheet allows me to fix a few minor issues in the accessibility of the WordPress back-end. Among these are some contrast changes; moving the post actions (Edit, Trash, etc.) into a context that’s visible to screen reader and keyboard users, underlining navigation links on hover, etc. What I’ve implemented is very basic, however — if anybody wants to extend them, they can do this by adding their own custom wp-admin stylesheet into their theme directory.

For my next (still forthcoming) version of my WordPress calendar plugin, My Calendar, I had a need to add custom screen options to a couple of editing screens. Now, there’s a great tutorial on adding screen options by Chris Marslender that I found very useful.

It is, however, incomplete.

Now, if what you want to do is add one basic control, that tutorial is definitely going to get you where you need to go. It’s simple, straightforward, and accurate. However, it has one tiny error and one large omission.

The tiny error is simple: for saving the option, the tutorial specifies this code:

add_filter('set-screen-option', 'cmi_set_option', 10, 3);
 
function cmi_set_option($status, $option, $value) {
    if ( 'cmi_movies_per_page' == $option ) return $value;
}

This will work, for a single field. But, if you add two, you’ll notice that this filter *prevents* any other screen option value from being sent if it is not equal to ‘cmi_movies_per_page’. It doesn’t stop any of the default screen options, which are all whitelisted in the WordPress function handling updating options. When you add another custom function, however…no go.

Easy fix:

add_filter('set-screen-option', 'cmi_set_option', 10, 3);
 
function cmi_set_option($status, $option, $value) {
    return $value;
}

Because the value being returned by the function named is very simple; just an integer; there’s no need to filter it in any way; just make sure it gets passed to the function and then saved in the user’s meta data.

Adding custom controls to Screen Options

That was the error. The omission (which is entirely fair, because it was already a long tutorial — no need to cover everything!) is about adding custom controls and saving their data. Because, in fact, you can add any control to the screen options — you’re not constrained to the standard control types that WordPress uses.

For consistency, I’m basing my settings on the same type of data used in Chris’s tutorial; I think this will make it easier to compare the two tutorials and make use of them together.

First, getting some fields into your screen options. This can be ignored when using the default screen options, because they’ll provide your HTML controls for you. But you can attach your own custom controls through the filter screen_settings.

add_filter('screen_settings', 'cmi_show_screen_options', 10, 2 );

The function itself needs to do a handful of things:

1. Define what it will return, whether it’s the desired screen or not.
2. Determine whether it’s on the right screen for the controls.
3. Return the form fields (the form itself is automatic)

The form fields must include an array of inputs named wp_screen_options[option] and wp_screen_options[value], or the submission will be ignored. As you’ll see further along, the option parameter is the important one; you need value to be present, but you don’t necessarily need to use it. That’s a choice, however, depending on what you’re doing with the data.

The current screen is passed to the screen settings function in an object variable of arguments, here called ‘$args’. You can test against your current screen using the $args->base member.

function cmi_show_screen_options( $status, $args ) {
    $return = '';
        if ( $args->base == 'toplevel_page_my-calendar' ) {    
            $button = get_submit_button( __( 'Apply' ), 'button', 'screen-options-apply', false );
            $return = "
            <fieldset>
            <legend>Show Columns</legend>
            <div class='metabox-prefs'>
            <div><input type='hidden' name='wp_screen_options[option]' value='cmi_show_columns' /></div>
            <div><input type='hidden' name='wp_screen_options[value]' value='yes' /></div>
            <div class='cmi_custom_fields'>
                <label for='cmi_producer'><input type='checkbox' value='on' name='cmi_columns[]' id='cmi_producer' /> Producer</label>
                <label for='cmi_director'><input type='checkbox' value='on' name='cmi_columns[]' id='cmi_director' /> Director</label>
            </div>
            </div>
            </fieldset>
            <br class='clear'>
            $button";
        }
        return $return;
}

In this example, I’m passing data using an arbitrarily named field called cmi_columns. I’m hypothesizing this as a group of controls to limit which fields you’re showing on a plug-in page.

Saving your Custom Screen Options

You’ll be using the same filter as in the other tutorial to save your data:

add_filter('set-screen-option', 'cmi_set_screen_options', 11, 3);

In the function itself, you can manipulate the POST data sent from your custom screen options however you wish. You can dance with it, change it, ignore it; whatever is relevant for you. If you need to interpret the data sent and use it in a way other than that directly posted, here’s where you can do it. Not in this example, however — which simply takes the posted data, and returns it to be saved in the user data.

function cmi_set_screen_options($status, $option, $value) {
	if ( 'cmi_show_columns' == $option ) { 
		$value = $_POST['cmi_columns'];
	}
	return $value;
}

That’s it. Value saved and passed.

What’s important in this tutorial?

If you’re trying to use the information from Chris’s tutorial to create multiple screen options, you’re going to get a little frustrated when the second one just won’t save. That’s because of the failure to return a value in the filter unless the specific field is passed. If you need to pass a type of data other than defaults, that tutorial doesn’t cover it. So here you are. Enjoy!

WP to Twitter is a time-saving tool for sharing your WordPress-composed content with your Twitter followers. But creating a smart Tweet is different from authoring great content: when you’ve only got 140 characters, you’ll want to think strategically.

There’s always a compromise between saving time and authoring something unique. The maximum in time savings comes from using the template tools in WP to Twitter to generate the text of every Tweet. An effective formula using your post title, your URL, and some tags is simple enough.

But what if you want to do something different? Now you’re into customization.

Writing a smart Tweet is about effective use of language: appealing to your followers with the fewest words you can.

Short Tweets are effective — they allow for easy sharing and re-tweeting; long tweets mean that either your Tweet must be shared using the Twitter “ReTweet” feature or the user needs to edit your copy in order to share your Tweet.

Hashtags are useful, so it’s worthwhile to include at least one. A hashtag creates an avenue for people to view your Tweet because they’re monitoring that hashtag. It’s absolutely valuable to reach the audience that is topically interested in your content but may not already be following you!

Your URL is obviously a crucial element, to send readers back to your site.

But what else?

People like to add their own commentary to Tweets when they share them – it may be nothing more than “This is cool: “, but when there’s room for those 14 characters, the likelihood that your Tweet will gain traction is noticeably higher.

There’s an interesting article at Social Media Today about re-Tweeting: Crafting the most Re-Tweetable Tweet You Can, by Charles McGuinness. In that article, the author demonstrates that there is an inverse relationship between re-Tweets and the length of Tweets: the longer the Tweet, the less it is re-Tweeted.

Over about 36 characters, the re-Tweet frequency levels out, with a spike of higher re-Tweeting at 120 characters.

Now, given that if you’re using WP to Twitter one of your goals is to share your web site content, keeping your Tweets under 36 characters is probably not at all realistic. Once you’ve got 20 characters for a URL, you only have 16 characters left for a title. That’s the word “self-sacrificing”, and I don’t think that’s what you need to be in this case…. So, not a lot of space.

But that spike at 120 characters is interesting. It’s a sharp and decisive spike – right back up to the popularity of a 24-28 character Tweet.

So what’s the value of maximizing that 140 characters? Do you gain anything by fitting in a couple extra words? In a word, I think…no. You just don’t. Your Tweet has a little more information in it (assuming that keeping information density high and leaving out anything extraneous), but it’s a little less likely to be shared — and it’ll reach fewer people.

So, what’s an ideal Tweet?

• 120 characters or less
• Links back to your content
• Includes one hashtag, maybe two if they’re really relevant.

I could set the character limit at 120 characters in WP to Twitter – but, honestly, that’s just getting pedantic. You’ve got 140 characters, and you’re free to use them. But I recommend against it.

SO, I can hear you asking, why are there so many options for customization in WP to Twitter? Well, that’s all about special cases: you may want to include a reference to another author. You may need to reference an alternate URL. You may need to add extra tags. It’s great to have lots of options: but smart usage is knowing that you don’t always want to use them.

References:

• The 6 most irritating ways to use hashtags on Twitter
• Twitter Etiquette
• The Perfect Tweet
• Twitter Manners: How to Write Good Tweets
• How to write better Tweets

Recently, the state of Minnesota rejected a constitutional amendment referendum that attempted to make same-sex marriage unconstitutional in the state of Minnesota. Much of the reason that this amendment was defeated has to do with societal change — but there was also a change in how the issue was discussed that is believed to have had a beneficial impact on the vote.

That change was a move from focusing on civil rights as a method to convince people to vote against the amendment to focusing on stories of the loving relationship of same-sex couples. The personal story: hardships faced due to an inability to marry and the very real emotional bond within a couple helped provide a personal connection to the issue that civil rights did not.

Like same-sex marriage, web accessibility advocates have long used business case arguments and civil rights as the major arguments for web accessibility — but is this really the way to convince people?

There’s no question that arguments for civil rights and the business advantages of an accessible web site are relevant: but if you want to convince people, an empathetic response is even more valuable. I’ve recently been involved in more than one conversation trying to convince people of the value of web accessibility where the argument hinged on “show me personal stories of the impact of web accessibility, and I’ll be convinced” — but I didn’t have any.

I don’t have a stock of personal stories about web accessibility – how inaccessible web sites have stifled the success of users with disabilities or how an accessible web site has made somebody’s day — but I would like to collect these.

To that end, I’ve created a page on my site dedicated to collecting your web accessibility stories: any story, however small, will be greatly appreciated.

I don’t have a plan right now for sharing these stores, but I do intend to make them publicly available — you can provide a name and email with your submission if you wish, but it’s by no means required. Names will be shared with their stories; email will always be kept private.

Go now – Share your Story

I don’t worry too much when I’m planning on adding a new feature to WP to Twitter – most people won’t notice, many won’t care, those who find it useful will be happy about it. But right now I’m thinking about removing a feature, and that is a much more sensitive issue.

Specifically, I want to remove support for URL shortening.

The main argument for keeping URL shortener support is to provide short URL statistics: using a tool like Bit.ly, you can track the clickthroughs on the specific short URL sent to Twitter. However, this can now be done using Google Analytics, which also gives those with an analytical interest the ability to look at their statistics in just one environment.

Shortening URLs to send to Twitter used to be very important — but with the introduction of Twitter’s t.co URL shortening, which is mandatory on all URLs, it’s become really fairly irrelevant. (Yes, it’s mandatory — you may see a different URL, but when you click on the link, you actually go to the t.co shortlink first.)

So I’m looking for users of WP to Twitter to let me know how they feel about URL shorteners. I know how at at least one person feels, and I’m inclined to agree – although Bit.ly works for most people, it fails for almost as many.

One consideration is that I would release an add-on plug-in that would provide URL shortening options in WP to Twitter – if you really want it, you can have it. But I very much want to remove it from the main plug-in.

Your comments are very much appreciated.

The new version of my PRO extension for WP to Twitter is now available. The update fixes a variety of minor bugs, creates some clarifying error messages – but most importantly adds some great new features.

In version 1.3.0, you can now:

Schedule a Custom Tweet

Schedule a Tweet for any time and associate it with any post you’ve published. Simple and straightforward: you can either send it as straight text — what you wrote, and nothing but what you wrote — or you can send it through the WP to Twitter template processor and fetch information from the post on the fly.

Lock Co-Tweeting to one account.

Want to send your posts to two accounts, but not to just any old account? Don’t want to expect your authors to set up their own accounts? No problem. You can set your Co-tweeting to always post to a specific second account.

Custom Filtering

WP to Twitter has a couple of filtering options — filter by category, don’t post edits, etc. However, the gamut of how you might want to filter your Tweets can be pretty complicated. WP Tweets PRO 1.3.0 adds an option to create a custom filter for Tweets – you can specify a wide variety of rules that will prevent a Tweet from being sent. Block a specific post from ever being Tweeted; block a specific author; block a specific word in the title — it’s up to you.

WP Tweets PRO does a lot to improve your ability to customize how your WordPress site communicates with Twitter – and it just got a lot more powerful!

Buy it now!

I released a brand-new WordPress plug-in today, targeted specifically at improving accessibility issues. There’s only so much you can do via a plug-in when it comes to site accessibility — most of what grants accessibility for a WordPress site is in the theme. However, that doesn’t mean that you can’t do anything.

This plug-in is designed to help shoehorn some accessibility improvements into themes that need a bit of help. It can do a fair amount, and every feature can be disabled or enabled as needed for a specific theme.

The plug-in is new, so forgive me for any errors — either in judgement or in execution — but here’s what it can do so far:

• Remove redundant title attributes from page lists, category lists, and archive menus.
• Enable skip links with WebKit support by enqueuing JavaScript support for moving keyboard focus.
• Add skip links with user-defined targets.
• Add language and text direction attributes to your HTML attribute
• Remove the target attribute from links.
• Force a search page error when a search is made with an empty text string.
• Remove tabindex from elements that are focusable.
• Strip title attributes from images inserted into content.
• Add post titles to standard “read more” links.

Many of these are tasks that have been performed by a diversity of plug-ins or have been known as customizations to WordPress over the years, but many of these plug-ins have not been updated for a long time. I’ve centralized several valuable accessibility improvements into one plug-in, to hopefully increase the ease of implementation and ability to find what you need!

At the moment, the plug-in is focused on front-end issues, and does not currently include any administrative improvements.

Download WP Accessibility now and give it a try!