Blog ยป Archive by category 'Web Development'
My first ever print article is now available online - Web Weaving, published in the June issue of “QualityWorld.” This article deals generally with some of the issues of developing a small business website and what you can do to stay competitive in the online market. It’s not stricly an accessibility article, although the issue is addressed. It’s not really a search marketing article, either, although that’s also relevant.
It is, fundamentally, a basic web site development planning article. The purpose was to cover a wide expanse of ground for a non-technical, non-web audience. It’s not advanced, and many topics are really only given a cursory glance. My core idea behind the article was to introduce the audience to some ways they can be prepared for their development process.
Shari Thurow, a regular on the search marketing speaking circuit, just published an article in the ClickZ network addressing three SEO Myths and Misconceptions. Although the article is generally pretty decent, I do take some issue with how she addresses one area — - the question of replacing images with text.
In fact, my complaint is with what I perceive to be the basic assumption she’s making in this SEO Myth: that web developers and marketers are recommending that web sites replace graphic images with CSS-styled text.
Read more: Replacing Images with Text
Although I deal with issues of usability fairly regularly, usability is not fundamentally one of the chief areas I work in. It’s certainly an area I’m very interested in, and is closely related to accessibility, but I haven’t been involved in any full scale usability testing. So, it’s rather interesting to me that one of the first sponsors of this blog should prove to be the makers of a usability testing software package called Morae 2. jo
This is not a paid blog post, although the product was being advertised on this website.
Read more: Usability Testing Software
As often as not, when I’m confronted with a redesign project, the reason behind it is “I’m tired of this look” or “this just doesn’t look modern.” Well, that’s fine. After all, if you redesign your website, the reason for it IS certainly closely tied to the way it looks. However, in my mind, just changing the appearance of a site is not sufficient reason to do that kind of work.
A website redesign is about creating a better website.
Read more: A Redesign Isn’t About Design
Writing a website is a complex task. The website needs to cater to the very human needs of it’s visitors, but also requires a certain amount of consideration for it’s non-human visitors: web browsers of all sorts, search engine spiders, or any piece of software which gathers information from the internet.
These two aspects can’t easily be separated: humans are using computers to interface with your web-based information, so the information received by your visitor is biased by the device they’ve used to access it. Website design and development requires a very conscious and simultaneous consideration of both parts.
Accessible web design is often times very computer and device-centric. Much of the process seems to be:
These are, to some degree or another, measurable and definite. They provide a definitively testable scenario where you can state clearly that website A is more accessible than website B. This doesn’t mean that either website is actually usable.
The technical aspects of accessibility are easy. They’re a pleasant shortcut from not knowing what you have to a sense of confidence that you’ve done the right thing. They’re also quite necessary — - if your human audience is unable to make use of your site due to a technical issue you should absolutely be able to fix that. Your code is written for a computer, and you provide the best information to whatever device is being served your page in order to give it access to your website. This applies to user agents and web spiders.
But the ultimate audience is not the device; it’s the person operating that device. A second layer of much less measurable consideration needs to be applied to the people operating devices.
- You’ve provided the ability to change font size. Do you need to tell your audience?
- You’re using hidden skiplinks to help navigate. How does somebody know this?
- You’ve got a really cool AJAX search which discovers results as your visitors type: do they know this?
You can’t make assumptions about your visitors or their devices. Many techniques are questionable because of discoverability — - a screen reader may support the JavaScript you’re using to power a technique, but not have a means to inform the user of the change in the page. The JavaScript you’ve written may degrade when JavaScript is not available — - but how does it degrade when an earlier version of JavaScript is all that’s available?
At the end of the day, you have no way to know exactly how well you’ve done. Even a thoroughly tried and tested site may be flawed when it hasn’t been confronted with users. You can run every machine test conceivable on a website and pass them, and still produce a site with problems. Testing, communication, and a willingness to explore alternatives gives you a chance of success.
Device compatibility is certainly important, but human compatibility is more important. Human compatibility is ultimately a question of audience — - and in the web sphere, as often as not, the audience is filled with question marks. Market research isn’t just about marketing: it’s about knowing your audience so you can provide not just what they want, but what they are able to use.
There’s no question that I’m going to advocate incorporating accessibility at the beginning of development in this brief article. I am, after all, approaching this question from the perspective that no site should ever be developed without taking accessibility into account. However, there are unquestionably millions of websites out there which have already failed to consider disabled populations, so building new accessible sites is certainly not the only work to be done.
Accessibility isn’t really all that difficult, in the development stage. If you make a point to take disability into consideration from the very beginning of the development process, the process is hugely simplified. Original development has a lot of advantages — - the fact that you’re starting from zero provides room for maneuvering which should make accessibility hardly any more complicated than any other project.
The biggest challenge is awareness — - maintaining the hyper-awareness required to consider the huge number of variables which may cause problems for the disabled isn’t easy. But if you prepare a checklist of issues (like this one, for example), you can make huge steps by referring to the list regularly. An intimate familiarity with these guidelines will make it even simpler - avoiding color contrast issues or confusing language are issues you can latch onto very quickly.
But applying accessibility retroactively is a completely different ballgame, and it’s not at all enjoyable.
In development, you can check each design or implementation decision against your accessibility baseline as you go, ensuring a very high level of accessibility from the beginning. When applying the same logic against a completed project — - whether you designed the site yourself or not — - the refitting process is enormously more complex.
Where do you start retrofitting? As a consultant, the job is relatively straightforward — - you just need to find all the problems. But as a developer, you need to also find the source of the problem. Developing an accessible web site is the process of leaving out barriers to accessibility. Retrofitting a website is the process of removing barriers to accessibility. It’s always easier to choose not to build a wall than it is to tear one down.
It’s debatable, ultimately, whether it’s more efficient to fix a project which is broken or to start over. Every project needs to have this question answered quickly, however, since it’s never more efficient to try both. The size of the site makes a difference, as does the choice of technology - a site which was inaccessibly developed in a CMS is a completely different story from a site which was developed using static files.
Why implement accessibility right away? Because it’s easier to do it right the first time than it is to do it over. And if you’ve already developed your site, the time to start over is now. The longer you wait, the harder it’ll be.
I’m not a big fan of most JavaScript widgets which are added to sites. I have a MyBlogLog account; and I find the statistics to be very interesting. The widgets, on the other hand, I find to be varyingly irritating, obtrusive, and most of all slow.
But there’s one particular widget I’ve seen on many occasions which really drives me nuts: Snap’s “Preview Anywhere”. I really don’t like this. To me, this is information overload. With well-written link text, and good context for a link, I know everything I need to know about a site to judge whether I’m going to go there. Do I need to know what it looks like?
I mean, if I go there, I’ll find out what it looks like soon enough. The suspense isn’t killing me. I’ll admit, there’s the faint possibility that I’ll see the preview and say to myself “Hey! I’ve been to that site before — - I’d forgotten how cool it was,” and I’ll follow a link which I would have otherwise ignored.
But it’s a slim possibility.
If my goal for visiting your’s website was to learn more about their links and visit everything they’ve connected to, I’d probably find this widget very useful. However, since my actual goal is usually to read what you have to say, with the possibility that I’ll also check out what you’ve referenced, this Snap widget simply gets in the way.
Lesson to be learned: don’t get in the way of your visitor’s goals. I’ll be honest - there are a number of websites which I find otherwise interesting but rarely visit because of this very widget.
Return to Top
