Skip to Content
Skip to Table of Contents

← Previous Article Next Article →

ATPM 12.12
December 2006


How To



Download ATPM 12.12

Choose a format:

Web Accessibility

by Miraz Jordan,

SeaMonkey 1.0.6

A couple of issues ago, I looked at Nvu and considered it a likely candidate for an application that can allow ordinary users to create Web sites that meet at least a bare minimum of accessibility requirements.

This month, I looked at SeaMonkey, though with a little hesitation, as it is a cousin of Nvu. In times past, the Netscape browser, which included the Composer component for making Web pages, turned into the Mozilla Project. In turn, the Mozilla Project has brought several Web-related pieces of software to the public: Firefox and Thunderbird are well-known; SeaMonkey is another.

Both SeaMonkey and Nvu were based on the Mozilla Composer code base, but they have been developed separately. They have a lot in common, but it turns out they aren’t quite identical.


SeaMonkey is free, open-source software. It requires Mac OS X 10.2 or later, 64 MB RAM (256 MB recommended), and 100 MB of free hard disk space (significantly less space is required if you reduce the cache size).

Getting Started

As usual, I started up the application and added a few headings, paragraphs and a list, and a photo—the fundamental features of most Web pages.

While the application opens with the browser component, you can open the Composer by choosing New from the File menu. You can change the Preferences to open the Composer on startup, if you wish.

It was a simple matter to type my text in to the Normal view. On saving, a sheet appeared asking me to enter a Title for the page.

It was easy to turn my list into a real HTML list, and my headings into HTML headings using the standard toolbar buttons.

Semantic Markup

The modern, accessible Web demands what’s known as semantic markup. Semantic markup classifies everything on a Web page: this is a paragraph, this is a heading, that is a list. Such classification allows software tools, such as screen readers for visually impaired people or search engines, to “understand,” navigate, and summarize a page.

Style Traps

In addition, modern techniques for creating Web pages involve applying styles to text (and other elements) via style sheets. In order to achieve consistent results with a style sheet, it’s important to use consistent markup in the HTML.

One common “trap” is to leave some text on a page without any specific markup, beyond being contained within the <body> tag and therefore classified, by default, as “body text.” If the writer intends it to be “paragraph” text, and doesn’t notice that the <p> tags are missing, then there may be a lot of troubleshooting to discover why one chunk of text looks different from the rest.

Body Text

Unfortunately, because I hadn’t set the style first from the pop-up menu, much of the text was simply body text, divided by line breaks, rather than paragraph tags.

It stands to reason that most of the text on an ordinary page will be paragraphs; I believe that paragraph text should be a default on Web-page software.

The good news was that I was able to select whole chunks of “body text” and style them as paragraphs from the pop-up. SeaMonkey did more or less the right thing: it removed the <br> tags and replaced them with correct <p> tags, except where I’d left empty lines between paragraphs. There, SeaMonkey correctly marked up paragraphs, but included <br> tags inside them to indicate the empty lines.

On reflection, I guess this is fair enough—by pressing Return twice between paragraphs I was indicating that I wanted a blank line—though it may be time for me to change my typing habits.

Alternate Text

As with Nvu, it was hard not to supply alternate text for an image. A warning appears if you attempt to close the dialog box without either entering alternate text or deliberately choosing none. If you choose none, then SeaMonkey correctly inserts an empty alt attribute.

A strange thing happened, though, when I inserted my image. I’d quickly exported an image from iPhoto. I created a JPEG, 450×300 pixels and weighing in at about 70K. That’s a bit big for a real Web page, but for my purposes it was fine.

After adding the image to my page, SeaMonkey Composer showed only an empty rectangle, with the alt text I’d supplied. I validated the page, checked the code by eye, removed and reinserted the image, reduced the image file size, checked the settings, and tried a different image. SeaMonkey Composer simply refused to display the image. On viewing the page in SeaMonkey Navigator (the Web browser component), there was my image, as it should have been.

A bit of searching didn’t turn up anyone else mentioning this problem, so I guess it was something about my setup. I was working on a backup machine and wasn’t able to engage in extended troubleshooting.

Even more curiously, while writing the above paragraph, I decided I didn’t care so much for the overall look of SeaMonkey and decided to switch to the Modern theme. After restarting the application, with the new theme, my images displayed perfectly in the Composer.


The page SeaMonkey created used an ISO-8859-1 character set. While this isn’t my preferred option, it’s perfectly acceptable and common. I was able to edit the HTML source to replace it with UTF-8. Another method was under the File menu: Save and Change Character Encoding, or from the View ‣ Character Encoding submenu. It doesn’t seem possible, though, to define the default character set in Preferences.

Separate Presentation and Content

A key element of accessibility is to separate presentation and content. The HTML file will specify headings, for example, but should not carry the information about how headings will be displayed. Instead, a separate stylesheet may specify that a heading should be green, Georgia, large, bold, with a border.


While an HTML doctype certainly doesn’t prevent anyone from removing fonts, colors, and the like to a separate stylesheet, it still allows users to include <font> tags. A Strict XHTML doctype does not allow such presentational markup, though a Transitional XHTML doctype does.

The doctype SeaMonkey used was HTML 4.01 Transitional. This is acceptable, but many people, including me, use an XHTML doctype these days—it’s been a W3C recommendation since January 2000.

I tried very hard to change the doctype to my preferred XHTML, but was unable to find any preference or setting to allow me to do that. That is simply unacceptable.

Miscellaneous Tools

The Tools menu begins with a Validate HTML item. This takes you to the W3C site, where you can upload the file you’re working on and check it.

A handy tool is the Export to Text item under the File menu, which does just what it says.

My Conclusion

SeaMonkey is very similar to Nvu, but not exactly the same. If you’re happy to code to an HTML 4 doctype, this software will allow you to create accessible pages—without too much effort. If you require or prefer an XHTML doctype, then this software is simply not for you.

Useful Links

Related Articles

Also in This Series

Reader Comments (3)

michael mckee · December 2, 2006 - 15:11 EST #1
I've set a couple of clients up with Seamonkey or Mozilla to edit their existing web sites. In this regard it is a sort of a free Adobe Contribute Lite. While Nvu has extended the basic Composer tools that Seamonkey offers, Seamonkey has the wonderful feature of allowing the user to browse to a page in a normal browser then edit it. (File menu->Edit or Cmd E). Once the connection settings are entered and a folder dedicated to saving the site files, Seamonkey makes editing existing pages as easy and intuitive as possible. As a site creation tool Seamonkey is quite limited. As an updating tool it is quite handy.
Rick L · December 2, 2006 - 21:27 EST #2
In general, would you say that non-experts would do better to stick with Nvu as a general-purpose website creation tool?
J.D. · May 16, 2008 - 07:43 EST #3
You can change the doctype manually by editing the source. Just click the 'HTML Source' tab, and change the doctype to: !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" (or whatever you prefer). See this list at the W3 site for valid doctype options.

It seems you were successful using this method to change character encoding to UTF-8.

Add A Comment

 E-mail me new comments on this article