This series is intended for both the novice and the experienced HTML coder. It will include information for beginners. This will help you learn the right way and avoid bad habits. I assume you are familiar with basic computer/Internet use and terminology.

Introduction: What is “valid, accessible” HTML (or XHTML)?

I am not referring to avoiding errors which prevent the display of content or which display HTML code in the browser. (Yikes!) Rather, I am referring to standards and best practices. There are international and national standards for many things (machinery, electricity, hardware interfaces, Internet protocols)…there are also standards for coding web pages. Here is what I mean in the context of coding webpages:

W3C (World Wide Web Consortium)

– international, chartered organization responsible for web-related standards; made up of individuals from many technical specialties, companies, governments, countries, races, and levels of experience; working groups develop proposals and solicit input, and members vote on the recommendations

valid code

– the code meets the standards put forth by the W3C for a particular language and version (e.g., HTML 4.01 strict), which the author must declare in his or her document

accessible

– the document meets some official standard for ease-of-use for those who have conditions such as blindness, color-blindness, and motor impairments; there are voluntary international standards, and countries may have specific laws and standards of their own; the only Internet-related accessibility law in the United States is Section 508, and it applies only to the government, though all websites should meet its standards; ideally, strive for the highest level of compliance with accessibility standards, especially if yours are a commercial website

What is the purpose of writing valid, accessible HTML?

The easiest issue to explain deals is accommodating people with physical handicaps or challenges.

Blind users cannot see your graphics. They cannot see the layout of your website, so they cannot interpret visual cues to determine what content is important. In contrast, sighted users can instantly see the layout of content and navigation with a quick visual scan and so ignore navigation, advertisements, and extrenuous information until needed. Blind users cannot determine important points from text that is visually bolded, or ordered steps using arrows.

The blind use special software called screen readers which “read” the pages to them. Like the users themselves, screen readers cannot take advantage of visual cues to determine the order in which content should be read, or the importance of an item — by default, they will just read all the content in the order in which it actually appears in the code (including all your navigation links). Many webpage designers have used tables with invisible borders (intended for tabular data) to control their layouts and overcome display discrepancies between browsers, especially when a complex graphical layout is desired. Is this a big deal? Yes! Many screen readers cannot handle tables at all, and if they can, they have no idea in which order content should be read!

People with other physical disabilities may find it difficult or impossible to access webpages using the mouse, they keyboard, or both. Some people may use pointing devices instead. For example, many people deal with conditions such as carpal tunnel syndrome, multiple schlerosis, or paralysis. There are even Braille printers. Other people are color-blind and require a high-contrast design. Still others are not disabled, but configure their browser to not display images, either because images annoy them or because they have slow Internet connections. These users need important images described to them, and/or a description to take the place of the image on the page.

There are also other usability and accessibility issues.

Some “surf the web” with text-based browsers. Why? Because they are faster, since they don’t have to worry about pictures, layout, colors, and fonts, and because many of them use an operating system that allows them to boot their computers into the command line, without using a GUI (”goo-ey”), a graphical user interface (such as a desktop), or allows them to choose their mode at startup.

Writing code that conforms to a standard (preferably the strictest and latest) helps to deal with most cross-browser issues. During the fierce “browser wars” in the 1990’s between Netscape and Microsoft’s Internet Explorer, both companies introduced tags that were proprietary (private property, meaning the other browser couldn’t use them). They also handled the standard tags and attributes inconsistently. This caused website designers to target their websites specifically at users of one browser or the other, or even to build seperate websites for each. Nonstandard code also causes horrible problems for people using screen readers and other assistive technology!

All browsers are much better today at handling code in a uniform way, but they are not perfect. Also, they attempt to accomodate old, possibly even abandoned (but still valuable) websites by using what is called quirks mode. This means that browsers will render different versions of HTML (including those pages that don’t declare which version they are) in old, nonstandard ways. Some browsers may even use quirks mode if they detect nonstandard code, regardless of the version the author declared. This is very important when you manipulate the layout of the page, as opposed to just the visual styling of text.

However, inconsistencies and bugs still exist. It is up to you, the author, to use the most modern standard, make sure you adhere to it, declare your standard in your document, and test your webpages in all browsers.

Is writing valid, accessible code hard?

No! Writing valid, accessible code, in combination with what are called best practices (most effective, efficient ways of working), actually makes your job as a web designer much, much easier! Here are a few generalities:

• Use the most modern version of the standard…XHTML 1.0 strict is usually the ideal way to go. (I will explain the relationship between the HTML language and XHTML coding soon.)
• Avoid framesets. A frameset is an HTML page that holds other HTML pages, each in its own frame. This allows parts of the webpage to be scrolled seperately. Non-graphical browsers cannot display the content at all, nor can cellphones, PDAs, assistive technology, nor very old browsers. Framesets confuse people if there are too many frames, or the frameset is badly-designed, or the user does not know how to print only the frame they want.
• Try to follow XHTML coding practices, meaning wherever an HTML version does not care how you do something, do it the “XHTML way” even if you are coding to a lower standard; XHTML is more strict about certain things (this is simple, and will be explained later).
• Avoid tables. If tables are absolutely neccessary to display specific, appropriate data, provide an alternative, non-tables version of that information.
• Avoid tags that are deprecated (to be phased out and not recommended) or non-contextual (not related to the meaning of the content); using them is a lazy way to style elements (and problematic from an accessibility viewpoint).
• Avoid using too many images, or images that are too large. They slow download times, a critical issue for vistors with slow connections.
• Provide alt text (alternative text) which will be shown in place of images and read to those using screen readers, or which will be displayed in a tooltip (pop-up text in a little box) to the viewer when he or she hovers the mouse over the picture.
• Do not use styles within individual tags when you can use stylesheets (style declarations coded at the beginning of a document, or in an external document, and which can be reused).
• Seperate content from style — use stylesheets. If you are incorporating dynamic (changeable) content via a server-side scripting language, consider using a templating system to keep the HTML seperate.
• Avoid JavaScript if you can, and never rely on it for required functionality or actual content. (JavaScript is a scripting language which can provide special effects, alter page elements “on the fly”, and provide extra functionality.) Visitors sometimes turn JavaScript off because it may be annoying, error-prone, badly-designed, or used for nefarious purposes. Because it can be turned off in a user’s browser, never, ever rely on JavaScript for validation (checking data for correct entry or malicious code before it is sent via a form to your email or your database).
• Do a prototype (mock-up, practice version) of a single or a few pages before you do all the pages on a multi-page website. When you are satisfied with the layout, navigation, and style, save a copy and rename it something like “TEMPLATE.html”. Strip all the changeable content out of the new copy…this will now be your template (basic code) to be reused on every page. For each new page, open up the template, save a copy under the new page name, and add all the unique content for that page (header text, images, and text).

I understand the accessibility/usability angle, but how do such practices make it easy for me?

In the long run, your website will be easier to maintain. You will need to re-write less code, and search/find features in your text-editor will be more reliable if you are consistent in your habits. Here are some specific examples:

• Seperating content from style makes it easier to:
• find mistakes
• make changes to content
• make changes to style, even more so if you control the style of multiple pages from one stylesheet
• avoid non-standard tags.
• Following XHMTL coding practices makes it easier to:
• upgrade the document’s standard later with less rewriting
• rely on search/find features in your text-editor
• avoid quirks mode
• avoid mistakes regarding tag nesting (the way some elements appear inside others)
• avoid non-standard tags, whether proprietary or just deprecated
• Avoiding tables:
• makes it easier to change content and layout
• avoids the all-too common disaster where you don’t understand how all your tables/cells are nested (webpage tables allow selected cells to “span” multiple columns and/or rows and to contain more inner tables), and where you may even make a cut/paste mistake and lose your layout or content while trying to change it
• avoids the nightmare where changes can only be made to pages one-by-one because content in pages is divided into tables — which, in addition to the problems above, can even result in discrepencies between pages because it takes you so many days (or weeks, or months) to update all pages that you don’t remember which files you changed or what you did
• Using prototypes and templates helps you:
• keep your entire site consistent
• seperate content from style

Okay, I understand this (I think). But first I need to learn HTML. Is it hard?

HTML is the easiest markup language you will ever learn. It is smaller and easier than specialty markup languages often used in publishing or typesetting. It is much easier than programming.