As such, I can’t help but be frustrated when I run across basic form construction which is simply well below the standards I’ve come to expect. A form like this one, for example, is incredibly irritating to my sense of what the web should be:

  <form action="/store/add_event_to_cart/53" autocomplete="off" method="post">    <table>
  <tr>
    <td nowrap><span class="required">First Name:</span></td>
    <td><input id="attendee_first_name" name="attendee[first_name]" size="40" type="text" value="" /></td>
  </tr>
  <tr>
    <td nowrap><span class="required">Last Name:</span></td>
 
    <td><input id="attendee_last_name" name="attendee[last_name]" size="40" type="text" value="" /></td>
  </tr>
 
...[numerous similar fields deleted to avoid boring the hell out of you]...
 
  <tr>
    <td colspan="2">&nbsp;</td>
  </tr>
  <tr>
    <td colspan="2">
 
      <input name="attendee[sponsor_email]" type="hidden" value="0" /><input checked="checked" id="attendee_sponsor_email" name="attendee[sponsor_email]" style="vertical-align: top;" type="checkbox" value="1" />
      <p style="display: inline-block; width: 360px;">Please sign me up to get occasional information from select sponsors, partners, and other fun people.</p>
    </td>
  </tr>
    <tr>
    <td colspan="2">Discount code (if applicable): <input autocomplete="off" id="attendee_discount_code" name="attendee[discount_code]" size="10" type="text" /></td>
  </tr>
    </table>
 
    <input name="commit" type="submit" value="Add Attendee" />
  </form>

But in this case, it’s not just the nature of the form itself. There’s a lot wrong here — the use of table for layout is a big problem, but even if you’re accepting the table as logical (and there is a particular logic which would except tables for forms,) the lack of a summary or headings in that table and the use of empty table cells to provide spacing is a big problem. Then we look at the form itself — not a label element in sight; instead we have plain text using a span and class to indicate if a field is required. There’s no coded indication that a field is required; it’s a purely visual indicator.

My sense of accessibility hurts.

And do you want to know where this code came from? Here it is.

Here are a few good articles on high quality form construction – but don’t bother reading them. After all, they didn’t.

• Sensible Forms
• Pretty Accessible Forms
• Making Compact Forms more Accessible

This is something that pisses me off; but you can find it everywhere. Large organizations responsible for web publishing don’t always maintain the standards they talk about. Is it just talk, then? Does the fact that An Event Apart does what A List Apart condemns mean following standards and implementing accessibility doesn’t mean anything?

Thankfully, no. It does mean that web sites aren’t perfect; and the people doing the labor are frequently not the people who know best how it should be done. But it is a problem — as much as we can evangelize best practices, it doesn’t mean that they’ll be used.

There’s a lot of pressure in the web industry to produce fast results. Sometimes this means people take shortcuts; sometimes it means hiring people who may not be as fully trained or qualified as you really wish you had; and sometimes it means things just go wrong.

But I’m left with a definite feeling of frustration to find that a leading web standards event like An Event Apart should exhibit this kind of HTML on their web site.

How can this be avoided?

Ooh, that’s a tough one. Work processes, new employees, insufficient testing — all of these can allow inferior code onto a site. As a freelance designer, it’s positively rare that I have sole control over new content or template changes after the initial launch. As a member of a team, I can only imagine that it’s even more difficult — anybody with sufficient permissions to commit a change can change the overall level of competency exhibited on the site.

Application of a tool like Marco Battilani’s Big Red Angry Text technique can help, but it’s a little scary to put into a published site if you know that the editing won’t always be done by knowledgeable people. It may demonstrate mistakes, but can sometimes serve to do nothing more than piss off or frustrate your client or staff. It depends on the control and education you’ve been able to impose.

1. Educate. Teach the people who will be doing work on the site as much as you can – the what and the why.
2. Review the site. Review the work that’s been done; a 30 second glance at the code is likely to result in fixing at least some errors, and will hopefully prevent future errors of the same type.
3. Provide tools for self-checking. Not a first choice, since all automated tools are flawed by their very nature, but they can still be of use.

It’s not always practical; but if following these steps is at all an option, it’s really worthwhile.

When the right hand doesn’t listen to the left.
Copyright 2004 – 2009 Joseph C Dolson, Accessible Web Design

First, sources:

Americans with Disabilities: 2005

The primary source for statistics in the Practical eCommerce article was a report called Americans with Disabilites: 2005, produced by the United States Census Bureau. The data dates to 2005, but the report was released in December of 2008, so it’s not far from the most current information available which is based on truly extensive research.

This report was released from data gathered in the Survey of Income and Program Participation in 2005, updating the information from a 2002 report of the same name. The report is limited to the civilian, non-institutionalized population of the nation, and estimates that the overall percentage of the population demonstrating disabilities would rise to 15.7 percent from 15.1 percent if that population was included, referencing information from the 2006 American Communities Survey.

The American Communities Survey

The ACS is a continuous data collection effort by the U.S. Census Bureau used to produce annual estimates at the national, state and local level on the characteristics of the United States population. In 2005, the ACS collected information from approximately 3 million addresses in the United States and 36,000 addresses in Puerto Rico. In 2006, it will also include 2.5 percent of the population living in group quarters, (U.S. Census Bureau, 2003).

Given the rapid pace of technological development, access to ongoing current statistics is of inordinate value to internet-based businesses, although the data is not currently detailed enough to be fully appreciable in web accessibility.

There is a more recent report, from the 2006 American Communities Survey, but the data collection is organized differently, so I elected not to mix the two to avoid introducing errors caused by relating data sets which are not a definite match. Regardless, both sets of data include valuable information, and are well worth consulting.

The primary flaw in this period of American Communities Survey data is that it does not break out separate types of sensory disabilities; blindness and deafness are collapsed into a single category. Although both of these issues have a bearing on web accessibility, the response to the issues is so radically different that this is a major flaw in the data when it comes to web accessibility analysis.

More recent American Communities Surveys have broken this information down further. As of the 2008 questionnaire (downloadable from the Census website), sensory disabilities are separated between blindness/low vision and deaf/hard of hearing.

Cornell University: Disability Statistics

A third fabulous source for disability statistics (with easily the best interface of the group) is the Disability Statistics project at Cornell University. The data is sourced from the American Communities Surveys and the 2000 United States Census, along with a few additional sources, so the base data is the same, but a greater variety of perspectives are available.

The Cornell database requires an account to access statistics, but they do provide free access using a public “guest” account. The email and password entered for the guest account are both “guest.”

Issues with the Data

It was necessary, of course, to summarize the data used for the report. However, each of those numbers should be viewed in context, as well. All of the data referenced is accessible as a Excel download from the U.S. Census Bureau (linked above).

The data is excellent for gaining an overview of the disabled population of the United States, but is not specific enough to give a clear sense of whether these disabilities will impact your web site. The statistics from the American with Disabilities report clearly state, for example, that 3.4% of individuals over 15 years of age have difficulty seeing; a total nearing 8 million people. However, exactly what is included in the data is hard to specify. The information was gathered by asking a series of questions, gathering whether the person had difficulty reading newsprint, etc. It doesn’t specify anything about the nature of the problem.

In general, my assumption is that the data may include some individuals who struggle with reading due to dyslexia, dependent on the exact phrasing of the questions, but not all, and presumably includes no or very few individuals with color blindness.

Download the reports (all in PDF format):

• Americans with Disabilities: 2005
• Disability Status and the Characteristics of People in Group Quarters
• 2006 ACS Content Test Evaluation Report Covering Disability

United States disability statistics: Measurement and sources.
Copyright 2004 – 2009 Joseph C Dolson, Accessible Web Design

Today, the good folks at SEOmoz published an extensive article documenting their statistical findings on web site ranking factors, as gathered from the data in their LinkScape analysis tool. It’s a good article, and demonstrates some interesting results they’ve garnered from the data available in the extensive LinkScape database.

One of their major takeaways in the article was a little disturbing to me.

“Alt attributes of images are probably pretty important places to use your keywords[.]” Explaining (Some of) Google’s Algorithm with Pretty Charts & Math Stuff, October 22nd, 2009

I’m not in anyway disputing their results; their data indicates that placing keywords in alt attributes is of benefit to search engine rankings. Whether that’s true or not is irrelevant to me; I simply want to discuss how this information should be best used.

SEOmoz, of course, is a company dedicated to the study and practice of search engine optimization and marketing. Their goal is to learn what they need to know in order to best put into practice the promotion of web sites. That’s great. My goal, however, is to make sure that users with disabilities are able to use and access web sites successfully without having to jump through unnecessary or unhelpful hoops along their way.

This is a particular case where the SEO method must be used cautiously and selectively if at all. What I want to convey in this article is the fact that while using keywords in alt attributes may help your web site rank, it can also result in a significantly less accessible web site, if applied poorly.

What’s the problem with alt attributes?

While sighted users will never even be aware of an alt attribute value in normal web browsing, screen reader users depend on them. Excess verbiage can render an image-based menu unusable, as I observed in a recent site review at Practical eCommerce. The same unnecessary use of keyword terminology in contextual images can easily confuse or distract a user; and the use of keywords with spacer or ornamental images can cause a web site to be completely unnavigable.

It’s all a question of information overload: practically speaking, if a web site uses images to convey information, a screen reader user can’t disable them without rendering the web site unusable. If the site also fills other images with extra text, the same user may be overwhelmed by an unnecessary volume of keyword phrases.

The SEOmoz report does continue to remark that “Keyword stuffing may be holding you back,” and the overuse of keywords in alt attributes can certainly qualify as keyword stuffing.

You shouldn’t take away from this article that using a keyword in an image alt attribute is totally unacceptable. That’s really not the case: just be selective. I wouldn’t condemn you for using the text “About ProductName” instead of “About” for a navigational image, or using a sensible alt attribute for a contextual image, such as “Woman using our ProductName.” Just remember that keyword stuffing is keyword stuffing, wherever you put the words.

And never place any value in the alt attribute for a purely decorational or spacing image. Please. Just an empty attribute.

Best practices: keywords in alt attributes
Copyright 2004 – 2009 Joseph C Dolson, Accessible Web Design

Continuing updates: Cli.gs gets a temporary stay of execution. Keep watching for further news — I may end up making these changes after all, but for now I’ll wait and see.

The Cli.gs URL shortening service is due to be closed down on Sunday, October 25th. At this time, the service will stop accepting new short URLs and generating statistics, but will continue to forward visitors at least through the end of November.

What does this mean for WP to Twitter?

Shortly before October 25th, I will release a very important update to WP to Twitter which will encompass the following changes:

1. I will remove support for new Cli.gs shortened URLs.
2. To continue offering choice, I will add support for at least one additional shortener.
3. Users with Cli.gs as their selected shortener will be given a choice what shortener they’d like to switch to.
4. If no choice is made, users will be switched to un-shortened URLs

Additionally, I aim to add support for custom shortened URLs – URLs shortened on your own domain. However, this may not happen by October 25th.

WP to Twitter update: Cli.gs to be shut down
Copyright 2004 – 2009 Joseph C Dolson, Accessible Web Design

Read my review of of Pets Contained at Practical eCommerce.

It’s always interesting to see what I’ve written after the editors have had their way with it…

New Accessibility Review at Practical eCommerce
Copyright 2004 – 2009 Joseph C Dolson, Accessible Web Design

Not a bad way to get a handle on WordPress plugin authoring. There may be a better way to approach the subject, but I can’t honestly say that I know what it might be.

The fact is, WordPress plugins are incredibly powerful and cover an enormous breadth of possibilities. As the guide indicates, the WordPress plugin API is essentially a WordPress-specific method of accessing the entirety of the PHP programming language. If you can do something with PHP, you can probably do it in a WordPress plugin.

The book has a basic assumption that you’re already fairly sophisticated in your use of PHP programming. Rather than hold your hands through PHP logic, the important information provided in this book is about how to make use of the WordPress specific functions which will allow your script to tie to WordPress — and the key information that plugin authors need to be responsible for the security of their own scripts.

This is an extremely important piece of information, and can’t be emphasized enough. Probably the biggest flaw in this book is that plugin security isn’t highlighted sufficiently. It’s not that the book doesn’t state clearly that plugin authors need to take care of security, but it doesn’t do it on every single page in six-inch bold type….

But I digress.

On the whole, you can learn a lot from this book, whether you’re a beginner at WordPress plugin authoring or not. The breadth of WordPress plugin capabilities means that most experienced authors don’t know everything, so there’s almost certainly something here for you — but it starts simple, and within the first 30 pages you’ll already have a usable, practical plugin written.

Review: WordPress Plugin Development: Beginner’s Guide, by Vladimir Prelovac
Copyright 2004 – 2009 Joseph C Dolson, Accessible Web Design

The goal of this article isn’t to tear down the hard work web site owners have done, so I’m not as harsh as I might be in another context — it’s also not a paid consulting review, so I’m not as thorough as I could be.

The purpose of these reviews is to provide an overview of some accessibility problems on every site reviewed; it’s superficial, but it will hopefully help make ecommerce web site owners more conscious of the issues they face with users with disabilities.

The first review is available today: Accessibility Review: Lori’s Wigsite.

I know perfectly well that this review, and the ones to come, will be leaving issues out. This is unavoidable. However, I’m interested in comments concerning these missing issues — if you are passionately concerned about elements left out, covered too superficially, or dismissed too quickly, let me know about it! I can’t cover everything, but I do want to know your thoughts.

Accessibility Review at Practical eCommerce
Copyright 2004 – 2009 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 – 2009 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 – 2009 Joseph C Dolson, Accessible Web Design

Granted, I was on vacation for a big chunk of the last four weeks, so we’ll call that an excuse.

The new column is Accessibility and the Checkout Process, summarizing a few of the key issues to be aware of when you’re trying to make sure that people with disabilities can get through your store — and succeed with your ultimate ecommerce goal.

New Column at Practical eCommerce: Checkout Process
Copyright 2004 – 2009 Joseph C Dolson, Accessible Web Design