There’s plenty of software out there for making websites. What this series of articles aims to do is to explore whether popular tools are able to make pages that meet the basic standards for web accessibility. Refer to the previous articles in this series for more background information. First published September 2006. Some details may be a bit dated.]
RapidWeaver costs US$39.95. A free demo is available. Mac OS X 10.3.9 is required.
I started up the demo version and created a new Styled Text page, pasting some prepared text into the Edit tab. I then dragged in a photo from Photo Booth, using the iMedia Browser. On selecting the photo and calling up the Media Inspector I was easily able to add alternate text.
To create a link I selected the text, clicked the Link button and entered an URL. It was easy to name the page by double-clicking on the ‘Untitled Page’ item in the list of pages. It was also easy to correctly mark up headings (down to level 4) by making choices from the HTML subsection of the Format menu.
I could find no way to correctly mark up a list, except by choosing the page type called HTML Code. It was impossible for most pages.
When I examined the coding for the newly created page I could see that the name I entered had been placed in the Title portion of the head. This is an excellent start.
Pages are created using an XHTML Strict Doctype. This is also an excellent feature. Although I chose the first ‘theme’ in the list, I checked a few others at random, and all seemed to use the same Doctype.
I was disappointed to find that my pasted text had been automatically marked up, not as paragraphs, with
p tags, but with line breaks. It would be a sensible default for RapidWeaver to assume that pasted text is paragraphs and to mark it up with p tags.
Where I’d chosen a heading it was marked up with appropriate
h tags. I attempted to change the font for a few words and RapidWeaver very sensibly applied a span with an inline style. This is miles better than old-fashioned font tag soup.
Line Breaks vs Paragraphs
We have to remember that the coding behind the scenes is crucial for those who don’t look at a web page, but instead listen to it or read it by touch on a Braille display. While software such as JAWS is designed for blind users and has many sophisticated features, any Mac user can get a quick idea of how a page sounds by using their computer’s built-in software.
As an experiment, create a web page with a couple of short lines of text. Add a break tag between them. Then duplicate the two lines, this time marking up them up with paragraph tags.
Now display the page in Safari, turn up your computer’s volume, select all the text and use the Speech submenu from Services to listen to the page.
You will clearly hear that the text separated only by break tags is spoken as one continuous item, while that marked up as paragraphs has a clear pause between each paragraph. Now imagine you’re a blind visitor listening to a whole breathless page broken only by line breaks, and lacking the clear delimiter of the paragraph tag.
We need to recognise that a line break is simply a way to achieve a visual effect, while the paragraph is the fundation of most pages. It should be usual for paragraph tags to be applied to otherwise unmarked text.
Most people want some WYSIWYG software to make web pages for them, which is why it’s so important that the tool help users rather than hinder them.
Of the software I’ve looked at so far (iWeb and Sandvox were the subjects of previous articles) RapidWeaver certainly does the best job, but it too has its oddities.
Rapidweaver gives the user three ‘Views’ of their work:
- The Code view displays the HTML behind the page, but you can’t edit the code. It does however provide a checkbox to ‘Display tidied code’ that will attempt to fix incorrect HTML and report errors. This is a very useful feature.
- The Edit view is where you paste or type text, make edits, select text and apply formatting such as
Heading 1, or
Paragraph, and drag in images. In this view text was marked with a green highlight when I applied formatting, links turned blue with an underline and pictures were displayed, but it didn’t display as a web page would.
- The Preview view displays what you can expect to see on your web page, with the chosen theme applied, along with layout and any graphic elements included with the theme, such as lines and party balloons.
I found the Edit view confusing and unnecessary — why not just have Code and Preview views, available side by side and both editable? While irritating, that doesn’t affect the accessibility of output, but it does introduce clumsiness and confusion.
With RapidWeaver each page has an underlying style, such as Styled Text, Movie Album, Photo Album. If you choose one of these styles then there are some limited formatting options you can apply to text in the Edit tab.
HTML Code Page Style
There is one page style called HTML Code that allows you to add your own HTML code in the Edit view. In this one page style you can use any HTML code you need, easily applying markup from the Quick Insert pop-up menu or typing in the tags you need.
The Quick Insert menu does include the list code I wanted earlier, but not the all-important heading markup.
On HTML Code pages you can’t apply markup from the Format menu, where heading markup was available for other page styles.
In all my years of making web pages I have perhaps once used the
strike tag to apply the strikethrough style to text. I use heading and list tags many times per day.
RapidWeaver lets me easily apply the
strike tag by placing it in prominent positions on two separate menus (the Format menu and the Quick Insert menu), but prevents me from easily applying headings if I’m using an HTML Code page and from applying lists if I’m using one of the other page styles.
This is downright odd, random even, and suggests that the software’s creators don’t have a firm grasp on the principles of HTML.
Why does RapidWeaver provide a menu for headings only down to level 4, rather than all the way down to level 6? Even though levels 5 and 6 must be seldom applied, they are still a legitimate part of the HTML specification.
Similarly, although such old-fashioned formatting as Bold, Italic and Underline appear at the top of the menu, where they are easiest to reach and suggest themselves as desirable, there is simply no way on most pages to apply a list. If you need a list then you will have to use an HTML Code style of page.
On the other hand, in my test, applying Bold or Italic actually applies strong and emphasis tags. This confusion of ‘strong’ and bold afflicts many people.
Strong is not Bold
For black and white printed material we use bold type for at least three different functions. Bold can mark out a heading. It can also mark out distinctive text, such as a place name. Another function is to convey emphasis — the domain of the ‘strong’ tag.
If we have more options for printed text, we may use color or some other characteristic instead of bold for headings and place names. And if we’re reading aloud, we don’t stress a heading or a place name, only words that require emphasis.
Screen reader software alters the voice to add emphasis when it encounters a ‘strong’ tag. Do we really want visitors who listen to our pages to hear a sing-song rendition, emphasising every book title or placename because we coded it as ‘strong’ rather than ‘different’?
Because of all these different uses ‘bold’ has been abandoned as a useful tag for web pages. What we need are tags that reflect the meaning of the text. Because ‘bold’ can mean ‘heading’, ‘distinctive’ or ’emphasised’ it shouldn’t be given prominence in a menu, nor should it just apply ‘strong’ in the background.
It would be far better if the menu label read ‘strong’, so then you know what you’re getting. And of course, the same applies to the ‘italic’ item that currently hides an ’em’ tag.
Place names and book titles should be marked up with a class with an appropriate name (such as ‘book’, or ‘place’) and the stylesheet should then format that class. Only text which is truly to be emphasised should be marked up with a ‘strong’ or ’em’ tag.
RapidWeaver does quite well, as far as it goes. The interface is a little confused and confusing. The menu items offer an almost random assemblage of HTML coding: I can easily choose to strike through text or mark a subscript or superscript — all tags I have very very rarely used, while I cannot apply a list — something I use almost any time I create a page.
The coding behind the scenes is of a high standard, though not always entirely appropriate, and I can’t edit the HTML unless my page is of the HTML Code type.
Of the software I’ve explored so far, this is the best. It’s a useful tool for an ordinary person wanting to put together a good web page, but it is somewhat clumsy and rather blunt.
While not entirely fostering accessible web pages it doesn’t hinder them either as some of the other software has done. On balance, it is on the positive side and could be a good starting point. If the creators were to sharpen up the software from a good grounding in web standards and how to use HTML correctly, this is a product I could encourage others to use.
For the moment it’s a good start, and a better product than many.
- JAWS for Windows screen reader software.
- ScreenCastsOnline, free video tutorials for using RapidWeaver and its plugins.
- Quick Tips to Make Accessible Web Sites, Web Accessibility Initiative.
This article was first published in About This Particular Macintosh in September 2006 and may have been modified from the original.