Web development basics
27 March 2006
Those of us who design and build for the web have witnessed some exciting changes in our field over the past few years. We've seen traction in the web standards movement, a spreading commitment to accessibility, the growth of web services, the emergence of Ajax, the development of time-saving code frameworks and libraries, and more. But how does it all fit together? As we pursue the next new and exciting development, how do we avoid taking for granted the amazing infrastructure all these changes have left us with?
Whenever I start a new project -- and from time to time during ongoing ones -- I take a step back to review the web development basics. What priorities should guide my work? Given the landscape of ways the web is accessed today, what core design and development requirements should I meet? What advice would I give to others in the same situation?
Well then, here are a few recommendations, for myself and those like me. This discussion will be mostly about front-end technical priorities, so the main back-end/infrastructural recommendation I'd make is to use systems (like Drupal for content management, say) that don't unnecessarily get in the way of realizing your front-end goals. For example: don't use a CMS that inserts invalid code into your documents!
Above all else, make sure that your site declares a document type (preferably at least XHTML 1.0 Strict) and that its HTML and CSS validate against the W3C's validators. As I've discussed before, this is simply the best way to keep your code lean and maintainable, and it sets an essential foundation for everything else I'm about to describe.
Beyond that core of valid markup and CSS, your site should also meet web accessibility guidelines and standards, such as the W3C's Web Content Accessibility Guidelines and the federal government's Section 508 standards. You can use various tests to check your site's compliance to these guidelines and standards.
But what's actually far more important than letter-of-the-law adherence to those guideline checklists is that your site really is designed and developed, from the beginning, with accessibility in mind. Keep the interface simple; organize and order content logically and meaningfully; and make sure the site makes sense in alternate browsing devices, like screen readers. On a markup level, this would mean direct, uncluttered code that's structured into semantically meaningful elements like headings, paragraphs, and lists rather than lots of meaningless divs and spans -- or worse, presentational elements like nested layout tables, hr tags, and images that contain text. Plus, if you use markup correctly, the site will not only be more accessible, but it will tend to rank higher in search engine results as well. I've found that Dive into Accessibility among others can help keep you on track when it comes to these sorts of common sense, real-world accessibility strategies. Example: a "skip to main content" link is important if your site includes a list of navigational links at the top of each page. Many major sites still don't have one.
And that about sums it up. Yes, of course there's so much more beyond this. But I've found that resisting compromise on these basic guidelines helps keep projects sane and sites usable, even as the web continues to evolve in newer, more exciting directions.
« Previous post | All posts | Next post »