with Lorelle and Brent VanFossen

Validating the Code Behind the Page

Checking Content
Begin your web page validation by checking the content of your page. It’s actually fairly simple. Is everything spelled correctly? Are the sentences compete? Is the grammar right? While this should be done at the time of creation, after you’ve messed around with the code for a while, you often have a fresh perspective on the content, so take another look to make sure it says what you want it to say, and it says it well and accurately. Many web pages flop due to horrible misspellings and simple grammar mistakes so easily fixed with today’s built-in spell and grammar checking programs. Take time to triple check the content to be sure.

Validating the code behind your web page or Website isn’t limited to a check to see if the HTML or CSS codes are right. You need to check the content of the page, test and verify accessibility, and thoroughly test your page under different viewing conditions in order to know if the design will indeed be accessible: visible and usable by everyone.

The order for checking and validating your pages should be:

  • Content
  • HTML tags
  • CSS codes
  • Accessibility
  • Links

Creating “accessible” web pages is not just a standard from the W3C Organization. It is considered a requirement by some search engines. Getting noticed means being “seen” by search engines, so do your best to meet their needs, too. Don’t limit your audience by creating limited pages. It’s not hard to make your page accessible, and it will help you in the future as the rules become more stringent on this topic.

By checking the content and basic coding, including the HTML and CSS style sheets, you are making sure the web pages can easily be read by others, no matter their software. After all, if your page is doing strange things because of screwed up bits of code, it makes it difficult to read and people will click away from you quickly. Checking for accessibility guarantees your page will be able to be read by not only any Internet browser software, but by anyone.

Just because a web page looks good on your screen doesn’t mean that all the coding is accurate or that it will look good on someone else’s screen. Begin by checking your page against the W3 validator. If you have left a tag without a closing or have too many tags that don’t match, or the elements within a tag aren’t right, these will show up in your validation report. Any little bugs in the CSS style sheets will also be found. To check your style sheets thoroughly, run it through W3’s CSS Validator separately. Fix and correct the mistakes and pass it through the tests again. When you get it right, the official validators reward you with an icon to post on your site to tell the world “I passed the test!” Don’t put this on every page on your site, but assign it to a nice “wall” on your “about us” or information page, just so those who are really interested in whether or not you passed can find it.

Most web page validators offer a link to help you understand what element is missing or needed to fix the code. About.com’s article about Using an HTML Validator discusses the most common errors to help you understand how to fix them if you need more information.

Different validators check for different problems. Some only check the HTML while others check both the HTML and CSS. There are validators to check your scripts, too. Some even check your layout to make sure all the containers are lined up as they should be and not spread all over the place overlapping, even though you can’t see it. Take the time to run your test pages through a variety of validation tests to catch all the little problems that might be there.

HTML – Validation

CSS – Validation

Validation by Uploading Files – Validate From Your Computer

Validators – Resources and Articles

HTML – Articles about Validation

Meta Tag – Validation

Size Does Matter – Web Page Size Standards

If you want to stay in the good graces of your visitors, the following are absolute NO-NOs:

  • Music or sounds
  • Flashing anything
  • Movement
  • Too many fonts
  • Too many colors
  • Things that go bump and twirl
  • Automatic Page Refresh

For more on what sucks on a web page and what not to do, check out:

A move is on by many web page designers to help their viewers upgrade to newer browsers by providing links to free newer upgrade versions, but the desire to keep pages visible to everyone, even those with old technology, continues, therefore you need to test your pages against the older browsers to see how they will look and if they will work.

Some validators even check your page’s tags to see if the code is backwards compatible, able to be viewed by older browsers. While Microsoft has announced it will stop distributing Windows 98 at the end of December 2003, new studies report that quite a few businesses (39%) and individuals are still using software that is at least five years old. Odds are that a good percentage of these are still using older versions of Internet browsers.

There are also validators and web page testers that emulate the various monitors and graphic card resolutions and sizes. It used to be that most pages were designed with a recommendation of “best viewed with 600×800 resolution” inviting users to tweak their screen quality to this standard. Unfortunately, few people knew how to change their screen resolution. Today’s hi-tech computers (52% of all Internet users) feature a screen with a much higher quality, but people still don’t know how to change the setting if it didn’t arrive that way! Many people use lower screen resolutions like a magnifier, thinking this helps them see the pages more clearly. A properly set up screen will ease headaches and eye strain.

If you are designing your site on a monitor at 1024×768 and higher (SVGA), take time to check how your pages will look when viewed at 600×800 or even down to 640×480. But don’t stop there! Consider how web pages are currently being viewed by everyone. Are people only surfing the Internet from their desktop computers?

One of our web pages viewed in a simulated screen size of a handheld computer screen It’s all very nice to have your web page be viewable at screen sizes from 640×480 to 1024×768, but can your web page be viewed when the screen size is two inches (5cm) square? Web pages are now being viewed on handheld computers and cell phones. Can your page design pass the cell phone test? What about WebTV? On a small, medium or wide screen television? Can it be viewed on all these devices without scrambling your pretty layout and design? Do the graphics stay in place or are they munched up, covering up the text or not even visible? You aren’t just designing for desktop computers anymore.

This is where the power of CSS or style sheets come into play. With a well-designed style sheet, you can take these different size issues and backward compatibility challenges on, easily overcoming them. By adding another style sheet or incorporating the specifics for the different media, you can easily make your web page viewable by all.

To help you understand how different software and hardware “see” web pages, we’ve provided a page showing the graphic examples of how your page might be viewed by different screen sizes, resolutions, as well as on a handheld computer or cell phone.

Example from CSS Zen Garden - visit for inspiration.external site The CSS Zen Garden site offers an excellent example of what well designed code can do. Volunteers have taken the exact same structure and content, well embedded with style tags, and created hundreds of different “looks” for the exact same content, simply by changing the style sheets. This is just an example of the power of a good style sheet.

After making all your changes and additions to meet the requirements of the different validators including looking backwards to ensure your page will work on a variety of browsers and monitor sizes and resolutions, run them through the primary HTML and CSS validators again to make sure that your “cleaning” didn’t create a few more little messes.

Tools – Validation

Browser Statistics and Information

Browsers – Validation

CSS – Media

Ready to Add Content

Awards for Effort
Most builders and construction companies are serious about meeting city building codes. The same dedication should apply when it comes to building web pages. Whether building a web page about a tree house or a skyscraper, part of the job of a web designer, from beginner to advanced and professional, is to meet the codes and design standards set up by the industry.

When you meet the W3 Organization’s standards, you get an award for your effort – an icon that says “I DID IT!” You can place it on your web pages to proudly state you have overcome the most difficult challenges to make your pages accessible to all and viewable by anyone.

When the structure (HTML) and presentation (CSS) codes passes the validations with he test templates, it’s time to start adding content. Before you add the text, make sure you have run it through the spell checker a few times, and have it proofed or passed through a grammar checker to make sure that your wording is correct. Many a user has been frustrated reading articles about how to serve up the best quality web product, and misspelled the word “Intrenet”, or left behind one of those common “from” or “form” mistakes. Proof your material thoroughly to make sure you are putting forward your best face.

If you are new to this, start slowly, with only a few articles, tips, and tricks, in addition to your gallery or product showcase. If you are experienced and have a web page already up on the web, it’s time to take the old content, put it through the wringer and incorporate it in your new page designs.

Again, upload only a few of the new pages and continue testing them through the various validators. Make sure they are working right with the new content. Sometimes a code is overwritten or misplaced during the copy and paste stages, resulting in the left side content sitting over on the right side of the page, and the right content smashed down at the bottom of the page. Take your time. After the first few pages are up and re-validated, then start adding more pages until you are confident that the process is working and you are secure with the coding.

your document. And make sure the content matches the use of those

Many times I’ve been so focused on the coding, I forgot to spell-check and really READ a document. I find out months, even years later, how a mispelled word or incorrect use of a phrase changed the whole content from what my goal was. Work hard to proof your material as much as you can before you post it. Have others read it and proof it for you. Keep the content concise but engrossing at the same time. The more effective your content, the more powerful the overall presentation will be.

The Accessibility Tests

While most HMTL validators test for accessibility, it’s time to really test your design for accessibility. W3’s Bobby is the most stringent of validators for accessibility requirements. It takes a lot of work to get the Bobby stamp of approval. It checks HTML, CSS, and links for accessibility. If any small detail doesn’t match its stiff requirements, you don’t pass. This is an excellent way to really test your web design skills. Understanding why it didn’t pass means learning about how the tags work together, enriches your skill level. Or so we like to tell ourselves. It’s hard work but worth it.

To meet accessibility requirements, every visual image must have a ALT or LONGDESC (long description) listed in its tag describing the image, especially if it is a graphic that replaces text. For example, Updated, the graphic shown here spells out the word “updated”. If you hold your mouse over the graphic, a tip balloon will pop up with the ALT description which is “updated”. If a user is reading your page with a speech program, it will automatically access the ALT and read the description of the image as:

For example, updated, the graphic shown here spells out the word "updated".

Not every image needs a description, but any important one does. All graphics must have an ALT tag to comply with the standards, an empty ALT tag would be:

<img scr="graphic.gif" alt="">

If the ALT is descriptive enough, you don’t need the long description. If you do need more of a description of the graphic, you have to have a LONGDESC file. This is an unformatted html file which contains a verbose description. Here is a well written sample graphic code:

<img src="ball.gif" align="right" width="100" height="300" longdesc="images/descrip/ball.html" alt="Picture of a pink ball bounced high in the air by a child.">

Longdesc from ball.html: "Photograph of a pink ball being bounced by a child, just out of visual range but with his hands showing and just a glimpse of a smiling face enjoying the pleasure of bouncing a ball on the sidewalk."

Links are not exempt from accessibility emphasis. While they don’t feature ALT tags, they do have TITLE tags. Be sure that every link is titled with a description so the browser can “read” the tag, describing where the link will go.

<a title="Taking Your Camera on the Road Learning Zone" href = "http://www.cameraontheroad.com/learn.html"> Learning Zone </a>

This is just a sample of the very basics for making your page accessible. In the links provided below you will find more information, as well as on our own Accessibility Policy page.

There are other validators for accessibility that you should run your pages through. Some provide testing for how your pages look when viewed under different browser settings for the visually impaired such as the browser-forced use of various foreground and background combinations (some dyslexics can read black text on a dark blue or purple background better than against a white background), font types and sizes (make sure your fonts are scalable to easily permit such size ranges), color blind issues, and the use of access keys (for non-mouse movement through a web page). Can your page be read and still look good as straight text with no graphics? Would Helen Keller be able to read your web page? We’ve put together a page showing examples of how a web page might look under some of these situations. Part of the magic of the World Wide Web is its accessibility to everyone, so make sure you take the time to ensure your pages are indeed accessible to everyone.

Access – Compliance Standards

Access – Organizations

Access – Resources

Access – Speech

Access – Validation

Access – Color Blindness

Access – Information and Resources

One Comment

  • Posted December 13, 2005 at 22:29 | Permalink

    Many thanks for this great list of web tools. I bookmarked it and will return over and over I am sure.

3 Trackbacks

  • […] Run a validation of the code on your site and fix any errors found. That often fixes a lot of the problems. […]

  • […] The page in the browser will be a “preview” of your post within your Theme. If you see something that needs fixing, make the change in the first browser window where you are editing your post, click Save and Continue Editing and then click over on the second browser window and do a complete refresh. You should see your changes. You can also run this page through a validator to check for errors. […]

  • […] We work overtime to keep our website as accessible as possible. When we find good information about accessibility design and standards, we like to bring it to your attention. […]

Post a Comment

Your email is kept private. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.