Website Wizardry

 

A successful website is a whole lot of work! The easy (and I use the term “easy” lightly) part is getting your site live. Sure, you might run into a few technical glitches when you initially get it up and running. You might have to postpone your launch date a couple of weeks — or months — to get it up to speed. And maybe you don’t always see eye to eye with your graphic designer or programmer, but basically the development part is the simple part. Right?

Once your site is up and running with the eyes of the world watching, you are left with some blazingly obvious questions to answer. How do you get your target audience to visit? How do you keep them coming back? Can your target audience actually access the masterpiece you’ve dished out money to develop? What if your initial design wasn’t as good an idea as you initially thought?

When it comes to developing an accessible website, there are two schools of thought. One school would suggest that you develop your site as you see fit, filling it with as much technical wizardry as you can muster, and ensure that you have made appropriate measures, where applicable, to make it accessible (text-only version, text equivalents for images, etc). This approach invests heavily in the idea that technology will move quickly enough to provide solutions for any access issues that may arise. It is almost a “trickle-up” sort of philosophy. Taking this approach may leave some users behind, but the hope is that one day the technology will pull them along.

The other school suggests you design a site to accommodate the lowest common denominator of technical requirements. Use hypertext and design tools in a highly structuralized fashion, and steer clear of complex graphics, features and design mechanisms that would make your site more difficult to navigate (no plugins, java, full-screen graphics, frames, etc). This approach will allow you to reach a wider array of users or visitors, but doesn’t necessarily allow you to develop the sort of features that will draw them back time and time again.

As these two concepts for site development battle it out, some middle ground has been reached. Netscape’s Cascading Style Sheets (CSS) are often cited as the answer to the accessibility issue. Using Netscape’s guidelines, a certain amount of success can be reached in terms of making your site accessible. Bear in mind that the CSS technique requires the home user to have the latest version of Netscape’s Navigator software (leaving behind those loyal to Microsoft’s Internet Explorer) and has many reported bugs, as well as questionable reliability.

The other hype in the Internet development world is something called XML, or Extensible Markup Language. XML is similar to Hyper Text Markup Language (HTML), both of which are sets of properties that specify how documents or pages in the Internet will appear when viewed. XML allows for more flexibility for both developer and home user alike to model, or form, information delivered on the Internet into more dynamic formats that can (hopefully) be tailored to individuals needs. XML isn’t available yet and is really only in its development phase at the date of writing.

So, what is left for those of us who plan to develop accessible content for persons with disabilities? Honestly, a lot!

In my office (virtual office, that is) at the Canadian Council on Rehabilitation and Work, we are currently initiating a major reworking of our Internet-based products (WORKink, the Wide Area Employment Network, etc). In the process, we hope to take all of these developing technologies into consideration — without forgetting that some people still love their old PCs and don’t have any interest in upgrading.

Our saving grace is that there are lots of folks out there who have the same concerns about providing access to web-based information and resources that we do. The World Wide Web Consortium (www.w3.org), or the W3C, has taken a big leap by developing the Web Accessibility Initiative (WAY). Here at home, Industry Canada has a set of guidelines that are a useful reference for anyone trying to develop accessible content (its guidelines may be a bit outdated but are good as a starting point). And WebABLE (www.webable.com) has an extensive list of resources on Internet accessibility issues.

Make sure that, if you have a website or plan to have one developed, your designers and tekkie friends read through these sites. It is much easier to make a site accessible when it is initially designed than to try to retrofit it once it is live.

(Mathew Growden is the editor of WORKink (www.workink.com).)

 

Related Articles

Recent Articles

Complimentary Issue

If you would like to receive a free digital copy of this magazine enter your email.

Accessibility