Category Archives: Accessibility

Accessibility, CSS, Geek, General, XHTML / HTML

WWW2005 – shameful name dropping

I attended WWW2005 in Chiba, Japan, just outside of Tokyo. It was a fun conference. I met lots of great people, and saw some people I hadn’t in a while. I was pleased to meet, and not drool on, Eric Meyer, who is both taller and cuter than I had imagined.

I also really enjoyed geeking with Bert about developments in WYSIWYG css and html editing. I think I will give stylemaster another try as he said it now has built in templates for different column layouts that have already been tested for browser compatibility. I had been using Inknoise‘s layout-o-matic, and sometimes the list-o-matic at accessify as jumping off points, but it could be nice to have that functionality on the desktop.

I am also thinking of doing a marketing promotion / good deed at dovetail. Yes, they can be one and the same! I would like to develop a basic accessibility report which can be prepared relatively quickly, and yet provide information for decision makers about how their website fairs against S.508 guidelines and WAI checkpoints. I think I will ask, the very energetic, Molly for her advice when I have a basic template put together. Meeting her in Chiba was really fun, she is totally committed to standards and she really knows her stuff.

I saw Tantek, but hardly got to talk to him this time. I also met the newest Internationalization staffer at the w3c, Felix, who, along with Richard Ashida, helped me order “women’s saki” and thus grow to appreciate what had before tasted like the smell of rubbing alcohol.

Of course, I also hung out with Eric and tried to solve the css problems in one of his presentations in the two minutes before he started to speak. He wanted a double row of list items so that they would fit on the projector without scrolling. Much like the A List Apart article that caused readers to get so nasty.

Wendy and I went shopping just before her flight and didn’t discuss accessibility even once. It was lovely to reconnect with her. I hope that Hugo, Vishal, and I can visit with them sometime soon. We bought beautiful pieces of antique kimono silk. Now I will have to find a backing or frame for it. I should have bought something in Japan, their aesthetic is really compelling.

I also met Shawn’s very jetlagged husband who is a pilot and not a geek, so I doubt very much that he has a website. He and Eric geeked about helicopters and plane crashes. Hugo probably would have loved that discussion!

I also saw Zac again from @semantics who had graciously hosted SPARQL-ing days, in Monte San Savino, Tuscany. (Quite possibly the best food ever served at a conference). Libby was also around. Robin turned me on to a traiteur italien on the rue St. Maur, in Paris. I still have yet to check it out because I am studying for my exam.

Ok, thats enough for my first-ever-name-dropping post. If it gets to be a habit I will create a category so that those who wish, can avoid this type of post.

Accessibility, CSS, Geek, General, XHTML / HTML

WYSIWYG Editor Accessibility Test Results:

3 Comments

Allowing writers to contribute to the creation of accessible documents.

Summary:

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

Reccommended
  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>.		 Yes. 
Excellent, used <strong>.		 Yes. 
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) 		No.
(Plan: Use CSS and style sheets to generate automatically) 		No. Yes.
Create Table of Contents No.
(Plan: Use style sheets to generate automatically)		 No.
(Plan: Use style sheets to generate automatically) 		No. Yes.
Clean-up        
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.		 Valid.  
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
AccVerify 		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.      
Clean-up          
TIDY the document No.
Warning: <img> missing alt attribute, <img> not closed, table lacks summary attribute, proprietary code. 		No.
Warning: table lacks summary attribute.		      
Validate XHTML Not Valid.
<img> missing alt attribute, <img> not closed, table lacks summary, proprietary code.		 Valid.      
Validate 508 Compliance Using Bobby Table missing row and column headers, <img> missing alt attribute. Table missing row and column headers.      

Screen Shots

Reference

  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.
Accessibility, Geek, General

Why design accessible web sites?

1 Comment

Introduction

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 nicole@postdiluvian.org.

Translations

Version français, Pourquoi des sites au design accessible ?

Accessibility, Geek, General, XHTML / HTML

Accessibility for Writers: Software Manuals

1 Comment

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.

Translations

Français