bobbyvandersluis.com | Unobtrusive Flash Objects (UFO) v1.0
A great article which explains a useful way to include flash content in your website without compromising standards.
bobbyvandersluis.com | Unobtrusive Flash Objects (UFO) v1.0
A great article which explains a useful way to include flash content in your website without compromising standards.
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.
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.
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. |
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 " " | 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. |
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?
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.
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.
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.
Images used to simulate text | Text as text |
---|---|
![]() |
![]() |
The Gilmore provides two examples of how a web site can be inaccessible to those with low vision. Other accessibility pointers are:
For further information, please contact nicole@postdiluvian.org.
Version français, Pourquoi des sites au design accessible ?
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:
You’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.
Alt 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 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.
Joe 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".
Use these guidelines when writing descriptions of screen shots.
You can see an example of a long description by clicking on the image above.
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.