Website Design For Accessibility: Part 1 | Part 2
Contributor: Andrew Ward

Designing websites to suit as many visitors as possible is a great challenge. Differences in hardware, browser software, and visitor needs all have to be taken into account when trying to find that 'best compromise'. In this extended two part guide, Andrew Ward guides the web designer through the main issues surrounding web design accessibility.

Introduction

Whether a website is transactional or informational, and whatever business objective has been set for it, success is usually reliant on attracting and maintaining the maximum possible number of visitors. Clearly it therefore makes good sense if Web users are unlikely to encounter technical problems or viewing difficulties when visiting the site. The task of the Web page author is therefore to produce a site that is viewable on the widest possible range of platforms - both hardware and software - by the largest possible user population. However, the reality today is that many sites are poorly designed from this perspective, and many users encounter difficulties when visiting them.

One of the unfortunate drawbacks of the Internet, and of the Web in particular, is that there is virtually no regulation. Before publishing a Web page there is no requirement to submit the content or the html code to any authority for approval. As a result, Web authors are not used to having to write valid html, nor to taking into account the wide range of challenges that viewers may encounter when accessing sites.

Furthermore, most Web browsers are very forgiving. For example, if a browser encounters a table element, such as a row,without a table first having been defined, it will probably work out what to do with it and make a reasonable job. This tends to be very misleading for the Web author, who believes that the page is correct simply because it happens to give a reasonable display in one specific set of circumstances. However, the page may appear as complete nonsense to other users.

Browser Dependency

One of the most common traps that Web site designers fall into is browser dependency. Unfortunately, information from the browser companies themselves sometimes doesn’t make it clear that features they offer are unique to their products, and people who republish the information then omit this warning. As a result, there are countless Web authoring guidelines that explain the use of the marquee tag, without mentioning that it only works with Microsoft Internet Explorer.

While Internet Explorer accounts for the majority of the Web browsing audience, there are still some 25% who use other browsers - and this figure may be much higher in certain industries where a different platform such as Unix, or a different browser such as Netscape Communicator, may predominate. Another common error that many Web authors make is to create pages that aren’t easily viewable on the Mac, simply because they don’t have one to test on. Once again, the number of Mac users is small, but these systems are very popular in certain market segments such as media and advertising, which could be a key part of the target audience for some sites.

Different browsers and platforms render fonts to different sizes, so text that looks acceptable with Internet Explorer on a PC may be too small to read with Netscape, and even smaller on a Mac. And if someone has a very high resolution screen, although a small font won’t lose resolution it will be physically quite tiny and require them to peer very closely.

Browser Testing

Fortunately, there are many free Web-based services that allow the Web author to test sites for performance with different browsers. These do not produce perfect renditions, and are not a substitute for proper testing on different platforms and with different browsers, but should alert the author to any major problems. Ideally, the Web designer should have access to a range of different hardware and software platforms, and in particular invest in a Mac, or at least a Mac emulator for the PC.

As well as compatibility between different browsers on different platforms, the author also has to concern themselves about older versions of browsers that may not support more recent features. The html specification has undergone substantial change and improvement over the years. One of the browser compatibility viewers, hosted by Delorie Software, is located at http://www.delorie.com/web/wpbcv.html. This viewer allows you to turn off specific features, such as frames, fonts and scripting, to see what pages would look like with a browser that lacks support for them. Remember that WebTV doesn’t support frames - in any case, frames seem to have fallen out of fashion, and are rarely used by major Web sites today.

It’s also worth taking into account those users who will be operating with a text-only browser such as Lynx. It’s not unusual to still see Web sites that advertise a text-only version consisting of an additional set of pages .However, unless the author is trying to create a particularly complex page, featuring many elements, most pages can be designed to produce an acceptable text-only display without significant design compromises. Delorie Software has another viewer that allows the author to select a text-only display. See http://www.delorie.com/web/purify.html.

Compatibility with earlier versions of html and the Web TV platform can also be tested at this location, by selecting the desired html version from a drop-down list. By the way, looking at web logs is not a good way of judging the importance of the Web TV audience for a particular site. There is a very active Web TV community and if a site is known to work well in the Web TV format, word will quickly get around. Conversely, a site that’s known not to adapt very well to the restricted format will find itself with virtually no visitors from the community.

See AbleStable's review of CSE HTML Validator for a good all round web page software validator.

Display Dependency

One of the major problems resulting from the lack of regulation is that many Web authors have not appreciated that in theory at least, the presentation layer of the Web is under the control of the user. The screen size and resolution, browser window size and shape, colour scheme, and font size, style and colour are all supposed to be under control of the visitor.

With many sites, the problem is rather more fundamental than just restricting the visitor’s choices. Often, authors haven’t appreciated that there is such a thing as a presentation layer at all, and so many pages don’t make clear distinctions between content (the actual text), structure (whether an element is a heading, list or whatever), and presentation. This not only makes it more challenging to produce viewable pages, but increases the difficulties of maintaining them.

This problem partly stems from the fact that html itself doesn’t make it very easy to distinguish between content, presentation and structure. That issue has now largely been solved with the advent of cascading style sheets - but these are still very rarely used. In the future, the situation will be further clarified by the use of modularised xhtml - but that’s still some way off from being a practical solution.


Website Design For Accessibility: Part 1 | Part 2