Of course, the lack of support does have some consequences. We can’t just go out writing HTML 5 without having significant awareness of this lack of native support — we have to compensate.

Nonetheless, being able to incorporate great new elements like figure, progress, meter, nav to improve semantics or browser capabilities including content prefetching to provide a faster, more seamless experience for users is actually pretty exciting.

HTML5 Datetime input in Opera 10.53

But new input types…cold shivers.

Sadly, they’re also one of the less useful elements at the moment. Until support is available in browsers, they’ll simply fall back to a text field, unless supplemented by scripting to customize their behavior. But hey — easy upgrade, right?

From an accessibility perspective, this is fabulous news. Or rather, potentially fabulous news. These new input types — including date formats, time formats, numbers, ranges, and colors — are intended to provide user-friendly and accessibility-enabled interfaces for inputting these kinds of custom data. Ultimately, they’ll provide replacements (or fallbacks) to the innumerable JavaScripted widgets used to create date input or color selectors. Users, instead of encountering a different style of calendar every time they need to enter a date, could have a consistent user experience. Having the behavior built directly into the browser, and tied from there directly into any accessibility software in use offers a hugely more dependable experience for users of assistive technology.

Now, this all depends on several factors: vendor implementations need to meet user agent accessibility guidelines; interfaces between browsers need to be consistent; and, of course, the attribute values need to be implemented by enough browsers to make their use truly valuable!

Today, support is pretty limited. You can take a look at Roger Johansson’s HTML 5 input type test page and see whether your current browser supports any of them. If you’re using recent versions of Opera or Safari, the answer will be yes — otherwise, you won’t be seeing very much of interest for a while.

But you can implement these input types today.

All of these different input types fallback to a simple text input. If you’re using the HTML 5 doctype, there’s nothing stopping you from applying HTML 5 input types right now. Any browser that doesn’t support them will simply provide a field to enter plain text — so if you’re currently collecting email addresses in a text input (which seems pretty likely,) then you have no excuse not to change now. You may not see the benefits right away, but why wait? You’re not going to see any downsides, either.

Creating forms has long been a thorn in many a developer’s side. Dealing with how to best layout and collect date information, for example, is always a pain. Do you leave it as a simple text field, and have to deal with who-know-what kind of data received from the user? Do you use multiple select boxes, and force the user to walk through three or more fields just to enter the date? Do you use a JavaScript-based tool to provide a calendar, which may not have great accessibility, may behave strangely in some browsers, and may take a lot of development time to massage into providing the functionality you’re looking for?

Even when browser support for HTML 5 input types is fully available, it’s entirely possible that you’ll want to take the route to custom develop interfaces for various fields. However, unlike the past, you’ll only be needing to do this because something particularly unique is required for the project; for lower-budget projects, you can save a lot of labor and provide a solid interface just by using native features.

HTML 5 has cool stuff: new input types!
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

The specific repercussion will be that every implementation of a plugin will need to be registered with Twitter as a separate application.

This means that the development of WP to Twitter will need to move in a slightly different direction. After pondering a bit, I’m left with four plausible choices:

1. Let the plugin die
2. Implement OAuth for the plugin
3. Build a pass-through web service to act as an application interface with Twitter
4. Associate with a 3rd party web service in the same capacity

These all have downsides, obviously — but I want to lay out my thoughts on each possibility and I’m asking for comments from the users of my plugin on their preference.

Death of WP to Twitter

Although it’s not really my favorite option, I have to acknowledge that it’s plausible. It’s certainly the easy answer — maintaining an even moderately popular WordPress plugin is a lot of free labor. I already spend more time on maintaining than I really should, from a financial perspective, and this may push it over the edge.

Implement OAuth

This would be a fair amount of work for me, although not insurmountable. The real downside to it would be how much work it would be for users — every one of you would have to register one application with Twitter for every site where you installed the plugin. With one site, this may not be a big deal — but I know it could be a real pain for people with more than that.

It’s not without some potential advantages, of course – when you’re registering your own application, you could customize the application name, the home URL for the application, etc.

Build a pass-through service

One way around the Oauth mess is for me to build a separate service which would handle actually connecting to Twitter. WP to Twitter would authenticate with that service, and pass the post off to Twitter. Again, this would be a lot of work — but, more significantly, it would involve some definite expenses.

I’ve been happy to maintain this plugin for not-much-better than free, but when it comes to incurring expenses, I start to feel a bit unexcited. It’s not like WP to Twitter is a commercially viable business, and I have expectations of profit from it — but I’d prefer not to find myself going into the hole because of it. I’d probably need to see an increase in donations to make this feasible.

Use a 3rd Party Service

Obviously, if I can build a service to connect with Twitter, so can somebody else. This is almost certainly the easiest solution which keeps the plugin usable — but it does mean creating a dependency on a 3rd party to keep the plugin functioning. Depending on Twitter is just natural; obviously, if Twitter goes away, the point of the plugin is lost. Depending on somebody else is something I’m less certain of, on the whole. There’s a reason, after all, that the plugin allows for use of URLs without an external shortener.

Give me your thoughts

This is very important to me — I want to know what direction you’d like to see WP to Twitter go. Please let me know! Do you know another solution? Do tell!

And if there are no responses…well, that has a pretty obvious meaning as well.

The future of WP to Twitter
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

Interestingly, the most frequent complaints I’ve heard since launching it were in an area which I had considered to be the least important area of the plugin — what it looks like.

I only did minimal work in setting up the appearance for this plugin; checking whether it basically worked in the default WordPress themes and little else. My assumption was that if anybody needed the plugin, they’d just have to be prepared to customize it to meet their needs. There was no reasonable way I could set it up to mesh with all possible themes, after all!

But apparently, in order to have the plugin be generally accepted, people need it to have “a look.” Most advanced users will probably change it; but I clearly hadn’t considered the more beginner users, without sufficient CSS knowledge to readily customize the output.

What’s really interesting to me about this situation, however, is not whether the plugin is accepted, popular, or heavily designed; that’s just an example. I was intrigued to observe in my own development process an approach which almost entirely ignored what the product looked like. From start to finish, I was really thinking about whether the plugin produced well-structured HTML and whether the various functions involved in producing information worked well.

I just never thought about design. And why would I? If I can’t predict what context the plugin will be used in, why should I design it at all, beyond making the basic functionality clear?

It’s an interesting question; from my perspective, as a fairly advanced WordPress developer, I honestly prefer plugins I use to have absolutely minimal styles, and for me to be able to disable those styles at will so that I can replace them. However, WordPress has a very broad user base. Most of those millions of users probably expect that they can install a plugin and immediately make use of it — and any changing of colors or reskinning to better match their design is purely optional. For those users, I really should be providing something which can be immediately useful.

It actually does come down to usability: advanced users can do what they want with the calendar design regardless of how extensively I’ve set up styles. Beginning users, however, may not be able to fix anything that I’ve left unresolved, or not fully tested. In order to provide the best usability, I need to consider those users, as well.

Having determined that it does make sense to actually design the plugin’s output, but also knowing that there’s no reasonable way I can design it to match all themes, I do have to make a firm decision about what the basic color scheme for the plugin will be. Originally, I’d used a basic, Kubrick-derived color set. Now? Well, the sensible thing seems to be to consider branding; set it up using my own website’s color scheme. It may be subtle, but it will convey my identity, even without my name or URL. That seems worthwhile.

Guess I better get to work!

Form over Function? Never thought about it…
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

Version 1.3.0 released. Numerous bug fixes and new features.

I just launched the first public draft of an online calendar plugin I’ve been working on for a while. It’s based on a plugin from Kieran O’Shea, Calendar, but has been adapted extensively to better suit my own needs.

Hopefully, it’ll also suit other people’s needs.

• Read more about My Calendar.
• Download My Calendar.
• View a sample installation.

Please leave comments or questions at the My Calendar support page; leave feature requests on the feature request page!

New WordPress Plugin: My Calendar
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

And, naturally, it always fails. Something goes wrong in the system; gross negligence of maintenance causes a malfunction; or some unanticipated exception allows the hero to escape.

This is an important thing to keep in mind when designing or building a web site, in every aspect. When you think you’re adding fabulous new functionality or greater accessibility, you should always be thinking about whether you’re ultimately supporting your visitor’s needs — or just making your system needlessly more complex.

Jared Smith, from Web AIM, recently published an article on web accessibility preferences expounding on the notion that in most cases, providing tools for your disabled users to change their experience usually means that you haven’t done your job right in the first place. Perhaps, rather than adding a tool to enable people to adjust your site, you should simply fix the site. Jared makes the very good point that in most cases, the people who need text enlargement have already taken care of it through their browser settings or operating system; and those who need extreme enlargement can’t be helped by a common accessibility widget — they need software support.

So, given this case, what do you actually accomplish by adding accessibility widgets to a web site?

If you’ve added them to a global element, to make them available throughout the site, you’ve made your site more complex: there’s more information on every page which needs to be sorted through or skipped over. You’ve added an additional technical element which needs to be supported and maintained — as browsers change, you’ll need to be rechecking not just your default settings, but all of the various combinations you’re providing, as well.

If you’ve added the same options to a page dedicated to these accessibility options, you’ve pretty well avoided the problem of having a globally more complicated interface. However, you need to ask yourself whether the problems your accessibility options fix will prevent the users who need them from finding the options! Take this example: you’ve chosen a relatively low-contrast (but attractive) text color for your footer and secondary header navigation. Since this color is below the WCAG 2 color contrast requirements, you’re providing a link to a page where the user can select a high-contrast option.

Unfortunately, since the link is in your footer, that user who needs a high-contrast page can’t actually find the page where they can make the change.

Problems with site complexity don’t only effect web accessibility, however. Any additional function to your web site needs to be carefully considered before implementation: is it worth while to add an audio player with auto start to your home page? What are the consequences of making this change? You may think that it’s a great opportunity to immediately promote your band’s music to those who want to hear it; but you’re making the gross assumption that those visitors want to hear it right now. They may not. And if they’re in a sensitive situation — checking you out from their quiet office cubicle, for example — then their first reaction is likely to be “How do I turn this off!”

Assuming you have decided to add this audio player to your web site — you may not realize that the most important control you need to have is a prominent STOP button. Otherwise, the most natural way to stop the music is to leave your site.

Any piece of new functionality adds complexity to a site. It may create an undesirable reaction, it may create user confusion — or it may be a brilliant idea which turns your home business into a multi-million dollar corporation. You shouldn’t avoid adding functionality on the grounds that anything complicated is going to be a problem; but you should certainly take a very close look at every new feature and decide whether it will add to the user experience. When making that decision, the points to consider are not limited to the value of that feature alone. You need to also consider all the other features which will be simultaneously available; you may want to add a new feature, but move an existing one. It’s usually not any given feature which causes problems; it’s having too many paths to follow which may confuse your visitors.

When More is Less
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

Shari Thurow, a well-respected researcher in the search engine optimization and usability realm, suggested that separating the two concepts is, in fact, ridiculous.

Well, that may be. However, I think that it’s crucial to break a task into parts if you want to gain a thorough understanding of the whole. Search engine marketing is an excellent example of a whole which is greater than the sum of it’s parts.

As I see it, building a search engine friendly site is one of the first stages of best practice search marketing. The adage “if you build it, they will come” fails to hold, however: a site which is constructed merely to be search engine friendly will gain little to no traffic.

Being part of the process

Being search engine friendly is a part of the process of search engine optimization; which is, itself, a part of the process of search engine marketing. In addition to these two aspects, search engine marketing may also include pay-per-click advertising, print advertising, link building and social media participation. Search engine marketing is a large area, and very, very few people are expert in all aspects. I’m certainly not.

From a marketing standpoint, what parts of this marketing whole are necessary for your business to succeed is going to vary radically depending on your industry and the way your business intersects with the internet. It will also depend on your definition of success. If you’re looking to maximize growth, you’ll probably want to be investing in all aspects of marketing.

So I’m arguing that search marketing, while clearly a practice in which the parts of the whole are highly interwoven and carry clear dependencies on each other, can nonetheless be separated into it’s component parts for a variety of reasons, including for the sake of discussion.

Now let me take this a step further. Not only is it possible to separate search engine marketing into separate aspects for discussion, it’s valuable.

If you want to understand the interactions between the different aspects of a task, it’s important to have some information about all parts. In this context, it’s necessary to treat the whole of search engine marketing in a given discussion. However, when you want to understand the details of a specific task, it’s important to stay focused on your part of that task.

It’s necessary for practitioners in search engine marketing to know, in general, what the impact their work will be on all aspects of the marketing campaign. It is crucial for practitioners in search marketing to know, in detail, exactly how to perform their own tasks in the best possible manner for their clients. It’s important to treat an area of expertise specifically. Talking through the nature of that area; comparing and contrasting it to other related areas; considering the specific nature of tasks within that area of expertise: these are all ways of better defining and refining knowledge on a specific subject.

Why does this matter?

It doesn’t, really. It’s all semantics. Search engine optimization is the commonly known term, and it frequently is understood to encapsulate search engine marketing. Or the other way around. The industries around search engines and marketing (and just about anything internet) are young, and the vocabularies aren’t really all the firmly established. As a result, some people have a very firm opinion of what a given term means which may not always coincide with others definitions.

Well, that’s why we write about it. We’re all hoping that our definitions will ultimately win.

Taking a holistic view of SEO in parts.
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

(The original also did this for meta keywords and meta descriptions — but the demonstration of this “logic” only requires one field.)

 
<? if (is_front_page()) { ?>
	<title>Handwritten title</title>
<? } elseif (is_page("page-name")) { ?>
	<title><?= get_post_meta(334, 'meta_title', TRUE); ?> | <? bloginfo('name'); ?></title>
<? } elseif (is_page("page-name-2")) { ?>
	<title><?= get_post_meta(383, 'meta_title', TRUE); ?> | <? bloginfo('name'); ?></title>
<? } elseif (is_page("page-name-3")) { ?>
	<title><?= get_post_meta(381, 'meta_title', TRUE); ?> | <? bloginfo('name'); ?></title>
<? } elseif (is_page("page-name-4")) { ?>
	<title><?= get_post_meta(383, 'meta_title', TRUE); ?> | <? bloginfo('name'); ?></title>
<? } elseif (is_page("page-name-5")) { ?>
	<title><?= get_post_meta(387, 'meta_title', TRUE); ?> | <? bloginfo('name'); ?></title>
<? } ?>

And so on. For approximately 40 separate pages. It made my brain hurt. For reference, the exact same thing — for all pages on the site — could have been accomplished (with better fallback conditions, in fact) with this code:

 
<?php if (get_post_meta($wp_query->post->ID, 'meta_title', true)=="" && is_page() ) { ?>
	<title><? wp_title('|', true, 'right'); ?> <? bloginfo('name'); ?></title>
<?php } else { ?>
	<title><?php echo stripslashes(get_post_meta($wp_query->post->ID, 'meta_title', true)); ?> | <? bloginfo('name'); ?></title>
<?php } ?>

Now, the original code may actually look cleaner — it does, after all, have fewer functions and fewer variables. However, the second example is a hell of a lot more maintainable.

If you add a new page to the site in the first example, you have to:

1. Create the new page.
2. Add a custom field with the title.
3. Check the new page’s ID.
4. Find the theme file which contains the meta data references.
5. Add a new line in the elseif loops which references your new page first by slug and then by ID

With the second example, you simply:

1. Create the new page.
2. Add a custom field with the title.

No coding, no PHP, no editing themes — it just works. Well, isn’t that handy? This is just basic good coding practice: make your code reusable. There’s absolutely no reason to code something into your WordPress Themes which is not readily transportable unless you’re doing yourself a favor by avoiding an unnecessary server call by hard-coding the site name or other known elements.

The basic difference between these two examples is simple: the first requires you to hard code the ID and page slug for each example; the second grabs the post ID from the existing post object. The second example also has a fall-back if no information has been entered in a given custom field — which is lacking in the original code.

Word to the wise: save yourself some work!

How NOT to use Post meta fields in WordPress Themes
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

Thankfully, the reason for his blogging silence is pretty straightforward: he’s been writing a book. Sweet!

The book is entitled “Selling Usability,” which is a bit of a misnomer, since the subject of the book is perhaps more accurately described as “Making Usability Happen, Despite the Regrettable Lack of Understanding on the Part of Your Managers.” To be fair, that would be a pretty unusable title.

It’s clear within the first 20 pages that John and I share a core philosophy concerning the application of usability: as much as you’d like people to buy in to the core ideals of user experience, you need them to buy in to making the change. By hook or by crook, making the change is what needs to happen in the end.

You can only teach those who are willing to learn; but you can guide anybody to the right decision if you use the arguments they understand and care about.

Selling Usability: User Experience Infiltration Tactics is a guide to convincing decision-makers towards user-experience focused decisions by using business-focused arguments and tactics.

“Selling Usability” is about communicating effectively.

John’s writing is frank and clear. He writes in a casually persuasive voice which quickly drives through the description of a problem into the analysis of why this is a problem — and how you might start to solve it.

This book is not about usability. You’ll learn a lot about understanding and communicating the user experience by reading this book, but it’s not going to teach you how to study user interaction.

Buy it now. You’ll learn more than you think you will, no matter your background.

“Selling Usability,” by John Rhodes.
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

And, as the developer, it’s your job to figure out how to re-do these projects. Usually, there will be more than one way to get the job done: at minimum, you’ll see a quick and dirty method and an arduous, finicky, complicated method which makes tears spring to your eyes in anticipation of the painstaking hours.

Finding the “right” way to do the job is a matter of balancing needs. In an ideal world, the “right” way is the method which gives you perfect accessibility, fantastic usability, and helps sell a million copies of your client’s product in the first 24 hours.

In the real world, it’s the best compromise between your time, your client’s budget, and the needs of the site audience. It may even be a more specific audience — the users of the specific portion of the site which is creating this challenge.

The Challenge of Scale

When you encounter a dozen pages with code which is layered with font elements, excessive span elements and dozens of unnecessary style attributes it’s a trivial task to strip the extra HTML and replace it with the bare minimum required for your needs. When you encounter 12,000 pages like this, of course, you may be looking at man hours which aren’t available anymore.

The Challenge of Legacy Systems

Rebuilding that CMS to deliver a reasonable facsimile of conforming HTML may not only be beyond the scope of practicality — it could well be a violation of the client’s license to use the software. If it’s expensive software, sacrificing a support relationship with the software developer could be very damaging.

With major CMS rebuilds, the most important thing is to identify the scope of changes you can make. Maybe you can’t replace every problem, but it’s honestly not worth discarding $30,000 worth of software investment for the sake of validation. It is worth discarding $30,000 worth of software for the sake of legitimate accessibility barriers. If the system will not allow you to create an accessible form, or generates a shopping cart which cannot be operated without using a mouse, that software should be replaced.

The Challenge of Fancy Widgets

Your client is in love with that poorly-designed Flash widget provided from CrazySite.com. They’ve just gotta have it! It can’t be used by anybody who isn’t using a mouse, the font size can’t be adjusted and is set to 8pt Arial, and there’s a constant red flash which might trigger seizures. But it’s just so cool!

Before you even start discussing the issues above — the un-sexy and hard to sell accessibility problems — it’s good to have a serious discussion with the client the answer one key question: Why. Does the widget serve a purpose for their business? Does it help their users? Does it help sell their product? Sometimes you can successfully get a client to make the right decision on their own once they realize that a function does not actually support their business in any way.

If, on the other hand, it does actually support their business, you’ve potentially stuck yourself with the greater challenge: replacing the functionality of the widget using an alternate means. Programming APIs are great, but not every site actually offers one.

The Challenge of Impossible Functionality

“Impossible” functionality is actually a bit of hyperbole. In my own experience, I’m not sure I recall ever having been asked for something which was actually impossible. However, I have been asked for functionality where the labor to value ratio was extremely unfavorable to the client, which is probably close enough.

Now, this is a highly variable challenge. Sometimes, the best thing to do here is just to ask for a second opinion from a programmer with more specific knowledge than you have. However, assuming that the request is actually unreasonable, the challenge is pretty much the same as above – find out what the client really wants. Sometimes, the difficulty is simply terminology. Some clients might use technical terms in an overly general manner, which can sometimes lead to misunderstandings.

Learning to inquire about project needs without using technical terminology is one of the most valuable tools in your scoping toolkit — it can save you tremendous amounts of time, wasted effort, and frustrated miscommunication.

What is doing it right?

So, in the end, what does it mean to do something right? Ultimately, it means not getting lost in the impossibilities of requests and avoiding being distracted by confusing requests. Doing a project right always starts with good scoping: continually asking questions until you’re absolutely certain that what you’re working on is really the project requested. Once the project is properly defined, the tools are known and understood, then doing the project itself is simply a matter of time and normal best practices development!

Let’s find a way to do this right!
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

Obviously, no survey is perfect — but observing the overall scope of responses can effectively expose some aspects of screen reader usage.

In fact, the preliminary results evidence a number of interesting conclusions. Among the statistics are indications that screen reader and web site evaluators who do not have a disability sometimes have a very disparate idea of what is more accessible than those with disabilities — an issue possibly connected to the evaluator’s lack of sophisticated familiarity with the screen readers.

It’s not altogether surprising that we in the web accessibility industry do not always choose the path which is actually most preferred — our impressions are necessarily biased by our own understanding of the technology, our presumptions of what is sufficient information, and our lack of ability to fully ignore the visual input we do receive.

That’s what makes this survey so particularly valuable: it begins to expose the difference between common misconceptions of what is accessible and those which are truly of benefit.

In the evidence in this study are included indications that disabled users would prefer that photos which are part of a page should be fully identified: as a photograph, and as the object depicted. There are indications that while site maps may be valuable, they are not in fact widely used by disabled users. There are indications that on-site search and navigation by headings are two of the most important navigation methods on a site for the disabled.

And, unsurprisingly, there’s fairly definitive confirmation that Flash is difficult for the disabled to use.

Nonetheless, the conclusions drawn from this information aren’t really that simple. With Flash, for example: the problem with Flash is almost certainly that the Flash web sites visited were not designed with accessibility in mind. Flash can be used accessibly, but in 9 cases out of 10 (a number I’m making up for hyperbolic purposes) it’s been developed with no regard whatsoever for accessibility issues. So the issue is not precisely with Flash — rather, the problem is with Flash developers.

The preliminary observations from this survey are well worth reading; and I’m definitely looking forward to seeing further analysis of the results.

Thank you, WebAIM!

WebAIM Survey on Screen Reader Usage
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design