COMPATIBILITY & ACCESSIBILITY
People will be visiting your Web site with all manner of systems. They could be on a Macintosh or on a PC or on a UNIX platform. They could have set their monitor's resolution to 640x480 or 832x624 or 1024x768 or higher. They could have set the number of colors their monitor uses to 256 or thousands or millions. They could be using Netscape or Internet Explorer or AOL or Opera or WebTV to view your site. They could be running any version of the browser of their choice. They could have changed their default settings on their browser, increasing the font size, changing the background color, turning images off, disabling JavaScript. They could have their browser window minimized or opened wide. The number of possibilities for how users may access your Web site is staggering.
But, more staggering still, when you think about cross-browser compatibility, there are more browsers to consider than Netscape, IE, AOL, Opera, or even WebTV. Users who are visually impaired may be accessing your site using screen readers or Braille readers. The issue of accessibility for disabled users is larger still and is, for many Web sites, a legal imperative. As of February 2000, as part of Section 508 of the Workforce Investment Act of 1998 (an extension of the American with Disabilities Act), all US Federal agencies, as well as all state and local government agencies, were required to make their Web sites accessible to individuals with disabilities. As of yet the Act does not apply to recipients of Federal funds or to the private sector, though those days are likely coming very soon.
Degrading Pages
If you're doing your job as a designer, you already know that the page you designed for Internet Explorer 3.0 (complete with stylesheets and floating frames) looks reasonable in Netscape 2.0. Do you care what it looks like in Netscape 1.0? How about Lynx? You've got to draw the line somewhere, but you've also got to be prepared when your "work of art" wets the bed in AOL. When I first saw something I was really proud of on an AOL browser, I wanted to crawl under a rug. The [WebTV] browser can be a real eye-opener as well...
You ... need to decide what level of technology you want to use. You've got a couple of options. If you keep it really simple — no Java[Script], no CGIs, no frames, maybe a table, some GIFs, a JPEG background image, or a <bgcolor> tag — you can be reasonably sure that most people who've downloaded a browser in the past year will all see the same thing...
The next option is to spice things up a bit with things that won't change your design significantly if a browser doesn't recognize your tags. This is still a pretty safe way to go — just the basics, plus some bells and whistles:
- You could change the font or link color (supported by Internet Explorer 1.0+, Netscape Navigator 2.0+), but you should ask yourself whether the page will still look OK if the type appears in Netscape 1.0 as black — because it will.
- You could use the font size tag (Navigator 1.1+, IE 1.0+) or the font face tag (IE 1.0+, Navigator 3.0).
- If you want to add color to a table cell (Navigator 3.0, IE 3.0), make sure the organization doesn't fall apart without it.
The last way to go is top of the line. I'm talking banana split here — chocolate, pineapple, whipped cream, and nuts. The most important thing to remember when you use higher-end technologies is that you must provide a simple alternative for people who can't see them.
- If you're going to use frames, make sure you provide a "no frames" version.
- If you want to use JavaScript, make sure you place your code within <!--comment--> tags so browsers that don't support JavaScript will skip right over it. Again, if you're using it for an integral part of your page, provide an alternative.
The bottom line is: Know your audience. You're not going to make everyone happy, but with a little effort, you can make sure a large percentage of your users see your pages the way you intended. It's as simple as that.
Accessible HTML
There are thousands of hardware and software products for computer users with physical disabilities, but you don't have to become an expert in assistive technologies to create an accessible Web site. All you have to do is one thing: Make your documents navigable by text browsers.
Most assistive technologies — screen readers, voice-recognition software, touchscreens, Braille readers, and speech synthesizers — grab output as ASCII characters. The fact that most of these technologies were developed before the GUI — when command-line interface ruled the computer world — means these devices work well with a structural markup language like HTML.
The easiest way to make your pages hold up through a text browser is to use the ALT element of the <IMG SRC> tag properly. Many people include ALT text without thinking about what it's actually for: describing what the image is. If you use a text browser, or you're like me and still run Netscape 1.1 at home because your machine is old, and you don't have the cash to upgrade anything, surfing without images is only possible with comprehensible <ALT> text.
The ALT element goes within your <IMG SRC> tag, like this:
<IMG SRC="usefullmatt.gif" ALT="photo of Matt Stevens">
Don't do this:
<IMG SRC="usefullmatt.gif" ALT="photo">
This doesn't work because the ALT text doesn't communicate what the image is to someone who can't see it. More importantly, if the image is used as a link, the ALT text should say where the link will take the user. Otherwise you cast off users to float forever without a point of reference.
A common mistake is to do something like this:
Before you go on, choose one:
<IMG SRC="logon.gif" ALT="button">
<IMG SRC="signup.gif" ALT="button">
<IMG SRC="exit.gif" ALT="button">
Instead, try this:
Before you go on, choose one:
<IMG SRC="logon.gif" ALT="logon">
<IMG SRC="signup.gif" ALT="signup">
<IMG SRC="exit.gif" ALT="exit">
[...]
If you're curious how well your pages already hold up, check your HTML at The Bobby, an HTML validation service set up by the Center for Applied Special Technology. [Or, enter your URL into Lynx-It, a simulator of the Lynx text browser to see what your HTML looks like without graphics or tables.]
Using Dreamweaver to check a page for compatibility with target browsers
Dreamweaver lets you construct web pages with elements that are supported by all browsers (for example, images and paragraph text), as well as elements that are supported only by newer browsers (for example, styles and layers).
The Check Target Browsers feature tests the HTML in your documents to see if any tags or attributes are unsupported by your target browsers. The check does not alter the document in any way.
The Check Target Browsers feature uses text files called browser profiles to determine which tags particular browsers support. Dreamweaver includes predefined profiles for Netscape Navigator versions 2.0, 3.0, and 4.0, and Internet Explorer versions 2.0, 3.0, and 4.0. To modify the existing profiles or to create new ones, see Creating and editing browser profiles.
You can run a target browser check on a document, on a directory, or on an entire site.
To run a target browser check:
- Choose from the following options:
- To run the check on the current document, save your file. The check is performed on the last saved version of the file and does not include unsaved changes.
- To run the check on a directory or site, choose Window > Site Files to open the Site FTP window; then select a folder from the local directory. The target browser check is performed on all the HTML files in this folder and any folders inside it. Target browser checks can be performed only on local files.
- Choose File > Check Target Browsers
If you have not yet selected a primary browser, you are prompted to do so.
- From the list of browsers, select the browser to check against.
- Click Do Check
The browser target report opens in your primary browser (the browser launches if it is not already open).
- To save the report for later reference, choose File > Save from the browser.
The target browser check report is a temporary file stored in the Temp folder in Windows and in the document root on the Macintosh. The file will be lost if you don't save it before browsing to another site.
Using Dreamweaver to resize the Document window
The current dimensions (in pixels) of the Document window, along with several common monitor sizes, appear in the Window Size pop-up menu in the window's status bar. To help you design a page that looks good at a specific resolution (or several different resolutions), you can snap the Document window to any of the sizes listed on the pop-up menu.
Using Dreamweaver to checking download time and size
The size and estimated download time of the current page appear at the bottom of the Document window. Dreamweaver calculates size based on the entire contents of the page, including all linked objects such as images and plugins.
Dreamweaver estimates download time based on the connection speed entered in the Status Bar panel of the Preferences dialog box. Actual download time varies depending on general Internet conditions.
— Excerpted from Macromedia Dreamweaver Help Pages
CODE BLOAT
Using a WYSIWYG to write generate your HTML presents compatibility issues of its own.
Not only do HTML tags not correlate perfectly with page-layout commands, but WYS in one browser is often different from WYG in another. And no matter how sophisticated the editor, it still has to make choices and compromises as it tries to translate your command into acceptable HTML. [When you] use an editor, you'll want to familiarize yourself with its idiosyncracies, and make sure you know how and when to go into the HTML code and clean up after them. You'll also have to contend with the assortment of proprietary tags some of the programs sneak into your documents for their own nefarious purposes... Finally, and perhaps most importantly, editors can only know about HTML as it existed when they were released. To take advantage of any HTML not known to the editor, you'll have to insert it by hand (or wait for the next version of the editor)... Ironically, the best feature of most WYSIWYG editors is that they allow you to edit your HTML directly in a text editor.
|
EX LIBRIS CANDY REVIEW
|
|
Code Bloat
Initial passes at laying out the Candy Review pages with a WYSIWYG may look okay at first and even when previewed in the browser, but a glance at the source code shows a different story. See how Dreamweaver and GoLive measure up when it comes to "code bloat."
|
|
The HTML-related idiosyncracies of WYSIWYG's — "code bloat" — are also a download time issue. There are a number of tools that cater specifically to shrinking and optimizing graphics for the Web, but HTML can stand to be optimized as well; each character in an HTML document accounts for a portion of the file size, the more characters, the larger the file size. Thus, removing extraneous code, such as specified defaults (for instance, the ALIGN=LEFT attribute/value pair which is almost always the default, and therefore unnecessary) and empty and redundant tags, and most importantly simplifying your table layouts (note that the contents of a table's cells will not load until the entire table loads from <TABLE> to </TABLE>) can "optimize" your code.
You may have thought that using of a WYSIWYG editor would free you up from the messiness of dealing with HTML and code, but in fact if you haven't already developed your ability to "read" HTML, you may find that working with a WYSWIYG will require your development of this skill to spot and remove code bloat.
FURTHER READING
Accessibility
Compatibility
Code Bloat
ASSIGNMENT
- View your pages in at least three browsers, including a text-only browser. Note any differences in display.
- Check your pages for compatibility in Dreamweaver.
- Examine the source code of your pages and identify and remove "code bloat."
- Begin building the Web pages in your site.
NEXT CLASS
Animated graphics with Fireworks
