Opera Developer News

Web design budgets are always tight but in economic downturns they tend to get slashed even further. One of the first things to get cut back, in my experience, is accessibility and user testing. The short term view seems to be that this is a outlay of cost that could be better used elsewhere and is a "nice to have".

I actually think quite the opposite. If you get it right at the start of a redesign or new build by including user feedback, especially feedback from users with disabilities, you're more likely to have a slicker, faster and more effective website than if you don't user test. And we all know what that means: better ROI, easier maintenance and a substantially bigger user base - all the things the money men like to hear about.

So far from this being a time to cut back on accessibility and user testing I think this is the very time to focus on getting your house in order; build an accessible site and you'll find you have a more usable one that demands less maintenance costs down the line.

So here are some of my recession busting tips for managing to produce an accessible site on a budget:

• User test with diverse users. If you can only test with a handful of user testers work with people with disabilities. Little will go unchecked with such diverse group and will give your sites a much more thorough test than if you use able bodied users as disabled users are far more likely to identify usability glitches that affect everyone. Just Ask: integrating accessibility throughout design by Shawn Henry (which is free) offers lots of practical advice on how to include diverse users in your user testing regardless of budget.
• Use web standards. Simple really but if you're building a site then use coding and programming languages as intended. That means anyone in your team, or new to your team, will understand your code and your web pages have a better chance of rendering correctly in across different browsers and devices. The Opera Web Standards Curriculum has a wealth of advice and soon the Web Standards Project (WaSP) will be launching their Web Standards Education Framework
• Validate your web pages. If you do this as you are building your web pages you will be making a huge step towards making web pages accessible. Validation does not equal accessibility and vice versa but both go a long way to supporting one another. Check out Opera's Debug menu and Opera Dragonfly for validation tools and error consoles
• Use graded browser support. If you want your web pages to be functional and readable across multiple browsers and browser versions with minimal fuss then check out YUI's graded browser support also recently referenced in the recently revised UK Government guidelines on browser testing. And if that isn't enough you can find even more practical guidance in the BBC's browser support standards.
• Use the Web Content Accessibility Guideline version 2.0 rather than 1.0. WCAG 2.0 is easier and clearer to use, contains test statements (known as Success Criteria), can be applied to all web technologies (and not just W3C technologies like WCAG 1.0) and comes with lots of supporting documentation. As an additional bonus WebAim just today published a handy to use checklist for WCAG 2.0 making it even more usable.
• Build code libraries. There's nothing to be gained from rewriting code and starting from scratch what has been done before. If you document accessible code snippets, templates, techniques and style guides as you go along they will then be there for the taking when new developers join the team or new sections of the site are added to. There are some great libraries out there that you can use that also offer accessible code. Check out our Opera Developer Community for solutions as well public code libraries such as Dojo and again YUI for accessible rich internet application solutions (WAI-ARIA).