It’s pretty easy to explain to people why their web sites need certain kinds of standards; take, for example, Section 508, which is essentially the ADA for web sites. Section 508 says that any organization receiving federal funds (hmm…bailout companies, take note) must have an accessible web site. “Accessible” is further defined by specific criteria, but it mostly comes down to making web sites that can be used by the physically impaired.* People understand needing to modify something so everyone can use it equally, without unfair impediments.
However, it can be more difficult to explain why web sites should also be using coding standards. For example, how many people realize that HTML is actually deprecated (i.e., dead**)? HTML was replaced by XHTML and CSS. The last valid version of HTML was released in 1999–10 years ago! And, even if your site is using more current technologies, is it actually validated as standards-compliant? Just using XHTML/CSS is not the same as using valid XHTML/CSS. It’s the difference between having my dad poke at your engine and bringing the car to a certified mechanic.
If your library’s site is still using HTML or non-validated XHTML/CSS, it’s not just a matter of being a technological left-behind. Your site actually has some major issues you may not even be aware of. Here’s just a few:
- Older (non-standard) code can be a real obstacle for visitors using mobile devices. What’s the point of designing a cool iPhone app for your library if the entire library’s web site isn’t usable on the same device?
- Internet browsers come in all sizes, shapes, and levels of annoyance. Each browser has slightly different rules about how it chooses to render a site. If you look at your library’s site in Internet Explorer and then Firefox, chances are high they don’t look the same. Being standards-compliant can minimize these differences. Keep in mind also that sites often render differently in different versions of browsers. Try looking at your site in Internet Explorer 6 and then Internet 7. Make sure you’re sitting down first.
- You may actually be sucking up your visitors’ bandwidth. Standards-compliant sites tend to be cleaner and more compact, without gobbeldygook code soup on the back end. This means they tend to run faster. Don’t have broadband in most homes in your service area? Your library’s site on dial-up might be a nightmare for your patrons.
- Generally, you can’t have a site that’s accessible to people with disabilities without it also being code standard-compliant (although, alas, you can have the reverse). If you aren’t using standard code, rest assured that your site is not good for people using adaptive software like voice readers.
- Non-standard code actually hurts your search engine rankings. Sites that are standards-compliant are more friendly to those little Google robot spiders crawling through your site to index it.
What does this mean to me, Laura?
- If your site is running on HTML, it’s waaaay past time to bring it into the 21st century. <plug type=”shameless’>Contact us at OPLIN to find out how you can get on the waiting list for the Dynamic Website Kits, which are totally standards-compliant.</plug>
- If you’re planning a re-design of your library’s site soon, it’s critical that you take standards into consideration. The footloose-and-fancy-free “do whatever works” mentality won’t cut it anymore. To do otherwise can end up making sure that people using alternative browsers (e.g. Opera, Firefox), mobile devices or adaptive software don’t visit your library’s web site.
- You can use automatic online and free validators from the W3C (World Wide Web Consortium–they make the international standards for web stuff): Here is the XHTML validator and here is the CSS one.
*Yes, I know this is a very simple explanation. Want more?
**Yes, I also know that W3C is working on the HTML 5 spec. But I am not holding my breath for a quick release and, if you are, I might have a bridge to sell you.