If you are about to redesign your website, now is a good time to focus on getting a website that can be used by as many people as possible. Here are some tips on when and how to make requirements and focus on accessibility throughout the redesign process.

Requirements specification

When you are writing your accessibility requirement specifications your web development team, it is important that you use the right standards. The best standards are the international guidelines for accessibility outlined by WCAG. In web design projects, it's fairly common for the buyer to request that the website be designed in conformance with WCAG 2.0 on level AA, however this requirement may not be as straightforward as it would appear at first glance. Halfway in the redesign process, how will you determine whether or not the website meets your expectations? My recommendation is that you explicitly state the individual success criteria which you wish to have compliance with. Have your website developer state if and how this is going to be complied with. Define the following, in a table or similar, for each accessibility criteria relevant to your new website:

  • Reference to criteria: 1.1.1
  • Description of criteria: Non-text Content: All non-text content that is…
  • Notes on criteria: This is relevant for images, …
  • Developer's field for description of solution: Leave blank for developer to fill out.

Do the same for all the criteria. You can also state, if a criteria is an ultimate requirement or a desirable requirement.

It's also important that the CMS used to build the website helps web editors publish accessible content. Make requirements on how this should be ensured. You can pick the necessary check points from the guidelines on accessible authoring tools

ATAG (these guidelines dictate that the tool generates accessible web content, helps web editors to publish accessible content, and that the tool itself is accessible). In my experience, you'll want to explicitly state requirements for:

  • how to handle alternative texts for images;
  • how to use headings;
  • how to create accessible data tables;
  • how to make quotes (< q > and < blockquote >);
  • how to enter page titles;
  • how the HTML code created by the CMS complies with the W3C standards;
  • how to tag change of language in the text entered

Consider also your organization's design manual and if there are any contradictions with the accessibility guidelines. For example there are specific accessibility guidelines on the contrast ratio between background and text colours. For this reason it is important to use 'accessible' colour combinations.

Design and development

A handful of the accessibility criteria are relevant when starting the phase of designing and doing wire frames. Think about navigation, the use of headings, colours, link texts and descriptions in places where the user is supposed to click, fill out, or choose content.

When it comes to the process of development, most of the accessibility criteria are relevant. Therefore it is important that the people developing the solution have a solid understanding of accessibility. Make sure you test the solution during the process from start to finish. Do not wait until the acceptance test. By then it's nearly impossible task to correct possible errors and shortcomings before the site goes live. It's especially important that the templates for different pages are tested as early as possible before building on them, to avoid spreading mistakes to hundreds or thousands of pages.

Publishing content

Make sure you train web editors on how to publish content the 'accessible way'. This way, when content is added both in the development phase and after you've launched, it furthers your site's accessibility rather than introducing new accessibility issues.

Media players, forms, and old content

Areas often being neglected include integrations with third party solutions, such as media players and forms. Remember these in the process. They should also be accessible!

Also think about content being migrated from the old system into the new. The WCAG specifications differ between HTML/XHTML versions. There might also be content from the old system that is not accessible. After all your hard work, the last thing you want is to carry old problems over to your new website.


To learn about all the aspects of the redesign process, download the guide "The 7 Phases of a Website Redesign".

Get the guide: The 7 Phases of a Website Redesign

More about website redesign

Blog post: 9 Ways to Keep Your Search Rankings During a Website Redesign. 

Blog post: Use Analytics Data when Planning Your New Website.