If you would like to make your web pages usable by everyone, it is important that you emphasize standards compliance. By complying with existing standards, rather than relying upon browser specific extensions and hacks, you can make sure that the web sites you design will be readable by all browsers supporting those standards, not just the ones you have time to test it on, and that your page designs won't break when new browsers and versions come into existence. HTML tags that go through the standards process are evaluated more thoroughly and designed for graceful degradation on older browsers.
The World Wide Web Consortium (W3C) is the focal point for web standards- see their pages (and some other useful resources) for more details:
- W3C - The World Wide Web Consortium (Information on current and proposed HTML specifications)
- XHTML 1.0
- HTML 4.0.1
- Web Design Group - Standards for HTML Authoring for the World Wide Web
- The WDVL: HTML Standards Compliance - Why Bother?
When writing to an HTML standard, make sure to pick the one most appropriate to your needs (don't forget to plan for graceful degradation).
In order to make pages that are viewable by all, it is very important that you test and validate your pages.
Nobody has time to test pages in all the browsers that are out there, but by making sure your HTML doesn't have mistakes in it, you can make sure that no browsers will choke on errors in your HTML. Browsers are fault tolerant by design, but to different degrees, and so while one browser may recover from errors in your pages without you noticing a difference, those same errors may cause another browser to render a page with noticable problems. One excellent example of this is what happened when Netscape 2.0 came out. Previous versions of Netscape allowed you to skip a matching quote in a link with no ill effects, but when Netscape 2.0 came out, it was more strict, and wouldn't close the link till it found the next quote. A lot of people had to go hunting through their many HTML pages for missing quotes and fix them when this happened (me included :). So make sure to validate your pages as you're writing them so you don't have to go back and fix them later.
There are many excellent validators available on the Internet. Some are available for download and are platform specific, while others have web based interfaces, such as:
For more information about the value of validating web pages, see:
A linter is another method of checking for errors on a web page. Unlike a validator, a linter doesn't check specifically against a published set of rules for HTML. Instead, it looks for common mistakes (and sometimes just poor formatting that isn't necessarily technically wrong) and points them out, such as missing ALT text, no HEIGHT and WIDTH tags on images, etc. Since linters and validators look for different types of errors on a web page, it's very often a good idea to use them both. Most of the web based validators also have the option of including results from Weblint, probably the most popular linter. For more information about Weblint, which is written in Perl and runs on most platforms which have Perl support, see:
In addition to validating your pages, it is also a good idea to test in a representative selection of browsers to see if there are any problems with your pages that you didn't catch in the validation process. It is a good idea to test in Firefox and/or Internet Explorer since those browsers are used by a sizeable portion of the Internet. In addition, you should also test in a text-only browser, like Lynx, and you should probably also select another browser for testing. Testing on multiple platforms, browser versions, color depths, and resolutions is also a good way to find problems that you may otherwise miss.
Testing pages generated by scripts, macro processing utilites, or other such programs can be more difficult than everyday testing. But it's important that you make the effort to write valid HTML when scripting pages- especially since if people come across errors, it won't just be the page you'll need to trace the problem in, but a specific instance of the page. It's also difficult if you're working with scripts provided for free or programmed by others for you, since you often can't rely that they'll write valid code and you may not be familiar enough with the script to fix it yourself.
Work With a Template
If at all possible, write your scripts to work with a template of the results page or have the person writing them do so. If you can set it up so that most of the HTML code in the resulting pages come from an HTML template than the script, it makes it easier to modify and test, and separates the look of the page from the information generated by the script. If you have template pages, you can validate the HTML in them, and just keep an eye on the bits of HTML actually generated by the script.
Since you generally can't validate your code directly on your script, you need to use your script to generate a page, and then view the source using your browser's view source command. Use this source page to run a validator on, or save it onto your server in a testing directory somewhere and use one of the online validators. This will often be enough to catch most or all the errors in a page. Then you need to go back to the script and find those errors and fix them. If you don't have the script, or don't understand it, you may need to enlist the help of the person who created it. If this is not possible for some reason, then at the very least you should prioritize the errors you find and make sure that any which are really bad at least get fixed. It's generally better to make sure in advance that whoever is creating your script understands your requirements and validates themselves, but often it's not possible. This doesn't mean you should give up completely on an accessible script generated page, but it often means you don't end up fixing all the errors you'd like to.
If the script generates multiple different pages, make sure that you view source on enough test cases to test the pages people are likely to receive, including the error page(s).
Modules or Other Automated HTML Producers
One of the biggest problems I've seen in terms of errors in the HTML of CGI generated pages is that they use modules to create the HTML code that often create severely invalid code. This is essentially the same as using a WYSIWYG editor in that it's often more pain to fix than it's worth. If you use modules to generate your HTML code, try to check it out first and make sure it creates valid code. If it doesn't, you should probably find one that does or rely upon templates or direct output of HTML. If the validity of your output isn't terribly important to you, the ease the module provides may be worthwhile, but make sure you're comfortable with the likely results.
Bandwidth conservation is important in making your sites usable by everyone because sites that are slow to load can discourage visitors to your site. In general, it's a good idea for all sites to do their best to limit the size of downloads required to view their pages, both to improve your site, and to keep from overtaxing the net as a whole. Most visitors to sites connect over modems, which aren't fast enough to allow for quick loading of most pages, and some users, especially ones outside of the US, pay for their time online or their local calls, which means that the more downloading they have to do, the less likely they'll stick around.
Many site designers don't realize that there are many ways to reduce the size
of their graphics significantly. Using JPEGs instead of GIFs in appropriate
cases, reducing the colors used in GIFs, optimizing animated GIFs for size, and
substituting text for graphics where appropriate are all effective ways of
helping your site load more quickly. In addition, providing the
WIDTH attributes whenever using images can allow the browser to leave room for the
graphics and load the text first. Note also that setting width and height that are smaller than the graphic won't actually save any download time since the entire graphic must still be loaded. To shrink an image you should actually resize it in a graphical editor. For more details on bandwidth conservation,
- Bandwidth Conservation Society
- Optimizing Web Graphics - webreference.com
- CSS Formatter and Optimizer
Although designing sites for all browsers can be accomplished without knowing all the details about different browsers and what they support, it is sometimes helpful to know details on which browsers support various features, and to what extent. Below is a site that can help you track down the information you may want to know:
Many users of the web have special needs that should be considered when designing web sites. Designing sites that are accessible by all browsers is a good step towards making your site usable by everyone, but you may want to check into ways to make your pages more easily accessible by visitors with visual impairments and other special needs:
- W3C Web Accessibility Initiative
- Designing More Usable Web Sites
- An Introduction to Speech-Access Realities for Interested Sighted Internauts
- Safe Web Colors for colour-deficient vision
- Designing Web Pages that are Color-Blind Friendly
- Vischeck (simulates color blind vision)
- 10 basic tests to check your website for accessibility
- Section 508 Accessibility Checker
It is very common for people designing web sites to forget locality issues that are important when dealing with the World Wide Web.
Date and Time, Location, and Currency
Some of the most common problems with world wide understandability of web pages have to do with information relating to date, time, location and currency. There are many different date formats in use throughout the world, so choosing one that is clear to all people is important. Specifying time zone information for time critical information on a web page is also necessary to avoid confusion. Location information should be complete, rather than relying upon abbreviations that may only be understood locally, or skipping vital context such as country names. Currency such as dollars, which are used by multiple countries with different values, should specify which type.
For more information on avoiding confusion over such information, see:
Non-English and Multiple Language Pages
If you would like to make your site readable in lanugages other than English, there are many issues involved, such as which character sets to use and whether language negotiation is appropriate for your site. For more information, see:
> Next Section (Accessible Design Tools)