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
- Watchfire’s Bobby Validator for Standards and Accessibility – hardest to pass
- W3C Tidy Online
- Windows GUI Interface for TIDY
- Searchengineworld.com’s Validator
- Site Report Card Validator *****
- Valet Webthing.com
- The W3C’s HTML Validation Service *** (URL and upload)
- Watson Addy’s Validator
- Alpine Internet HTML Validator
- AnyBrowser’s HTML Validation
- Cynthia Says Validator
- Doctor-HMTL Validator *****
- HTMLvalidator.com’s Validator
- Website Test Tools and Site Management Tools (mostly paid, some free)
- Software QA and Testing Resource Center
- HTML Tag Checker
- W3.org Tidy Validator
- Cleans Your HTML Code to Shrink It
CSS – Validation
- W3.org’s CSS Validator (URL, upload, and direct paste in) *****
- Style-Sheets.com Validator (browser specific) ***
- W3C Style sheet validator
- WDG and HTMLhelp.com’s CSS Validator and Checker
- WDG Add-on CSS tool set for Win IE4.0x
Validation by Uploading Files – Validate From Your Computer
- W3.org’s CSS Validator (URL, upload, and direct paste in) *****
- Searchengineworld’s HTML File Upload Validator ***
- WDG and HTMLhelp.com’s CSS Validator and Checker (URL, upload, and direct paste)
- The W3C’s HTML Validation Service *** (URL and upload)
- HTMLHelp’s File Upload HTML Validator
Validators – Resources and Articles
- Fixing Your Website
- Mark Freeman’s Many Links to Validation Resources
- Squarefree’s Bookmarketlets (JavaScript for web page testing) *****
- Walidator.com
HTML – Articles about Validation
- Understanding How HTML Validators Work
- You Call That Website Testing?
- What Every Website Owner Should Know About Standards: A Web Standards Primer ***
Meta Tag – Validation
Size Does Matter – Web Page Size Standards
- 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?
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.
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
- Gazingus.org’s Validation Bookmarks
- NetMechanic’s Spell Check for Web Pages
- Pcman’s Web Page Screen Resolution Tester*****
Browser Statistics and Information
- Upsdell’s Browser News Statistics
- W3 Schools’ Browser Statistics and Trends
- Evolt’s Browser Archive
- The Counter’s Browser Global Statistics on Usage
Browsers – Validation
- Web Page Monitor (check for different sized monitors)
- AnyBrowser’s Website Viewer – How does your site look to other browsers
- Window Sizer – Check a page at various window resolutions
- AnyBrowser.org Developing Web Pages to Work for Every Browser
- Archive.org: Preserving the Internet Web Pages (Find old web pages)
- Bobby (checks sites for browser compatibility and disability access)
- Web Browsers Compatibility from Delorie
- Webmonkey – Browser Kit
- A Compendium of HTML Elements (browser compatibility lists)
- NetMechanic’s Browser Compatibility
- Learnwebdesign’s Browser References
- Public Lynx Access Browsers
- Checking with Multiple Browsers (the hard core way)
CSS – Media
- Code Style Media Monitor (projection, print, etc)
- Guide to CSS2 Support in PDA/Handheld Browsers
- pawgo.com’s Handheld Internet 101
- Pcman’s Free WAP Tools and Resources (WML/WAP Page Emulator)****
- How Can I Tell HTML Browsers from WML (Wireless) Browsers
- The Wireless FAQ (WAP, WML)
- W3C Mobile Access – Seamless Web Access From Mobile Devices
- W3C Mobile Access Activity Statement
- CSS Mobile Profile Test Suite
- W3C CSS Mobile Profile 1.0
- W3C HTML 4 Specs on Mobility – Handheld
- Aural style sheets
- The W3C CSS2 recommendation, Section 7: Media types
- Open Mobile Alliance for the Mobile Services Market
- Web Design for Mobility – Handheld, PDA, etc.
Ready to Add Content
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, , 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
- Creating an Accessibility Statement
- Review: International Compliant Style (IC-Style) Accessibility
- Accesskeys and Reserved Keystroke Combinations Chart
- Clagnut: Accesskey Standards
- Keyboard Access Information (UK Government Recommendations) *****
- Accessibility Statement and Resources
- A Primer for Accessible Web Pages
- Section 508 US Accessibility Law
- Checkpoints for Web Accessibility Guidelines
Access – Organizations
Access – Resources
- Accessible Web Authoring Resources and Education
- Designing More Usable Websites – massive links *****
- Designing More Usable Web Sites
- Accessibility Forum
- Makoa.org’s Accessibility Resources and Information
- The Accessible Web
- Alertbox: References on usability of web design
- Blindness-Related Resources on the Web and Beyond
- Accessible Web Page Design – Resources for the Visually Impaired
Access – Speech
- An Introduction to Speech-Access Realities for Interested Sighted Internauts
- EmacSpeak
- Introduction to the Voice, Your Aural Font – CSS Tutorial
Access – Validation
- Readability Of Websites With Various Foreground/Background Color Combinations, Font Types And Word Styles
- Vischeck (simulates color blind vision)
- Accessibility Checking Favelets (scripts)
- Bobby (checks sites for disability access and browser compatibility)
- Notes on Tools for Checking and Improving Web Page Accessibility
- HiSoftware’s Online Content Accessibility and Quality Tester
- Evaluation, Repair, and Transformation Tools for Web Content Accessibility
- W3C Web Accessibility Initiative: Evaluating Websites for Accessibility
- WaiZilla: Open Source Accessibility Testing
- WAVE Online Accessibility Tool Checker *****
Access – Color Blindness
- Can Color Blind Users See Your Web Page?
- Q42 Color Blindness Simulator
- Visibone’s Color Blind Color Chart
- Color Blind Web Filter – Testing Online
Access – Information and Resources
- UK Government Standards for Access Keys Implementation
- The Digital Talking Player – Download
- Arguments for Making your Site Universally Accessible
- UK Web Accessibility Center for Public Access
- Don’t Fake Your Markup Accessibility Issues for CSS
- How Alt Attributes Help Accessibility
- Five Site-accessibility Tips to Help Comply with Section 508
- Building Accessible Websites (online free book)
- Improving Website Usability and Appeal
- Improving Website Usability and Appeal
- Designing More Usable Web Sites
- Viewable with Any Browser Campaign
- Making Accessibility Accessible: The Reasons Organizations Don’t Have Accessible Websites
- Accessible by Design
- Dive Into Accessibility
- Dracos Accessibility Examples (using popular “inaccessible” Websites and redesigning them to be accessible)
- Inaccessible Website Demonstration
- Provide Clear Navigation Mechanisms
- Design Considerations: Readers with Visual Impairments
- Maccassibility Teaching Web Accessibility to Blind Students
- CSS Accessibility Problems: Is Markup Dead?
- Accountability of Accessibility and Usability
- Useit.com CSS and Usability
- W3C Device Independence Principles – Understanding Accessibility Issues
- Guidelines for Creating Accessible Websites
- Curriculum for Web Content Accessibility Guidelines 1.0
One Comment