November 9th, 2010
Government bodies and companies face the challenge of creating websites that are optimally accessible to people as well as browsers and search engines. There are internationally recognized agreements for creating accessible websites like WCAG. The Dutch government has assembled these international standards in a quality model called the Web Guidelines. This quality model mandates significantly better websites that are made for all people.
Before the end of 2010, all Dutch governmental websites must comply with this set of guidelines. The symbol on the left is the certificate displayed by sites that validate to all 125 guidelines. Recently, the ICTU, an institution founded by the Dutch Ministry of the Interior and Kingdom Relations that helps authorities to improve their ICT performance, decided to relaunch the Web Guidelines website using Drupal. The information on the new site (www.webrichtlijnen.nl / www.webguidelines.nl) is tailored to specific target audiences and the phases of an implementation. A developer or editor can now view the guidelines that are most relevant to him or her. The new site features case studies, best practices and success stories. It also offers a tool that can automatically check if a website conforms to 47 of the 125 guidelines.
Why choose Drupal?
ICTU had several reasons to select Drupal as their new CMS. The most important needs were:
- The website itself must comply with all 125 web guidelines. Because many proprietary CMS systems are (at least partly) closed source, it’s not always possible to validate to all guidelines using these closed source CMS systems. Drupal was not only chosen because its output already validates XHTML 1.0 Strict by default, but also because developers have full control over the code.
- ICTU preferred open source. The Dutch Lower Chamber announced that it considers the use of open standards and open source software by the government and the public and semi-public sectors to be important. This resulted in an action plan prepared by the Dutch semi-public organization NOiV (‘The Netherlands in Open Connection’) for the increased use of open standards and open source software in the public and semi-public sectors in the Netherlands.
- ICTU needed a future-proof solution with good support. By choosing Drupal, companies are excluded from vendor lock-in. Which means they can switch support partners if needed while keeping full control over their code. But even more important was that Drupal has a great and vibrant community they could rely on to provide support.
Our challenges while building the website
Because the Web guidelines are very strict – and not all Drupal modules adhere to these standards – some specific modules had to be developed instead of using contributed modules.
Note: the English translations of the guidelines have not been migrated to the new site yet. Therefore, when referring to specific guidelines, it links to the old website.
- Filter guidelines on terms. The guidelines state that URLs must be friendly (no query strings or incomprehensible terms in the URL). The Drupal way to filter by terms is by using Exposed Filters – which adds ampersands to the URL and makes it unusable for this project. In addition, the design needs checkboxes and tabs to filter guidelines instead of dropdowns (as Views uses). To get this working, we created the Termfilter module (described later on).
- Integrate the validation tool in Drupal. The validation script was written in PHP 4 a few years ago and still works fine. ICTU decided to re-launch the website in small steps, with the graphical design and the filtered guidelines having the highest priority. This meant that the tool was not ported to Drupal/PHP 5 (yet). It was not possible to integrate the PHP 4 application in Drupal without rebuilding it, so the HTML and CSS of the new design was also applied to the existing tool. The same goes for the wiki, which is currently built using MediaWiki. Migrating to Wikitools was out of scope of the current phase of the project, but this might be performed later on.
The site uses several content types like News Article, Web Guideline and Blog Post. A basic Page, which is used for the main content of the site, contains extra CCK fields. The body field is only used as a teaser for the page. For the main content, a CCK field (content) is used. Every page can have a subtitle as well, which is also a CCK field.
Menu block is used to generate a secondary menu in the left sidebar. CKEditor is integrated to ease the editing of content and combined with IMCE for inline images. The GeSHi Filter is used for syntax highlighting. Syntax highlighting is very important, because the site offers a lot of HTML/CSS code examples.
Filtering Web Guidelines on terms
Described as one of the challenges earlier in this article, Exposed Filters (part of the Views module) could not be used to filter the guidelines. That’s why a specific module was created that takes care of filtering, named Termfilter. With this module, nodes can be filtered on their terms using POST requests, so the URL stays intact.
It is also possible to use one vocabulary as a filter using radio buttons and one vocabulary to filter by using tabs. This last requirement is needed to display both the current guidelines (based on WCAG1) and the new guidelines (based on WCAG2), which are still subject of discussion.
The content type Web Guideline uses six taxonomies to group and subdivide content (Guidelines version, Role, Subject, Project phase, Advantages and Confirmation Level). The Termfilter module uses these vocabularies to filter, sort and display nodes. Using a combination of a browser cookie and a session cookie, the filter settings are saved to be restored when a visitor returns to the website.
We used Acquia Search (a hosted Solr solution) instead of Drupal core search, not only because of its powerful faceted search options, but also because it comes with several other cool extras like Sort and Suggestions and the ability to index the contents of documents. By doing so, we can offer multiple ways of finding content quickly and easily.
A large number of modules built by the Drupal community were used. Key modules include:
- Admin menu & Admin role
- Easier content administration for admins
- Menu Settings per Content Type
- Limit the menus to choose from while adding nodes
- Automatic Nodetitles
- Format the guideline title using a specific pattern
- IMCE & IMCE Mkdir
- Insert inline images in the content and manage directories
- Secure Pages
- Use SSL for certain parts of the website
- Features & Strongarm
- The only way to make DTAP manageable
- Get grip on the formatting of terms entered by admins/users (eg all lowercase)
- CCK and several submodules
- Couldn’t live without them
- Used to display a countdown clock on the top of the page. We had to make some changes to make it multilingual and such
- GeSHi Filter
- To enable Syntax Highlighting
- WYSIWYG Filter
- Input filtering specific for WYSIWYG editors
- Internationalization & Localization client
- For translation of the website to Dutch
- Views & Semantic Views
- We used Semantic Views to make accessible views without having to create loads of templates. Cool stuff!
Some stuff we built ourselves
- Termfilter: Used to filter nodes on their terms as described earlier. We plan to release this module in the near future.
- Block ID: We used Block Class to create our own Block ID module. Instead of
#block-block-news1we now have
#news. Much better.
- Banner rotator: Accessible image slideshow. Too specific to contribute.
The following people contributed to this project: