One of the biggest headaches in managing the code side of Web design is the variations that exist in how markup is formatted. I don’t mean how it will look on display, but how the code itself is formatted behind the scenes.  Read more

SSI (Server Side Includes) are directives that are placed in HTML pages, and evaluated on the server while the pages are being served. They let you add dynamically generated content to an existing HTML page, without having to serve the entire page via a CGI program, or other dynamic technology.  Read more

I've mentioned that HTML and XHTML documents have an inherent structure, and that's a point worth repeating. In fact, that's part of the problem with web pages of old: too many of us forgot that documents are supposed to have an internal structure, which is altogether different than a visual structure. In our rush to create the coolest-looking pages on the Web, we bent, warped, and generally ignored the idea that pages should contain information with some structural meaning.  Read more

The WCAG contains many valuable strategies for opening your site’s doors as widely as possible. But they do not always map to common, real-world scenarios. Designers and developers often find themselves following the spirit of accessibility without adhering to every letter of the law, because at the end of the day, common sense will dictate what is in the best interest of your visitors. Some Priority Level 3 requirements are as easy and useful to implement as Level 1, just as some Level 1 requirements are nearly impossible to objectively quantify. For instance, checkpoint 14.1, required for Level 1 compliance—“Use the clearest and simplest language appropriate for a site’s content”—is an area where many feel the W3C itself falls short. They might disagree, and how could you argue with them if they did? What quantifiable measuring sticks do web developers have to rate content? It’s important to dispel the myth that accessible sites must be ugly. Too many designers equate accessibility with all-text documents without visual formatting or decorative images. This could not be further from the truth. Ninety-nine percent of accessibility is achieved within the markup (the one notable exception being accommodating the visually impaired with wise color choices), so even the most beautiful sites can welcome all visitors. The bolt tightening and pipe cleaning that needs to be done under a corporate website’s hood is usually quite minimal. The value that a few pieces of additional markup brings to the table is enormous. If Target had put just a few extra hours of spit and polish into their HTML, they might have completely avoided a costly and widely publicized lawsuit. The rest of this chapter will explore some tactics for better real-world accessibility—changes that will directly benefit visitors without getting hung up on explicit WCAG compliance.   Read more

There are numerous platforms on which to develop a corporate website—some are turnkey (meaning that everything works right out of the box), and others are customizable solutions ranging from small, free, and open source to large, expensive, and proprietary. Some websites are built entirely in Flash, others in static HTML, and others in closed platforms like Lotus Notes and Domino. HTML vs. Flash Flash has grown from crude animation software to a mature application development environment. Many design agencies specialize in Flash websites, and their creations are often rich interactive experiences built to wow the audience. While it is possible to build a corporate website entirely in Flash, there are several key disadvantages to the platform:   Read more