Accessibility: putting it all together with fusebox 4; fusebox 4 and web standards go hand in hand, creating an accessible site with minimal headaches – web site accessibility
In the last three articles in this series, I’ve spent a lot of time on everything but ColdFusion. Separating content from presentation by using Web standards makes accessibility much easier. Using ColdFusion and Fusebox 4 to do this makes it even easier.
One of the basic tenets of Fusebox has always been to separate out business logic from display logic. This has been done by designating specific types of files (called fuses) to hold different types of logic. Historically, the following have been used:
* Query fuses (qry_fusename) holds code that returns a recordset
* Action fuses (act_fusename) holds code that runs business logic
* Display fuses (dsp_fusename) holds the actual code that displays to the user
Web standards takes the idea of display one step further, by separating out the content (HTML and actual information) from the way it’s presented (cascading style sheets [CSS]). The concepts of separation in Fusebox 4 go hand in hand with the concepts of separation in Web standards.
Fusebox 4 and Content Variables
Fusebox 4 includes the capability of calling multiple fuseactions within another fuseaction using the Fusebox 4 XML command . Calling the command also includes the ability to “stuff” any output for display into a variable of your choice rather than outputting it at the moment of creation. This attribute of the command, “contentvariable,” opens up a world where Web standards become easy.
Imagine a portal system where you want to create menus, and pull in news, articles of interest, and other items. The code for each item can become complex. By separating out each item as fuseactions, we simplify the task by breaking it down to simpler components. (Note: In the sample code here, I’ll show only the calls to the display since this article is focused on the layouts.)
Fusebox 4 uses the concept of circuits (in our case, directory structures) and fuseactions (calls to grouped sets of individual scripts or fuses). Each circuit will contain a circuit controller which is called circuit.xml. In this controller, the Fusebox 4 XML language is the language used. (The fuses will be the code that contains our ColdFusion and XHTML.)
In our sample portal, the call to the home page would be a fuseaction called welcome in the home circuit (or in Fusebox 4 jargon, home.welcome). The circuit itself is displayed in Listing 1. You’ll notice in this listing that the fuseactions being called within the main fuseaction all contain a call placing the information into a content variable (i.e., places the output which results from the call to the menu in the view HTML main circuit [vhmain] into a content variable called “content.menu”). The fuseaction called in our sample “includes” the actual display fuse as seen in Listing 2. The information contained in the dsp_menu fuse would be very simple XHTML as found in Listing 3.
Listing 1: Main fuseaction calling other fuseactions
<do action="vhmain.welcome" contentvariable="content.welcome"
<do action="specials.display" contentvariable="content.special"
<do action="vhmain.contact" contentvariable="content.contact"
<do action="vhmain.sitenav" contentvariable="content.textlinks"
Listing 2: Menu Fuseaction
Listing 3: Contents of dsp_menu.cfm
Displaying All the Content Variables
To display the content variables, we add another type of fuse to the Fusebox 4 toolbox. A layout fuse (lay_fusename) as shown in Listing 5 will contain the actual presentational code, including calls to cascading style sheets. Notice there are no tables used; the presentation is styled using CSS. Also notice how simple the page is. It really consists of only the actual XHTML code needed for the layout and the content variables placed specifically where necessary. Changing a layout page is simple since you are truly working with the layout as a whole, instead of trying to work around your content as well. Layouts should be their own circuits and be called as a fuseaction via the command as in Listing 4.
Listing 4: Layout circuit
Listing 5: Web standards layout for portal page
<!doctype html public
“-//W3C//DTD XHTML 1.0 Transitional//EN”
content=”text/html; charset=iso-8859-1″ />
Layout files can be called at the end of a fuseaction with the ability to change layouts on a fuseaction basis. They can be called per circuit by making use of Fusebox 4’s call in the circuit.xml or they can be called for an entire application by being placed in the area in the fusebox.xml file. How you choose to place your layouts depends entirely on you.
Can’t I Do It with Just ColdFusion?
You can accomplish the same thing in ColdFusion using the tag (in CF5 or CFMX) or the custom tag , written by Steve Nelson for older versions. In each case you would wrap all the output between the tags and save it and then have your layout at the end of your .cfm file, possibly via a . However, one of the benefits to using the Fusebox framework is that a lot of the grunt work is already done for you.
How About Netscape 4?
Netscape 4.x was first introduced in December 1996. As such it is not a Web standards-compliant browser. In fact, the latest statistics from browser news (www.upsdell.com/BrowserNews/ stat.htm) and other sources show Netscape 4 as having a less than 2% rate of usage at this time. So how come we still have to consider them?
Netscape 4 Standardization
Many United States federal agencies are still standardized on Netscape 4, a browser that was introduced in December 1996. One of the by-products of this is that most agencies still rely on producing Web sites and applications using the nested table layout because that’s what works on their computers. It’s hard to design a tableless site for a client who can’t see it. Viewed in this way, the U.S. government might be considered one of the largest stumbling blocks on the road to accessibility.
Speech Browsers and Screen Readers Cannot Easily Be Detected As Such
The other obstacle to implementing Web standards in this environment is that many speech browsers, such as IBM Home Page Reader, use Internet Explorer as an underlying browser. A screen reader will use whatever browser the user has available. Because of this, it’s impossible to use a browser detection script to definitively say that a particular user is “viewing” a page using assistive technology. So how do we solve this conundrum?
One of the tenets of Section 508 is: 1194.22(k) A text-only page, with equivalent information or functionality shall be provided with the provisions of these standards, when compliance cannot be accomplished in any other way.
I propose a new accessibility rule:
When designing pages that shall be accessible, a reasonable alternative shall be made when a browser that does not support Web standards is encountered. The content of a non-Web standards page shall be updated whenever the primary page changes.
In other words, I propose that we code our pages to Web standards (including positioning) and that we treat outmoded browsers like Netscape 4 as the alternative. Since browser detection scripts can easily determine Netscape 4, it’s a reasonable use of resources.
Separate and Equal
To make our pages separate and truly equal, all that’s necessary is to direct our content variables to a tabled layout when Netscape 4 is encountered. The actual changes to the existing Fusebox 4 code are truly minimal. These changes involve creating a tabled layout for each of our standard layout pages, a style sheet that works with Netscape and implements a browser sniffer as a preprocess plug-in.
A browser sniffer is code that determines what type of browser is currently accessing our site. There are several browser sniffers available. I tend to use a free one found on the Macromedia Exchange called AEBrowser. Since Fusebox 4 does not contain the ability to call a custom tag within its XML language, I need to place the actual custom tag call to the browser sniffer in a fuse or a Fusebox 4 plug-in and use it that way.
I call the plug-in, which I have named “sniffer” in Fusebox 4’s preprocess phase. This phase executes before any calls to any fuseactions take place.
The plug-in itself must sit in the plug-in subdirectory. All sniffer. cfm contains is a call to the custom tag via cfmodule.
This sniffer creates a structure called browser.
Everything else in our system works in exactly the same way until we call the layout fuseaction , as shown in Listing 6. The call to the portal layout uses Fusebox 4’s conditional statement to determine if our user is coming in via Netscape 4. If so, it calls a tabled layout, otherwise it calls the standards layout. The tabled layout will call its own style sheet specifically designed for Netscape 4, as well as streaming the exact same content into a tabled layout as shown in Listing 7.
Listing 6: Determining layout by browser type
<if condition="browser.isNavigator is true AND
Listing 7: Netscape 4 gets the tabled layout
<!DOCTYPE html PUBLIC
“-//W3C//DTD XHTML 1.0 Transitional//EN”
<meta http-equiv="Content-Type" content="text/html;
<link href="assets/table_style.css" type="text/css"
<body topmargin="0" leftmargin="0"
<table height="586" cellpadding="2" width="592"