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).
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.
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.
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.
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.
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.
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.
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.
- Web Accessibility: PageSpinner 4.6.3: Quirky and Erratic, ATPM 12.11, November 2006.
- Web Accessibility: Nvu: impressive and powerful, ATPM 12.10, October 2006.
- Web Accessibility: RapidWeaver: A Useful Tool in Need of Sharpening, ATPM 12.09, September 2006.
- Web Accessibility: Sandvox: Sand in the Eyes, ATPM 12.08, August 2006.
- Web Accessibility: The Clayton's Web, ATPM 12.07, July 2006.
- Web Accessibility, ATPM 10.01, January 2004.
Also in This Series
- What Browsers Can Do, Part 2 · May 2007
- What Browsers Can Do · April 2007
- The Flip Side of the Coin · March 2007
- SeaMonkey 1.0.6 · December 2006
- PageSpinner 4.6.3: Quirky and Erratic · November 2006
- Nvu: Impressive and Powerful · October 2006
- RapidWeaver: A Useful Tool in Need of Sharpening · September 2006
- Sandvox: Sand in the Eyes · August 2006
- The Clayton’s Web · July 2006
- Complete Archive