Category Archives: Geek

I became a geek by accident. I was a groupie for ages and then it just kind of rubbed off on me.

WYSIWYG Editor Accessibility Test Results:

Allowing writers to contribute to the creation of accessible documents.


The testing was based on the needs of non-technical content contributors; writers, graphic artists, editors, etc. The program had to shield the user from all the code and provide a simple usable interface.

It is reasonable to expect writers to be able to update documents and follow preexisting styles without substantially compromising accessibility. However, they won’t be able to create or change the overall look and feel of the documents. This type of change requires familiarity with CSS and XHTML, even in the WYSIWYG (What You See Is What You Get) environment. With proper planning, this limitation can actually help insure consistency across large documents.

Determining whether or not a document is accessible is, at best, vague.  Tools for testing accessibility, such as Watchfire’s Bobby, give technical results that must interpreted by someone familiar with Section 508 guidelines and XHTML.  A combination of TIDY, Validation, and Bobby may be appropriate for testing writers deliverables.  Additionally, the writers may need training to understand accessibility issues.  A computer program, no matter how thorough, cannot determine if alt text is appropriate to describe the function or effect of an image.

Five Editorswere able to complete most or all of the tests. Contribute, Dreamweaver, and Amaya produced the most accessible markup. GoLive and FrontPage failed to request alt attributes for images, the most basic accessibility test, and the markup produced by FrontPage [1] didn’t validate.  Three Editors were immediately eliminated.  XStandard did not pass the easy tests.  Authentic and HTML Kit are not WYSIWYG editors.

Amaya’s strengths are that it always produces valid markup and it’s relatively simple user in terface would be easier to learn.  However, it is a quirky program, it crashes often forcing one to save work frequently, and its interface is unpolished and can be frustrating to work with.  It is awkward, and sometimes requires redundant clicking to perform operations.

Contribute, by the same company that makes dreamweaver, is designed as simpler environment from which content contributors can edit documents themselves without risking compromising the accessibility of the mark-up or the overall look of the document. It interfaces with dreamweaver to allow "check-out" of documents and thus protect against accidental overwrites caused when two people try to edit the same document. Contribute and Dreamweaver were the only editors to offer this functionality. Its user interface is a cross between a browser and word processor and most functions are accessed using simple drop down menus. The code it produces is valid and accessible with the exception of alignment of images which would need to be done by administrators using a more complex editor. Administrator preferences must be set to optimize for accessibility.

Dreamweaver MX produced the best markup of all the editors and had nice popup boxes to request accessibility inputs.  It doesn’t, by default, have these options turned on and preferences must be set appropriately when the program is installed.  It also has an internal validator and accessibility checking.  It is more complex, and the set of functions used by the writers would be a relatively small portion of the tools capability, but it does a good job of screening the user from unnecessary complexity and presenting simple dialogue boxes relevant to the current task.  It received 3 1/2 out of four stars in "Supporting Accessible Authoring" according to Constructing Accessible Web Sites by Thatcher et al.

FrontPage’s strength is that it looks almost exactly like MS Word, writers would quickly feel comfortable with the user interface.  However, this is also a danger.  Styling documents in the familiar way would quickly lead to inaccessible code and probably require much more time from a "clean-up" person, who would edit the file directly to eliminate proprietary markup, solve validity errors, and retrofit accessibility features.  It received only 2 1/2 out of four stars in "Supporting Accessible Authoring".

GoLive is a complex program and yet it doesn’t prompt for any accessibility features and uses out of date methods to markup text.  It received only 2 1/2 out of four stars in "Supporting Accessible Authoring".

RoboHelp is not an html editor, it is a program for creating help files like those in typical Windows programs. It supports the creation of smaller documents relating to specific issues and questions as well as Index, Table of Contents, and Search functions. Macromedia states that it outputs professional quality print documents, manages libraries of related help information, and creates s.508 compliant HTML files. A multimedia summary of this program is available at the Macromedia web site. Using RoboHelp to edit existing software users manuals would require rethinking the scope of your project and rewriting a large number of documents.

Editor Accessibility Test Results

  Recommended Possible Runner-ups
  Contribute 2 Dreamweaver MX Amaya RoboHelp
Cost $99.00 $399.00 $0 $999.00
Allows Check-out of documents (protects against accidental overwrites). Yes. Yes. No. Yes.
Interface Screen Shot Screen Shot Screen Shot Client Example
Usability Intuitive, looks like a cross between a browser and a word processor, but produces accessible mark-up.  Has no code view, and simple menu options that allow a writer to participate without knowing HTML.
Also supports "checking out" documents to avoid accidental over writes with multiple contributors. 
Would be inappropriate for technical site developers but interfaces with Dreamweaver MX. [2]
Intuitive, the user is somewhat screened from the power/complexity of the tool and offered options relating to the current task.  Very impressive. [2] This is a quirky program that does generate valid HTML, but its unprofessional user interface can be very frustrating.  Software for creating help systems (similar to clicking on help in windows programs), it creates search, index, table of contents, and can export to print quality documents.
Would require rethinking the project and rewriting existing documents to fit RoboHelp framework.
Reliability Good. Good. Crashes regularly. Not Tested.
Web site Contribute Macromedia – Dreamweaver MX 2004 Amaya RoboHelp
Easy Tests        
move a paragraph using cut/paste Yes. Yes. Yes.
No right click, forced to use menus.  Clean but left a stray <p>.
insert <p> Yes. Must press return twice or it adds style=margin-top: 0; this can be fixed with administrator options. Yes. Yes.  
move image Yes. Yes. Can cut but not paste.  Requires reinserting  
find and replace product name Yes. Yes. Yes.
Edit: Find
change section of font to bold Yes.
Excellent, used <strong>.
Excellent, used <strong>.
Used <span>.
add link Yes. Yes.  Yes, but convoluted.  Highlight text: Click Link button: Enter URI and alt: Click confirm: Click on text again.  
Medium Tests        
insert "note" paragraph Yes, easy drop down menu. Style must already exist, cannot be created in Contribute. Yes. Yes. 
Style: Apply Class: Note
insert image inline and floated Inline – Yes.
Float – No, uses option of align="right", which is deprecated.
Inline – Yes*.
Float – Yes.* apply style from the properties menu.
Inline – Yes,
Float – Yes, apply style.
insert table Yes, prompts for header but not caption or summary. Options are limited, preserving simple interface. Yes, very good. Prompts for header, caption, and summary. Not fully 508 compliant but valid  
Hard Test        
increase font for all headings No. Yes.
Right click: Manage Styles: new:  h2: tag
Requires  knowledge of CSS.
"Create rule" doesn’t work.  Can edit existing rule.
Requires  knowledge of CSS.
Create Index No.
(Plan: Use CSS and style sheets to generate automatically)
(Plan: Use CSS and style sheets to generate automatically)
No. Yes.
Create Table of Contents No.
(Plan: Use style sheets to generate automatically)
(Plan: Use style sheets to generate automatically)
No. Yes.
TIDY the document Yes.* Yes.* No.
Warning: table lacks summary attribute.
Validate XHTML Valid.* Valid.*
Excellent, can be validated within the program against different doc type declarations. Also, advanced CSS error checking, browser compatibility verification, and accessibility flags.
Validate 508 Compliance Using Bobby Yes.* Yes.* Table missing  row and column headers.  

Not Reccommended

The following Editors are not reccommended either because they failed to create accessibile mark-up or they were inappropriate to the task.  Specific details of each editor are below, but several of the tests were not completed if the browser failed earlier easier tests.

  Functional But Not Accessible Inappropriate
  Frontpage GoLive Authentic XStandard HTML Kit
Cost $199.00
+ $299 for LIFT software to enable FP to produce accessible code.
$399.00 $0 $0 $0
Allows Check-out of documents (protects against accidental overwrites). No. No. No. No. No.
Interface Screen Shot Screen Shot Screen Shot Screen Shot Screen Shot
Usability Looks like a word processor, but dangerous because familiar methods produce invalid, proprietary, and inaccessible mark-up.  Requires expensive accessibility add-ons.
*Tested without LIFT or AccVerify.
Fairly Complex.  Some operations awkwardly required drag and drop, others, menus an inexperienced user might never notice. Very Complex.  Not appropriate to the task. Not at all obvious how to complete even simple tasks. Not WYSIWYG.
Reliability Good. Good.   Crashed OS and never managed to save.  
Web site Microsoft FrontPage
 UsableNet – LIFT for FrontPage
Adobe GoLive Authentic 2004 – XML Document Editor XStandard FREEWARE / SHAREWARE XHTML 1.1 WYSIWYG EDITOR HTML-Kit
Easy Tests          
move a paragraph using cut/paste Yes, though it inserted a "&nbsp;" Yes, left a stray <p>. No. No.[3]  
insert <p> Yes. Yes. No. No.[3]  
move image Yes. Yes. No. No.[3]  
find and replace product name Yes, but deleted a space after the name. Yes. No. No.[3]  
change section of font to bold Yes, but used <b>, a nonstructural tag. Yes, but used <b>, a nonstructural tag. No. No.[3]  
add link Yes. Yes.  Done in separate window. No. No.[3]  
Medium Tests          
insert "note" paragraph No. Yes. Right Click: CSS Style: Note.      
insert image inline and floated Inline – Yes, but doesn’t prompt for alt text.
Float – No, it offers the option of align="right", which is deprecated.
Inline – Yes.
Float – Yes, apply style, but doesn’t prompt for alt text.
insert table Not fully 508 compliant, it doesn’t prompt for important info. Not fully 508 compliant, it doesn’t prompt for important info.      
Hard Test          
increase font for all headings Yes.
Format: Style: HTML tags: h3: Modify.
Requires knowledge of CSS.
While technically possible, the software is complex enough that after 5-10 minutes the task wasn’t finished.      
Create Index No. No.      
Create Table of Contents No. No.      
TIDY the document No.
Warning: <img> missing alt attribute, <img> not closed, table lacks summary attribute, proprietary code.
Warning: table lacks summary attribute.
Validate XHTML Not Valid.
<img> missing alt attribute, <img> not closed, table lacks summary, proprietary code.
Validate 508 Compliance Using Bobby Table missing row and column headers, <img> missing alt attribute. Table missing row and column headers.      

Screen Shots


  1. Frontpage was tested without the optional LIFT software from UseableNet that allows it to produce accessible code. UseableNet did not respond to demo requests .
  2. Preferences must be optimized for accessibility by site administrator.
  3. Crashing and instability limited the scope of the testing.

Why design accessible web sites?


An accessible and non-accessible site can look exactly the same to a non-disabled user. It can be difficult then to understand what the fuss is all about. Why is it important to consider accessibility when designing and planning online assets?

  • First, we have decided as a society that people should have equal opportunities and access even if they are disabled.  To that end, the Federal Government created the Section 508 law.
  • Second, search engines like Google process more than 150 million searches per day, and the programs they use to gather information about a site see nearly the same thing that a blind visitor would.  That means that if you have a site that’s blank to blind visitors, it is also blank to all those people using Google to search for products and services.
  • Third, sites that are designed to be standards-compliant will work on new and upcoming devices (such as accessing web content via a cell phone or PDA).  This means not having to redesign your site every time a new device or browser is released.

While two sites might look identical to your eye, they can be built in radically different ways underneath. The design underneath, when used correctly, is what can provide a very different user experience for disabled visitors. 

Note: No short article can explain accessibility or section 508 compliance in its entirety.  More recommended reading is included under Technical Resources.

An Example

Web accessibility is particularly difficult to determine because, unlike a brick and mortar store front, you can’t see the wheelchair ramp or elevator of a web site  However, there are strategies for understanding better what a disabled visitor to your web site experiences. 

One example, given by Jeffery Zeldman in his book Designing with Web Standards,
The Gilmore is a beautiful web site, and clearly a substantial investment.

Screen Shot of the Gilmore Website - Images On.

However, when viewed with images turned off, to simulate the experience of a blind visitor (or anyone searching with Google), the site is nearly blank

As you can see, the navigation is completely gone, and all of the content except the address is lost. 

Adding text to the code of the site (which is invisible to most visitors, but which allows blind users to navigate) is one of the most basic and easily achievable accessibility measures. 

The Gilmore also uses images instead of text for some of the words on the site. By magnifying the text, we can simulate the experience of someone using a screen magnifier.

As you can see, when images are used to simulate text, the results are blurry and unhelpful. When text is used for all words on the site, it remains clear – no matter what the magnification level is.

The result of images used as text:
Images used to simulate text Text as text
Image used as Text Text used as Text

More Accessibility Notes

The Gilmore provides two examples of how a web site can be inaccessible to those with low vision.  Other accessibility pointers are:

  • Instructions that are audio-only leave deaf users wondering what they are missing.
  • Sites that put sale prices in red don’t allow color-blind visitors to realize that the price has been reduced. 
  • Sites that rely on tables, especially when they have many tables nested inside of other tables, can leave both blind and mobility impaired visitors stuck in one portion of your web site, unable to access other content.

How to Achieve Accessibility

  1. Build a standards compliant web site – accessibility is easier to build into a site that is otherwise compliant with industry standards.
  2. Carefully consider how each of the section 508 guidelines applies to your content.
  3. Plan ahead. Accessibility, like anything else, is much less expensive when you build it into your process rather than trying to retrofit it after the fact.
  4. Choose the right HTML Editor.  The choice of editor is an extremely important one when planning for accessibility.  Some editors support accessible and standards compliant authoring, while others have to be forced through tedious hand coding or expensive add-ons to produce accessible code.  For more information, please see the WYSIWYG Editor Accessibility Test Results.
  5. Accessibility is a continuum and every step you make in the right direction improves the value of your site.  You don’t have to be perfect to be a lot better. 

Technical Resources

More Information

For further information, please contact


Version fran├žais, Pourquoi des sites au design accessible ?

Accessibility for Writers: Software Manuals

One of the most important improvements that can be made to the accessibility of a site is a task that will often fall to writers.  Adding text to describe images allows blind and visually-impaired users to access your content, but writing it is not necessarily something that comes naturally.  The tips compiled here will help you get started and avoid common pitfalls.

If the software you are writing about is not yet accessible, it may help to consider the perspective of a blind parent trying to help their sighted child.  Or a blind and a sited spouse learning to use tax software together.  The example often cited is the nephew who is considering joining the millitary and his visually-impaired aunt who goes on the web to look up information about college funds for soldiers.  Even if the application itself isn’t or can’t be made accessible the manual can and should be.  However, to the extent that the software can be operated by disabled visitors the long descriptions should describe how a blind visitor would use the software.

There are three options available for adding text to images:

  1. Alternative text – the easiest accessibility feature to add and the most important in terms of added accessibility.  Essential information is included in the alternative description. It is specified using the element alt="[enter essential information here]"
  2. Title – used for adding something extra to your descriptions.  You can be more creative with the title.  It is specified using the attribute title="[Enter longer, more creative, extra information here]"
  3. Long description – with complicated images like screen shots or images that convey a lot of meaning to the viewer long description is used.  It is specified using the longdesc="[Enter url of long description here]"

Alternative Text –

Pink Water lillies and blue padsYou’ve probably already noticed Contribute prompting you for alt text when you insert images, but maybe you weren’t 100% certain what the appropriate text should be.

Alt text should be used to describe what something is, represents, or does.  For instance, this picture of water lilies could have the alt text "Water lilies on Ames Pond".  Alternate text should be a summary of what the photo is in few words. 

Section 508 regulations require that this text be an equivalent to what a sighted person sees when looking at the image, but also stipulates that it not be long or vague.  The struggle is to be balance accuracy with brevity. 

Alt text should never be longer than 1024 characters.  Generally, it should be just a few words.  It is important to keep in mind that everything on a page has to be read aloud to someone who can’t see the screen.

You might have asked yourself "What something does", how can an image "do" something?  Occasionally images are used for links.  In this case the alt text should tell the user what will happen if they follow the link.  For instance if the link leads to a page about ponds in Maine, it should say "Maine Ponds" or something similar. 

Common pitfalls:  Never use the phrase "Picture of" or "Link to" in your alt text.  The screen reader will already have informed the user that the text refers to a link or a photo.  It is easy to imagine how this would get irritating to hear twice every time the user encounters an image.

Alt text must be included for absolutely every image every time.  However, there are times when an image doesn’t really serve a function.  For instance images used solely for layout purposes like borders, rules, textures, rounded corners, and sometimes logos.  In this case you should include alt="".  This tells the screen reader to skip over the image entirely.  If you don’t include this convention the user will hear over and over IMAGE IMAGE IMAGE, and wonder what they are missing. 

Tour ButtonAlt text should always be considered in the context of the document in which it is included.  For Instance, software manuals often contain buttons and descriptions of those buttons.  In the actual program the alt text might be "Take a tour" or "Tour the Reader", but in the context of a guide about the software the alt text should be "Tour Button" or something similar since the important thing is that the user be able to identify the button and apply that information to using the software.

For screen shots where we will also include a long description the alt text should be "Library Screen shot – long description".  This will let the user know that the image is both the library screen shot and a link to it’s long description. 

Long Description -

Long descriptions are separate web pages used to describe complex images such as screen shots which cannot be completely summarized by their alt text or their context.

Title Page Screenshot - long descriptionJoe Clark suggests long descriptions be kept in the same directory and use the same filename as the image they describe,  adding -LD at the end of the file name for easy identification.  For instance, the following image "TitlePage.png" would have a long description called "TitlePage-LD.html". 

Long descriptions are simple text only pages which use words to describe what the user cannot see.  The title should be "Long description for TitlePage.png". 

Screen Shots:

Use these guidelines when writing descriptions of screen shots. 

You can see an example of a long description by clicking on the image above.

  • Describe what you see.
  • Imagine that you were a blind teacher trying to explain to a student how to navigate that particular screen.  What would they need to know?  Tell the student how to find the different functions using only words.
  • Work from the top left to the bottom right and describe things in order.  (as the english language is read from left to right, and we are writing in English)
  • When sections of the screen shot look like tables or lists, describe them as such. 
  • Using grouping words like column, navigation bar, band, etc to group related portions of the Screen shot will make your descriptions easier to read.
  • Language should match the image.  Administrative screen shots should be described with functional language, whereas fun screen shots from the application should be described with more detail. 
  • Refer to color, shapes, or other presentational devices that would help a blind teacher or parent to tell the student what to look for.
  • Avoid describing the same things multiple times.  If we have already created a long description for the library and then you write a long description for a specific screen within the library it is enough to include a phrase like "In a yellow bar across the top are the typical controls found in the library." and make the word library a link to the more general description of the library.
  • The long description is included to make the image useful in it’s context.  You may, if it is absolutely necessary to make the description more comprehensible, include information that is also in the text of the document, but generally it should be unnecessary. 
General Images:

Read Joe Clarks advice on how to write a long description for a photo.  While this article deals with writing long descriptions for screen shots, his approach can help you start to understand what information to include.



Web Design Resources

I became a geek by accident. I was a groupie for ages and then it just kind of rubbed off on me. I am eager to collect my links before they get lost.  The resources for learning to design well are out there, but hard to find and evaluate until you know the basics.  This represents, quite simply, what I know so far. Designing to standards is so graceful when you finally feel comfortable with it, it demands a lot, but now I wouldn’t do it any other way.

Almost all of the pages I write are XHTML 1.0 Strict, with valid CSS.  Support for it is excellent now, and with some thought no one, not even users of Netscape 4.X need to lose content.  They may not get to see your gorgeous design, but your page will be light and flexible, and users of modern browsers can still get a full user experience without designing different sites for every browser ever made. 



Web Standards

I started by reading the specifications at the W3C.  I like this approach, but there are probably easier ways to go about it.  The specifications are usually relatively straightforward, but they include a lot of information about browser implimentation that isn’t strictly necessary.  Also, they just aren’t targeted to designers.  They aren’t supposed to be.  I am ordering Eric Meyers book about CSS and I will let you know what I think. 

Design Resources

  • Color Scheme – A tool for harmonizing your color scheme.
  • ChromoFlash – another color tool (in French).
  • A list Apart – Articles on all aspects of standards based design.
  • Spazowham – I am completely in awe of these people, they are incredibly clever and committed to accessibility.  No sacrifice.
  • Layout-o-matic – For basic layout choices you do not need to reinvent the wheel.
  • Essential Fonts For Designers – A source for free true type fonts.
  • Dreamweaver – An excellent tool, though it needs to be coerced into producing valid accessible code.
  • XMLSPY – This editor is amazing, valid or very nearly valid code 100% of the time.  Not for the faint hearted, this is a powerful tool, not a WYSIWYG environment.

Cross Browser Compatibility

  • Position is Everything – Excellent source of information on css bugs and support. Use caution employing their techniques, some of the cures are worse than the disease. I would rather add a couple unstructural div tags than a mess of hacks in the css.


  • Designing Web Usability – by Jakob Nielson, a fabulous book, takes the guess work out of making a website work for the users. I read it in a weekend, it managed to be that engaging.



Approach:  For a long time I didn’t really understand the reason for CSS, XHTML, and standards in general.  I didn’t get that the reason for the separation of CSS and HTML was to separate content from presentation.   And even when I read that statement in Standards based design books, I didn’t understand why.  What are the benefits of this separation?

12/42 seconds loading Cut page size and thus loading times by up to 75%.  Saving strain on servers and disk space at hosting service or on machines hosting the site.  Particularly for image heavy sites such as Artists would often have saving speed in the details helps insure that images of artwork will load sooner.

How to write lite HTML?

Choosing an editor

Chances are, you already have a tool that you are comfortable with, but is that tool really supporting your efforts to author valid, accessible, modern code?  Validity and accessibility are ultimately not something you paste on top of an otherwise broken website.  By far the easiest way to author well is to learn to do it all along.  When I finish writing a template page for a website, I run it through the CSS validator and the HTML validator on the W3C website.  When I first started authoring valid code this was a tedious process.  I was trying to validate something broken.  Now, when I finish with a site it often validates without any errors.  This is the result of a change in  process.  A change in editors (pico just allows too many typing errors!) as well as rethinking the way to author and the reasons for separating content from presentation.

I reviewed several html editors in the article WYSIWYG Editor Accessibility Test Results:   Allowing writers to contribute to the creation of accessible documents.  This review was based on a search for a non-technical tool for writers.  Based on your level of technical skill and the resources you have available you may consider Dreamweaver or Contribute (with options configured for accessibility and validity), Amaya, or XMLSpy. 

First write XHTML Strict 1.0. 

It’s just easier to work within the rules once you get used to them.  This means that you use a doctype declaration at the top of every page. This declaration lets the browser (Internet Explorer, Netscape, Opera, and others) know what kind of mark-up to expect and in some cases how to interpret it.  Transitional sounds easier at the outset, but diagnosing layout problems is a lot easier if you are certain these are not just the quirks of lower quality code.  The initial investment is well worth its payoff in the long run. 

This means that you must finish what you start! List Items, breaks, images, paragraphs, and horizontal rules must all have closing tags.  This is accomplished in two ways.  List items and paragraphs must have closing tags.

	<li>Nose Rings</li>
	<li>Other Rings</li>


<p>Text text text text.</p>

Images, horizontal rules, meta elements, and breaks remain a single tag, but they must be closed within themselves. Note the space between the end of the tag information and the back slash.  This is essential for some reason I do not now recall.  Just do it.

<img src="images/pearlearrings.jpg" />

<br />

<hr /> 

Write all tags and attributes in lowercase.  Put quotes around attribute values.  Use escape characters for all symbols.  For instance &amp; for the ampersand.


A return to grade school, outline the document like a research paper.  Start with a roman numeral I. and work your way down to the finish.  At this point don’t consider how you want to present the content, but only what it is and how it relates heirarchically to the rest.  For Instance, consider this website: Flesh out

  1. Nicole Sullivan
  2. Skip Links
  3. Stylesheet Switcher
  4. Navigation
  5. Article Title
    1. Subtite
      1. Sub-Sub Title
  6. Extra Information

Using Lists for Navigation Elements

Using Selectors

Selectors are the key to avoiding div-itis.  Probably half the weight of the first couple of sites you build using CSS will be div tags. 

Meaningful Names

You’ll be kicking yourself the third time your client asks you to change to look of an element you called "redUnderline".  If you choose structurally meaningful names for classes like "specialInstructions", "teamCaptain", or "salePrice" the look can change without losing cohesiveness.  This will also keep a consistent appearance accross multiple pages which not only helps branding, but allows disabled visitors in particular to quickly understand how to navigate around your site and find the information they are looking for.