One of the main reasons for using a content management system (CMS) is that it can provide great advantages for future growth. Having the easy ability to extend your software to create new types of documents (as with WordPress’ custom post types), or to simply add new pages and new features without needing to scrap everything you currently have is a huge advantage.

However, much of that advantage can be lost through poor planning.

If you have any thoughts — at all — that you might want to add additional content to your web site in the future, it’s really not a bad idea to start planning right away when you’re building your web site. A little forethought now can save a lot of trouble down the road.

It’s not necessarily the case that your problem will be absolutely and insurmountably limiting — in fact, that’s extremely unlikely. It is very likely that it will be an inconvenience which will cost you time and money.

For example, let’s think about the most basic key element of your web site: the navigation. If you’re making changes to your web site which included adding, re-naming, or removing documents, you’re going to be making changes to the main navigation. With that in mind, does it make more sense to take the CMS navigation and style it to do what you need, or to remove it and replace it with a static menu that looks like you want it to?

Realistically, you can probably have it both ways — in my experience, a skilled web developer can take CMS output and make it look however you want. But I’ve certainly encountered many circumstances where that simply wasn’t what was done — which made later changes significantly harder than they needed to be.

This is just intended to be a quick post, so I’m not going to go into extensive details on all the possible ways that you can fail to plan for future changes on a web site — but I do want to make a few quick points:

• Unless you’re planning on your business failing, you should always assume that your web site will grow and change.
• Your web site will never be finished. It is a living document.
• You should always be prepared to simplify. Change is not always additive. Removing the right things can be a huge benefit.
• While building a new web site, it’s not at all unreasonable to ask your developer how much work it would be to change “x”, where “x” is something you may want to do next year. But it’s probably better to find out even sooner.

However much planning you do, not every change will be quick and easy. However, even though a complete redesign will always be a lot of work, adding a new page shouldn’t be.

I’m a firm believer that the first step to creating effective accessible web sites is to understand the nature of disability. Learning all the technological elements which can affect that accessibility is also necessary, but if you don’t understand why you’re employing the technology, you’re far more likely to make simple but costly mistakes.

My latest article, 10 Common Developer Mistakes, published at Ecommerce Developer, covers examples of some of those still-common mistakes which are fundamentally the result of a failure to understand how other people perceive and interact with your product.

What makes a web site inaccessible is your fault: your web site is not inaccessible because your visitor has a disability, it’s inaccessible because you have placed barriers on the site. These barriers are caused by a failure to understand how other people perceive or interact differently from yourself.

A self-focused perception of the world can be very damaging to accessibility or to usability. It’s not that you can’t build a great and even successful web site while primarily thinking of yourself as the user; but your site’s ability to cope with the needs and expectations of other users is greatly reduced if you aren’t able to understand how other people will interact with your web site.