Original version at http://www.anybrowser.org/campaign/abdesign.html
Below are some useful tips and links that can help to make your site accessible by all browsers, and better in general. This is not meant to be a complete guide to HTML, just a look at web design from an accessibility point of view. I have tried whenever possible to provide links to sites with more indepth information than what is here- please let me know of any sites that would enhance the usefulness of any of the sections below, or if I have missed any important topics in accessibility.
Remember when reading this page that the advice provided is as general and thorough as possible to make it the most useful to the most readers. When enhancing the accesibility of your site, make sure to consider any special needs of your site, as well as the intended audience and available time and skill. The more you do to make your site accessible, the better, but if you can't follow all the recommendations, at least do what you can to follow those that make sense to your needs.
If you don't know enough HTML to make sense of the advice here, and you're looking to learn, there are plenty of links to excellent HTML guides available from About.Com's HTML section.
In the context of web site design, accessibility is a measure of how easy it is to access, read, and understand the content of a web site. Accessibility is complicated by the fact that a web site is not a published piece of work so much as a living document that can be interpreted in different ways by different browsers and on different platforms. Web sites are not a print medium- although they are most often read in a visual manner, there are many different ways a web page can be experienced, such as via a speech browser or via an indexing robot. A web page is a combination of textual information which is interpreted appropriately by a browser and linked to files of various types, such as graphics, movie clips and sound files.
Since a web page can be interpreted differently by different browsers with different capabilites, and since the language of a web page- HTML, is constantly evolving, accessibility must be considered to make a page usable by as many people as possible. The keys to making your page accessible are graceful degradation, standards compliance, fast loading, and intelligent organization.
Since HTML is continually changing and different browsers support different elements, graceful degradation is the key to making sure that pages are readable and accessible in all browsers. When a browser encounters tags it doesn't understand or can't display, degradation takes place. Whether this degradation will cause some of your page content to be lost to the browser, or whether the content of your page can still be accessed fully is dependent on whether the degradation is graceful.
The HTML standards were written with graceful degradation in mind- new attributes to older tags are safely ignored so that the rest of the tag can still function normally, and new tags are written with alternative display for browsers that don't support them in mind. There are many elements of HTML that can't be displayed or can be turned off in browsers that were written with the knowledge of these elements- such as images, java, and frames. Using the appropriate methods to provide an alternative message to those who can't see those elements or have turned them off is one way to design for graceful degradation.
If you design pages with graceful degradation in mind, by utilizing the built in elements of the HTML standards, and the advice provided here, you can design pages that should degrade gracefully in all browsers and are accessible.
Certain characters are reserved and can not be used in URLs without encoding (in hexadecimal format). Some browsers may handle some of these characters properly anyways, but this does not indicate that these characters are safe to use without encoding in any browser. For example, spaces are special characters that aren't allowed in URLs without encoding them to %20. Internet Explorer users may not catch this problem since it error corrects for this, but Netscape and many other browsers do not, so you should be especially careful to encode these properly. In general, you should avoid the use of characters in your file or path names that may require encoding and you should always encode a character if there is some doubt as to whether it can be placed asis in a URL. As a rule of thumb, any character other than a letter, number, or any of the characters $-_.+!*'(), should be encoded to their hexadecimal equivalents.
URLs (Links) are generally case sensitive. Some web servers may not be case sensitive (this generally only affects a server, not a browser), but it is best if you create all links as if they are case sensitive so that you don't have to change them if you move from one server to another. (The domain part of a URL is not case sensitive, but the rest of it can be).
Although rarely discussed, color issues are very important when designing accessible sites.
If you want to specify one of the colors (BGCOLOR,
TEXT, LINK, VLINK, ALINK), specify them all to ensure a pleasant and readable mix. This is because some users may use different default colors than you expect, so if you don't specify all the colors of a document they may end up with colors which are incompatible to the point of making the document unreadable. Even when using a background image, you should still specify BGCOLOR, because the user may not have image loading on.
It is now recommended that formatting specific settings like colors be set in a style sheet rather than in the HTML itself (note that when setting colors for the BODY you should still set them for all types of text). This will make it less likely that the colors cause a problem for the user and allow a separation of style from content. It will also probably reduce the amount of repetitive tags needed on your pages. Note that it is possible to set colors in both places but care should be taken not to rely on colors set in CSS when setting colors in HTML, so that if the style sheet is not used the user won't end up with an unreadable combination.
Be careful to avoid the use of FONT colors unless necessary, since if the
user has their colors set to override those of the document, they may be
incompatible colors with the FONT color you use and may make the text
unreadable. The FONT tag is also depreciated in newer versions of HTML so if you want to color your text it is better to do that in a style sheet.
Also make sure to only use table BGCOLOR when necessary, both for the reasons
stated above, and because some browsers don't support that feature, so if
the text color is unreadable against the default background color, the text
may become unreadable in a browser that doesn't support table BGCOLOR. Setting the table background colors in a style sheet is the preferred method and less likely to produce unreadable combinations.
When you are specifying colors for your page, use the hexadecimal color codes (such as "#FF0000"), and not the names of the colors (such as "red"), as some browsers don't support all the color names.
When designing pages, you should also keep in mind that some users view in 256 colors or less, and that the color palettes differ on different platforms and browsers, so make sure to keep your pages readable in 256 colors. It is common to design pages which are compatible with the 216 color Netscape color cube which is common between the Mac and Windows versions of Netscape- it won't be perfect, but it's the best approximation avaiable of colors that are unlikely to dither on a 256 color display in most circumstances. Remember also that some users may use grayscale or black and white displays, so graphics which dither badly enough that they are undecipherable should be avoided if you want to maximize your site's readability for all users. There are also issues involved in designing pages for readability by color blind users- see the special needs section for links to sites that can help.
For more information on which colors are safest for use in web pages, see:
It is possible to have a web site without any images, but it's not very common.
In order to make sure your images are fulfilling their goal, it's necessary
to consider the purpose of each image, and make
sure you have provided appropriate ALT attributes for all of them. It's
important that all graphics have ALT attributes because otherwise, the reader of your site won't have any way of knowing if those graphics are
expressing anything they need to know or are simply decorative. For most graphics, substitute text should be used for the ALT attribute (depending on whether the graphic is there to serve a functional purpose or to illustrate something). For bullet graphics, ALT="*" or something similar works best. For horizontal
rule, a dashed line is the most useful ALT attribute. For graphics that
provide no useful content, an ALT attribute should still be supplied- even if all it says is ALT="". If the graphic is supposed to flow within the text, it makes sense to use an ALT with no additional decoration. However,
if you want the ALT to stand out, as may be necessary in cases such as button
links, putting brackets around it, such as ALT="[Table of Contents]" is a good idea. Note that there is also a TITLE attribute which can be used to provide descriptive text associated with an image in addition to the replacement text provided by the required ALT attribute.
For more information on using ALT attributes in images, see the following sites:
If you think there are any graphics that the visitors to your site may want to download, you may want to specify the image size so the visitor knows how big a graphic they're downloading. You may also want to make the graphic a link to itself, so it can be more easily downloaded.
One way to speed page loading when using graphics is to specify
the WIDTH and HEIGHT attributes for each graphic so the browser can
leave space for the graphic and load the text first. Not all browsers do
this, but it gives visitors using those browsers an opportunity
to read the textual content of your page while the graphics are loading. For more information on helping pages load faster, see the bandwidth conservation section.
Note that some browsers display
alternative text for images in a poor fashion- by trying to fit that alternative
text into the space reserved for the graphic by the WIDTH and HEIGHT attributes, and cutting off
whatever text won't fit. This makes it sometimes a difficult decision to use
the WIDTH and HEIGHT attributes. I recommend that they be used anyways in most cases because
it helps the large percentage of users who browse with graphics view your
pages quicker, and most browsers these days will use a popup or some other format to display the alternative text instead, but this is a personal decision, and you should
decide for yourself what fits your needs.
Choosing the appropriate graphic format for your images is important to accessibility and loading speed. The three preferred formats for graphics on the web are GIF, JPEG and PNG. GIF and JPEG are more widely supported, but recently some browsers have been dropping GIF support because of patent concerns. PNG is less well supported but is typically supported in newer browsers and doesn't have the same patent problems that GIF does. GIF images are more suitable for graphics that are smaller and have less colors, whereas JPEG is best for larger, photographic images and graphics with many colors. For more information on the difference between the two formats, see JPEG vs. GIF on the Web Design Group site.
PNG is appropriate for replacing both GIF and JPEG in some cases. Browser support for PNG is now fairly good and may make it appropriate for you to use PNG on your pages, although there are still some browsers that don't support it and some which don't support the full specification (especially alpha channel transparency), so keep that in mind if you're putting important content in images. Also note that PNG does not support animation although there is a new standard called MNG which does, but which isn't yet supported well. PICT, BMP, XBM, and other graphic formats aren't supported in many browsers, and tend only to be supported on particular platforms, so avoid them.
See the color issues section for more information on using colors in your images that will dither gracefully.
Image maps are sometimes useful on web sites, but they can often provide a barrier to access of site content if they aren't supplemented by other modes of navigation. Some web users don't have graphical browsers or browse with autoloading of images turned off, which makes navigation of sites difficult if they depend upon image maps. Search engines in particular can't typically navigate sites with image maps.
Whenever possible, make sure that text navigation links or a textual site map is available to make the entire site available to users without images. Don't forget that using textual navigation or separate graphics may be a viable alternative to using image maps entirely.
Indicate in the ALT text for any image mapped graphic that it is an image map, so that if the user can load the graphic, they can choose to do so. Also
indicate if there is text navigation available so the user can choose not to
bother loading the graphic if they don't need to. ALT="Image Map - use text
links below." is a popular way of indicating how the user should deal with the image.
Map the coordinates 0,0,0,0 in your server side image map to your textual site map or alternate page if you have one. Some browsers (such as Lynx) send those coordinates whenever an image map link is selected.
You can provide both a server side and a client side image map. Although pretty much all browsers support client side maps if they support image maps, there are still some very old browsers which only support server side maps. To use both types of image maps you can include both the ISMAP and USEMAP attributes in the image
which you are using for your image map.
Provide ALT text for both the image itself, and for the links
in the client side map (the AREA tags). Some browsers, such as Lynx, use the
ALT text in the client side map to provide a means of navigating. If you don't provide
ALT text, the user gets a list of URLs instead, which is a lot less helpful.
Animated images can sometimes provide useful information, but more often they just provide decoration to a site. The main issue for making your images useful to those with browsers that don't support animated images is to make sure that the first and last frames of your image (the ones most often displayed by browsers not supporting animated images) are ones that will stand alone in usefulness. You should also consider whether it is really necessary to use animated gifs, as they annoy many users and are not easily stoppable in some browsers, and since they also tend to be much larger than single images.
Common sense tip: Don't use animated images on a page unless you want to draw extra attention to that image or that area of the page. Animated images tend to distract users from other sections of the page and draw their eye to the animation. Many web designers make the mistake of using animations as much as possible, rather than saving animations for specific cases in which attracting the user's eye is the main goal. This diminishes the effectiveness of the animations, as well as bogging down page loading and distracting the user for little useful effect.
If you are aiming for accessibility, it is better to present your content with logical structure than to rely upon layout. If you do need to use some layout for your page, and you find the need to create additional space between items on your page, there are a couple different ways to do it.
The way that will work in the most browsers, is by
using a non-breaking space character- or  . There are some situations
in which this will not work- non-English language character sets may interpret this character
differently, so if you are writing a non-English page, make sure to test non-breaking spaces
before using them in your document. There are also a few old English language
browsers which will also interpret this character as something other than
a blank space.
This approach to creating more space is more flexible than non-breaking spaces, but is
likely to work in fewer browsers, and if automatic image loading is turned off in a browser,
the 1-pixel graphics are often displayed as an image to be loaded, rather than just creating
blank space. In addition, some browsers don't stretch images to fit the suggested HEIGHT and
WIDTH supplied, so your graphic may end up being displayed as just 1 pixel square.
You should avoid using transparent graphics to create space on your page
if a non-breaking space will suffice.
The SPACER tag is a Netscape specific tag, and you should probably not use it if your
spacing is critical to the readability of your document. On the other hand, if a non-breaking
space won't fulfill your needs, and your document will be readable without the space, it may
be preferable to use a SPACER rather than a transparent graphic, since if it doesn't work in
the browser, it will be safely ignored, whereas a transparent graphic can display in an unintended
manner.
Cascading style sheets give you a lot of control over positioning of elements on a page, and by separating layout from content, they do it in a way which shouldn't interfere with readability on browsers which don't support them. If the spacing is not essential to the document, it is a good idea to look into using cascading style sheets to create it, since it won't interfere with the accessibility of your document and is likely to be supported by most browsers over time. To learn more about style sheets, see the style sheets section.
Tables are one of the most useful features of HTML, but they are also commonly used in ways that make pages unreadable to browsers that don't support them. There are two main types of tables- those that are used for page layout purposes, and those that are used to format data.
Tables that are used for layout purposes don't often pose a severe problem to readability, but to be sure, you should check your page in a browser that doesn't have full table support, such as Lynx to make sure it's still readable and logically ordered. It is best to avoid using tables for layout when possible, because their rendering is unpredictable in different browsers, or even in the same browser on different platforms. This means that even though it may layout perfectly when you test it in your browser, it may come out totally different for someone else, which may make the page difficult to read. One other issue to be considered when using tables for layout of pages is that they can often make pages load much more slowly (because most browsers need to read the entire table before rendering it), so definitely make sure tables are the best approach before using them. You may want to look at cascading style sheets as an alternative to tables for layout. They are supported in less browsers, but are less likely to degrade in an unreadable fashion.
If you have tables used for formatting data, you can still make them
readable, but it requires a bit more effort. There are ways to design pages using tables that format data so that they
are still readable in browsers that don't support them, and there
are also other alternatives that should be considered, such as using
preformatted text. Design tabled content
so that if the table tags were removed, the text would still be in logical
order. Put spaces at the end of table cells and breaks at the end of
table rows so that your content line breaks in the appropriate places. Also avoid using ROWSPAN and COLSPAN if possible, since their absence
in a browser that doesn't support tables is likely to confuse readers as to how the columns should
line up.
For more information on designing pages with tables that can be readable by all browsers, see:
Instead of using tables for formatting tabular data, you may be better off using preformatted text. Preformatted text loads faster than tables and should be readable by anyone. Converting an existing table to preformatted text may be as simple as loading your table into your table capable browser and saving it as text. This won't work all the time, but it is often the fastest and easiest way to do it. Make sure to use spaces rather than tabs when creating preformatted text tables, since tab spacing is not the same in all browsers.
Due to the poor implementation of frames in some browsers, non-existent implementation in others, and their poor degradability, it is best that frames only be used if appropriate and necessary.
Frames should only be used if they fill a purpose that can't be adequately addressed by other means, and if care is taken to ensure that the site is still navigable without the use of frames, both for those users who don't have frames capable browsers, and for those who are confused or annoyed by frames. Before deciding to use frames on a site, make sure you have considered the problems they may cause for your users, including difficulty bookmarking pages and back button confusion in older browsers.
For more information on appropriate frames usage, see:
Frames do provide a method of making pages readable by non frames browsers,
by displaying all text between the <NOFRAMES> and </NOFRAMES>
tags only to browsers which don't display the frames themselves. Therefore
you can easily make framed pages readable by non-frames browsers.
Make sure that whatever information is placed on the NOFRAMES sections
is updated with the framed sections. What is done most commonly is that
two entry pages are made, one with frame links, and one with normal links,
and the NOFRAMES section leads readers to the nonframed entry page. It
is also a very good idea to place a link to the nonframed entry page from
the front page in the framed section, so that users who dislike frames can
access the site using the non framed entry page.
Style Sheets can be a valuable method of adding an attractive and standard design to all the pages on your site.
What is particuarly advantageous about style sheets is that they are designed specifically with browsers that don't support them in mind. By separating the design from the content of the page, style sheets allow web site designers to design their pages attractively without making their pages difficult to read in other browsers. The biggest barrier to using style sheets on your site now is that they are not fully supported by all browsers, but since they are designed to not interfere with proper rendering of the page by browsers that don't support them, you can safely use them now on your sites if you like.
See these sites for more information on using style sheets:
Unfortunately, style sheets sheet support varies widely between browsers and there are some which have no style sheet support. Since sites can be designed to take advantage of style sheets without causing problems for non-style-sheet capable browsers, they are worth using, but be careful about using them in a way that can cause content to be unreadable when the style sheet is not loaded. When designing a site using style sheets, it is best to test both in browsers that support style sheets and those that don't, to ensure readability is preserved. Note: Most compatibility issues you'll encounter when using style sheets are in browsers which partially support them (rather than those which gracefully ignore them), so make sure to test carefully and check the online style sheet references.
Cookies are a feature supported by some browsers which allow sites to keep information on the user's computer to be retrieved when the user revisits the site. Cookies are useful for many things, including page personalization, but some browsers don't support them, and many users consider cookies an invasion of privacy and disable them. Think carefully before using cookies, and try not to require their usage to view any of the content of your site, due to the lack of support and the issue of user privacy. In certain cases, such as shopping basket features, cookies may be useful enough to outweigh their problems. If you must use cookies, try to provide some alternate method of performing any tasks on your site that the cookies enable for those who can't or won't use them.
For more information on the usage of cookies, see:
There are many arguments against using javascript on web pages:
Javascript is not supported by all browsers and Javascript implementations vary between browsers, so if you use Javascript, you must make sure it degrades in a useful manner. In addition, Javascript code can sometimes appear on the screen in browsers that don't support it, so make sure you comment the code appropriately so older browsers will be able to ignore it.
Even browsers that support Javascript can encounter problems with it.
If you find it necessary to use Javascript, please take care to make sure that users of non-Javascript and semi-Javascript capable browsers can still access all the content of your site, and make sure to test your Javascript in different versions of Javascript browsers on different platforms to make sure it works as expected and doesn't generate errors or cause crashing.
If you use Javascript on your site for anything that provides content you will need to provide alternative access to that content for non-Javascript users. To do this, you can use the NOSCRIPT tag to encase the alternative content. Browsers with Javascript support will ignore the content inside the NOSCRIPT tag and browsers which don't support Javascript will show the alternative content. Note: It is much better to use the NOSCRIPT tag for alternative Javascript content than to try to guess from the browser name whether Javascript is supported because it may be disabled even if supported in the browser.
If you must use Javascript, make sure to comment your Javascript appropriately so that browsers that don't support Javascript won't display your Javascript code when rendering your page.
Java is a promising technology, but it is still fairly new and is not supported by many browsers, and in addition, many users turn Java off in their Java capable browsers for speed, security, or reliability concerns (some corporate firewalls filter it out too). If you have content on your site that can't be effectively implemented other than by Java, then you should make sure that you use appropriate alternate text for other users and test your applet to make sure it won't crash browsers. Try not to use Java if it's not necessary for presenting your content.
Currently plug-ins are supported by only a few browsers, and the plug-ins that do exist are usually only available for Windows, and only sometimes available for other platforms. Due to this, it is a bad idea to make any of the content of your site only accessible via a plug-in. Even if your visitor has the hardware and browser necessary to run the plug-in, they still must make the effort of downloading the plug-in. Enhancing your site with the use of plug-ins that aren't required to access your content won't keep your site from being accessible, but visitors to your site without the plug-in may be annoyed by the dialog box their browser may display telling them to go download the plug-in.
Although it is popular to design pages targeted for a specific screen size, this is rarely a good idea. Keep in mind that many users may not have a screen big enough to display the whole page (and although vertical scrolling is considered an acceptable solution, horizontal scrolling is almost never a good idea). This is especially an issue for users on specialized devices such as PDAs and television based browsers, although many browsers on small screen devices compensate for this issue by ignoring certain formatting instructions or reformatting the page to fit. It is also an issue for people who prefer to web browse in a window that doesn't take up the entire screen (very common on non-Windows platforms) and for those who set their font sizes higher than normal (especially common with older Internet users who may have difficulty with small default font sizes). If you design your page to be formatted to fit a certain size screen there are a lot of things that can go wrong for your site visitors, even in the most popular browsers.
Whenever possible keep formatting with absolute pixels sizes to a minimum and tend towards use of percentage sizes. Try your page at different window sizes and font sizes so you can catch the most common problems with readability that exact pixel sizing will exhibit. If you must use absolute pixel sizes, assume a large font and a small screen so that your page will work with the largest variety of visitor's environments.
If you distribute files from your web site, you should consider the accessibility of the format they are in.
For text documents, it is best to distribute files in text format- don't distribute a file in a word processor's format unless it is necessary for you to preserve the formatting of the document. Remember that not everyone has access to the same word processor that you do. If you must preserve the formatting, make sure that the format you distribute your document in is likely to be available to your target audience. Adobe Acrobat format (PDF) is available to most users, so if you must preserve formatting, distributing documents in PDF is probably the easiest and most commonly readable way.
If you are distributing compressed files, make sure to choose the format that makes the most sense to your users. If your files are likely to be used by people on multiple platforms, it is probably best to either distribute it in multiple formats, or to choose a format that you know those multiple platforms all can read files in, and provide pointers for downloading the appropriate software. Zip is probably the best format if you know you will have users from all platforms and can only provide your file in one format, since software is available for reading it on more platforms than any other format that I know of.
If you are distributing files that are likely to be only used by a specific platform, it is best to use the compression format which is most widely used on that platform, for example: .sit files for the Mac, .zip files for Windows, and .tar, .gz, or .Z files for UNIX.
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:
When writing to an HTML standard, make sure to pick the one most appropriate to your needs. If you don't need any extended features, or expect to have a lot of visitors with very old browsers, you may want to stick to HTML 2.0 compliance. Most currently updated browsers have support for HTML 3.2, so it is generally the best to use if you want to use features not in HTML 2.0 (don't forget to plan for graceful degradation). If you need some of the newest features of HTML, like frames, HTML 4.0 is what you should use, but remember that most browsers do not support most of the new features included in HTML 4.0 yet, and you should setup your pages to degrade gracefully.
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 Netscape 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.
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).
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 HEIGHT and
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,
see:
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 are some sites 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:
It is very common for people designing web sites to forget locality issues that are important when dealing with the World Wide Web.
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:
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:
One of the most important things about designing a web site is using the right tools. You can make a website with many different types of tools, but if want to make your website accessible to all browsers, it's very important to use tools which help you, rather than interfere with your work. Here are some tools that you may find useful in accessible web design.
When it comes to designing web sites for accessibility, it is almost always best to use a text-based editor rather than a graphical editor. There are cases in which a graphical editor may be necessary, but if you can use a text-based editor, you have a lot more control over the accessibility of your site.
When selecting a graphical editor, take care to select one which does a good job of creating accessible sites. In general, graphical editors tend to be fairly bad at this, mainly due to their focus on hacks to achieve specific presentation in the more popular browsers and their removal of control from the creator of the page. Be especially cautious to choose an editor which doesn't rewrite your code without your permission (FrontPage for example is a major culprit for this), that creates pages based on standards (and preferably allows you to specify which standards you are targetting), and that allows you to take advantage of the standard accessibility features of HTML, such as ALT and NOFRAMES.
Do not assume that an editor will create accessible code just because it is creating HTML code automatically. Make sure to run your pages through a validator at least the first times even if the program has a built in checker, since the checker that is built in may not be thorough, and you can't really tell without running a comparison check. Also, I recommend against using the graphical editors distributed by the major browser vendors (Netscape's Composer and Microsoft's FrontPage) as they tend to have a bias towards coding for their own browser. If you can give me some information on which tools are good and which should be avoided, please let me know. If you must use a graphical editor which produces poor HTML, I highly recommend using HTML Tidy to clean it up before posting or editing it by hand.
"Amaya is the name of W3C's own test-bed browser/authoring tool and is used to demonstrate and test many of the new developments in Web protocols and data formats. Given the very fast moving nature of Web technology, Amaya has a central role to play. It is versatile and extensible - new features can be easily added - and is available on both Unix and Windows '95/NT platforms. Amaya is a complete web browsing and authoring environment and comes equipped with a WYSIWYG style of interface, similar to that of the most popular commercial browsers. With such an interface, users do not need to know the HTML or CSS languages."
Adobe GoLive is a complete web design tool and site management package. Some of the features which make it useful for accessible site design are: the ability to target for specified HTML or browser versions, the fairly clean and valid code it generally produces, the HTML checker, the included scripts (for Javascript and DHTML) which are designed to degrade appropriately and work in multiple browser versions, and the quality text editor included (and the ability to also work in the editor of your choice).
Dreamweaver is a graphical editor which also includes site management features, and first class text editors (HomeSite/BBEdit) appropriate for each platform it's available for. It won't change your HTML unless you ask it to.
Text-based editors are generally best for making accessible sites, because they give you a lot more control over the code they use. In a text-based editor, a web site is as accessible as you make it. Some editors provide functionality which make it easier to produce or test for accessibility. Here are a few. If you know of an editor which provides features which make it good for accessible site design, please contact me and let me know.
BBEdit is a basic text editor with powerful features and a full suite of HTML tools. It has a robust plug-in architecture, with many useful web design plugins available, multi-file search and replace (with regular expression support), and many other useful features. The lite version is free, the pro version comes with more useful plugins, an HTML checker, link checker, HTML aware spell checker, and other useful features.
As you type, HotDog provides continual feedback on the HTML code you are using. This feedback takes the form of tool tips which explain what each tag and attribute does.
Unfortunately the several different browsers on the market each conform to different HTML standards. While all browsers support the bulk of the HTML language, they all add extra functionality of their own. For example, Netscape has Netscape Extensions and Microsoft have their own extensions as well.
A professional web designer has to make sure their web page looks great under any browser. The only way they can insure this is by knowing which browsers support the different tags and attributes they are using. HotDog has many ways of giving the user this information on the fly. Holding down the CTRL key and moving the mouse over any tag or attribute reveals for what HTML specification the tag or attribute is defined.
A key part of HotDog's ability to provide this syntax information to users is the HTML Property Sheet. The HTML Property Sheet is a panel that sits next your document in HotDog. This panel lists all the known attributes for the tag you are editing. This list of attributes is usually ordered by what browsers support them.
For example, as soon as you type <TABLE> in HotDog, the HTML Property Sheets has listed all the attributes that can be used with the Table tag, and it has listed the attributes by which browsers support them. This enables professional web designers to make informed choices about the HTML they are creating.
The Syntax Manager can be told to only recognize any HTML specification you choose, in particular, the HTML 3.2 specification which nearly all browsers support in its entirety. By using the HTML 3.2 specification only you can be sure your are using HTML code that any browser can display. This would mean that as soon as type a tag or attribute that is not part of the HTML 3.2 specification, it would be colored red to indicate that it might not be recognized by some browsers.
HomeSite is a full fledged web design tool with many useful features, including web page validation.
NoteTab Pro is a leading-edge text editor and HTML coding tool, and an ideal Notepad replacement. Winner of top shareware industry awards since 1998, this elegant application does it all: you can handle multiple large files with a simple tabbed interface, use a spell-checker and thesaurus, format text, use multiple undo, and bookmark documents. You can build templates, use powerful system-wide searches, and do global multi-line replacements.
Its Clipbook feature lets you create and organize clips, which can range from text macros to complete mini-applications, using a simple scripting language with enough features to satisfy any power user; a bunch of handy clip libraries is included.
Web authors will love the HTML clip library, just one of a load of features that make NoteTab a great code-based HTML editor. Other gems include text-to-HTML conversion, tag stripping, and tools for adding links and color codes.
Arachnophilia's purpose is to create Web pages. It does this in one of two general ways. The easy way is to drop a Rich Text Format (RTF) document onto the Arachnophilia program window and watch Arachnophilia turn it into a web page for you. The not so easy way is to write the HTML code yourself, which, although more work, produces the most professional-looking results. Arachnophilia will help you create Web pages, no matter what method you choose. And, by just typing, you can create new Arachnophilia commands, even entire toolbars, for HTML tags the author hasn't thought of -- Arachnophilia's suite of commands is entirely under your control. You can load hundreds of documents at once (memory permitting) and search through them at once for particular words. You can preview your work on up to six browsers, thus assuring your pages will look good no matter what browser your visitors own.
Site management tools, such as preprocessors and server side scripting, can help a great deal in making accessible sites (and just in general). For instance, if you want to provide two versions of a site, you can manually maintain both versions, which can lead to a lot of errors or with one section of the site not being updated regularly, or you can automate the process, and make it easy to update repeated sections of text, toolbars, etc. throughout the entire site.
Using a preprocessor allows you to automate the information in your pages with macros and variables, and allows you to publish a version of your site with those macros and variables replaced with the appropriate HTML code so that no server plugin or script is required to access the information. The advantages to this approach over server side scripting are that pages load faster, since no additional work is required by the server, and no special server software is required, so you can use a preprocessor regardless of your server setup. The disadvantages to this approach are that you can't use some dynamic information in your macros that you can with server side plugins/scripts, such as the date the visitor is viewing the page, code which only shows to viewers at certain sites, etc, and that maintaining two versions of your pages could get you into trouble in case you edit the published version instead of the pre-published version.
Server side plugins and scripts allow you to embed macros, variables, and dynamic information in your HTML pages that will be evaluated as the pages are being served to your visitors. The advantages of this approach are that you can use dynamic information on your pages, such as the current time, the browser the visitor is using, etc., and that there is only one verison of your pages to maintain. The disadvantages are that you need to have support on your server for the script or plugin you are using, there can be security problems with software of this type, and the additional processing the server must do can slow the loading of your pages.
Whether you should use a preprocessor, a server side plugin/script, or some combination of the two is dependent upon the needs of your site. Many tools can function both as preprocessors and as server side plugins or scripts. Some site management tools which may be worth looking at are:
Interaction is a Mac web server companion that makes web sites dynamic social places that adapt to the visitor. It support XML and style sheets, which are processed into HTML at serving time. Services such as threaded forums and chat rooms comes as optional components to the application, and are designed to work with all standard browsers included WebTV and text-only browsers.
XPublish is the first web publishing system for Mac that is based on XML. It supports a website that is published using extensible markup or XML-extended HTML. The application processes XML into standard HTML at publishing time based on Cascading Style Sheets. This offers many of the advantages of one-source publishing, but without the overhead, expense and complexity of an SGML system. XPublish makes publishing of middle-sized and large websites more efficient and flexible, allowing the same content to be published in many formats without manual recoding for optimal accessibility.
Cascade is the first comprehensive Cascading Style Sheets editor. It is used to design the look & feel of websites. Cascading Style Sheets (CSS) offers many advantages for more accessible web pages, included that the presentation can be modified to the preferences of the reader or automatically adapted to various displays or media. Cascade has the ability to emulate CSS so that parts of the design also can take effect for older browsers that doesn't support style sheets.
There are quite a few cross platform preprocessors, such as make, htmlpp, and others, and server side scripts/plugins such as PHP and Livewire available as well.
Testing your web site for errors is very important. The two most common types of HTML testers are validators and linters. The main difference between a validator and a linter is that a validator checks a page against a published HTML specification for technical errors, whereas a linter checks a page for commonly made mistakes. It is often a good idea to use both as they can sometimes find different types of problems.
Validators and/or linters are included with quite a few good quality HTML editors, including Bare Bones Software's BBEdit Pro, Allaire's HomeSite, and Sausage Software's HotDog. If your software doesn't include a validator or at least some sort of HTML checker, it is a very good idea to find one to use. Don't assume that your editor creates valid code. This is very often not the case. Simply testing your pages in your favorite browser or even a couple browsers won't really tell you if you've got some sort of error in your pages that may not be corrected for in another browser, or in a new version of your current browser (i.e. Netscape 4 no longer allows you to forget ; in entities, like ©). There are quite a few validators and linters listed at Yahoo. In addition, here are a couple of the more useful web based ones:
When creating image maps for web sites, there are special accessibility issues that should be considered. Often there is a way to avoid the need for an image map, but if you do need to use them on your site, then you should make sure to use a tool which will make your image maps more accessible. First of all, make sure you're using an image map editor which will allow you to add ALT attributes to your AREA tags, since this is required in HTML 3.2 and up, and will allow some browsers to navigate your image map without graphics in this manner. In addition, some image map editors have additional functionality, such as generating a text toolbar for the page based upon the image map links to be used for greater accessibility. If you know of an image mapping tool or other program that is good for making accessible sites, please let me know.
MapEdit is imagemap editing software. MapEdit is a graphical editor that allows the user to make clickable imagemaps for the World Wide Web. MapEdit allows you to load your image into a scrollable, resizable window and then draw polygons, circles and rectangles on top of it, specifiying a URL for each. It also allows you to go back and delete these hotspots, set a default URL for clicks outside the hot area and allows you to associate comments or alternate text to be show to users of non-graphical browsers. With Mapedit 2.63 and the latest web browsers, you can use client-side imagemaps, which reside in your HTML page. Mapedit will also create server-side maps for backwards compatibility with old browsers.
Campaign | Graphics & Slogans | FAQ | Example Letters | Feedback | Links | Forum