Launching today, I’m beginning a new series at Practical eCommerce. This is a series of practical accessibility reviews — web sites can submit themselves to be reviewed, and I’ll take some time to review the site and write up my comments in an article format.
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.
A couple years ago, I wrote an article addressing the differences between working in a search engine friendly manner and working on search engine optimization. That article talked extensively about what is included in optimization which is not necessarily a part of being search engine friendly.
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. 
A little while ago, while working on a site built by another developer, I came across this rather interesting example of how to use custom fields badly in a WordPress theme (abbreviated for, well, brevity):
(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:
- Create the new page.
- Add a custom field with the title.
- Check the new page’s ID.
- Find the theme file which contains the meta data references.
- 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:
- Create the new page.
- 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!
Somehow, I’m never fully satisfied when I’m posting notification about a new column elsewhere and see that my last post was also a notification about a column elsewhere. It becomes clearly evident to me that my posting frequently here at Accessible Web Design has gone down a bit.
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.
The latest in my monthly column on accessibility at Practical eCommerce magazine is now available: Web Accessibility and the Law.
Although I’m not a lawyer, I do pay some attention to the nature of legal issues surrounding web accessibility. They’re murky, but this article attempts to shed some light on how the law covers accessibility issues on the internet.
Hope you’re able to get some value out of the article!
The United Kingdom-based Royal National Institute for Deaf People (RNID) recently produced a nice mini-site entitled “10 Things You Should Know About Web Accessibility.” For the most part, it’s excellent — a friendly voice, a casual approach, elegant presentation, and good information.
It does, however, intimate one of my pet peeves in documents promoting web accessibility:
Hey good lookin’
“But accessibility always compromises the design, doesn’t it?”
Wrong. Your site can still look beautiful.
This doesn’t precisely say that compromise is not required for accessibility; but it’s certainly implied by the language chosen.
To suggest that compromise is not required is simply a mis-representation of the truth about accessible web design: you do have to make compromises. Whether they’re compromises concerning how information is presented, the color contrast between elements, the specific uses of language or technology, you have to make compromises.
The perception seems to be that making compromises for accessibility means that you create an unattractive web site or otherwise decrease the aesthetic value of your web creation. This is not true: but it’s inaccurate to say that you don’t make compromises.
Truth: Effective accessible design has requirements which will require compromise in many areas.
It’s important to educate all participants in a web design project on accessibility before any serious work is done, to help prevent problems. If the designer knows to check contrast levels before proposing a design, they’ll start by creating an aesthetically elegant design with the color palette available. If they aren’t aware of these problems, you’ll end up making compromises on colors — and, without extensive modifications, it is entirely possible that these compromises could have a damaging effect on the aesthetics of the site.
Compromise shouldn’t damage aesthetics or accessibility: but poor planning almost certainly will.
It’s now available: Part 4 of the New Accessibility Guidelines series at Practical eCommerce. Part IV: Robustness.
Wouldn’t have thought I had that much to say on the subject of being robust, but there you have it. Enjoy!
Return to Top
