WET: a government front-end toolkit for accessible, multilingual sites

Five goals, and the first one decides the audience

The Web Experience Toolkit is described as an open source code library for building innovative websites that are accessible, usable, interoperable, mobile-friendly and multilingual, and it is a collaborative project led by the Government of Canada. The README calls it an award-winning front-end framework, and it is also a collection of flexible and themeable templates and reusable components.

The five-word list is the product specification. A toolkit aimed at a general commercial audience would not put accessibility first, would not treat multilingual support including right-to-left scripts as a headline feature, and would not be run by a government department. The audience is public sector teams, where the requirements are accessibility regulation, official languages, shared design across departments, and the need for a component library that a dozen teams can all use without inventing their own.

The collaboration model is spelled out in the same section. The project is managed openly on GitHub, with discussion through the issues tracker, and external contributions are welcome in the form of pull requests, design patterns, issues and suggestions, documentation and testing. There is a multi-level review process combining automated and manual reviews to ensure code integrity, which is a reasonable way to handle the fact that the reviewers are partly government staff and partly volunteers.

The benefits section is also candid about the motivation, which is to reduce costs by openly sharing and collaborating, to avoid duplication of effort and to produce better quality results. That is the argument for a shared framework, and it is the reason a government built one.

Accessibility is the claim with a standard attached

The accessibility bullet points are the most concrete in the README, and they are the reason many teams look at WET at all.

The toolkit conforms to WCAG 2.0 level AA. It leverages WAI-ARIA to further enhance accessibility, and it has been tested with assistive technology through an Access Working Group.

The WCAG 2.0 reference is worth pausing on, because it dates the work. A conformance claim against a specific version of a standard is only as good as that version, and the 2.0 specification is the one that preceded 2.1 and 2.2. For a team with a regulatory obligation, the question to ask is which version of the standard their obligation names, and whether the toolkit's claim covers it.

The usability and interoperability claims are softer but still concrete. The design approach is iterative, with design patterns and usability testing through a User Experience Working Group. Interoperability is an HTML5-first approach that leans on native HTML5 support and fills support gaps with polyfills, with a wide variety of browsers targeted, Edge, Firefox, Chrome, Safari and Opera, and support for HTML data through RDFa 1.1 Lite and Schema.org, which is how the metadata that governments publish can be machine readable.

The mobile story is the usual set of claims adapted to a public sector, adapting to different screen sizes and device capabilities, touchscreen support, optimised for performance and building support for device-based mobile applications.

Thirty-four languages, and the ones that are hard

The multilingual claim comes with a full list, and the list is more informative than the count. The toolkit currently supports 34 languages including right-to-left ones: English, French, Afrikaans, Albanian, Arabic, Armenian, Bulgarian, Chinese, Chinese Simplified, Czech, Dutch, Estonian, German, Greek, Hindi, Hungarian, Icelandic, Indonesian, Inuktitut, Italian, Japanese, Korean, Latvian, Lithuanian, Polish, Portuguese, Portuguese Brazilian, Russian, Slovak, Spanish, Thai, Turkish, Ukrainian and Vietnamese.

Two of those entries tell the story of who this is for. Inuktitut is an Inuit language of northern Canada, and Arabic and Persian-style right-to-left handling is the hard case in any layout system. A toolkit that ships a right-to-left language correctly has solved the mirroring problem that most front end frameworks leave to the application.

The build reflects that this is a first-class concern rather than an afterthought. The package.json carries an update-i18n script that runs node script/i18n.mjs, and the repository has a script/ directory, so the translations are part of the build pipeline rather than a set of hand-edited files.

For a multilingual government site, the practical value is that a translation team is not left translating a layout, since the templates already carry the language-specific structure.

Themes, plugins, widgets and the CMS variants

The themeable and reusable section is what makes the toolkit usable rather than merely compliant. The framework supports custom themes and includes support for two different themes, and it ships reusable templates, plugins and widgets.

The variant list is the part that decides whether the toolkit fits your stack. The toolkit has been adapted to various CMS and programming frameworks, which are Drupal, WordPress, SharePoint which is in development, DotNetNuke also in development, PHP, SSI, and Java with Maven.

The wording about SharePoint and DotNetNuke being in development is worth a second look for anyone in that world, because it means the integration exists in some form but is not finished, and an unfinished integration is a support commitment you take on.

The key resources listed in the README are the documentation, the downloads, the examples, the version history and the roadmap, the terms and conditions, the source repository with its contributing guidelines, a communications material page, and a list of websites using WET. That last one is the most useful page for a team doing an evaluation, since it shows what the toolkit looks like in production rather than in a demo.

A Grunt and Rake build with an i18n script

The build tells you what kind of project this is, and the answer is not a modern JavaScript toolchain.

The package.json names the package wet-boew at version 4.0.98, requires npm 10.7.0 or newer, and defines three scripts. The test script is grunt pre-mocha followed by node test-runner. The prepare script is grunt prepare, and the update-i18n script runs node script/i18n.mjs.

The repository has both a Gruntfile.coffee and a Rakefile, which is a fair summary of a project that predates the current tooling conventions and has kept its build while its dependencies were updated in place. The tests are run through a custom test-runner.js rather than through the package's own test script, and the repository has a .bowerrc and an .actrc, the configuration files of two package managers that are no longer common.

The dependency list is the other half of the story. jquery is pinned at 2.2.4, which is old by any measure, along with jquery-validation, bootstrap-sass 3.4.3, datatables.net, dompurify for sanitising, openlayers for maps, proj4 2.22.0 for coordinate systems, flot for charts, magnific-popup, code-prettify, jsonpointer.js and fast-json-patch, the last three with a mix of upstream and forked versions. Several of those are GitHub forks of the original projects, which is how fixes get in without waiting for an upstream release.

The browserslist field says last 2 versions, bb >= 10, Firefox ESR and ie > 10, which is a deliberate and dated statement of what the toolkit supports.

MIT, Crown Copyright and a wordmark you may not use

The licensing section is where a toolkit like this differs from a typical open source project, and the README is precise about it.

Unless otherwise noted, the source code of the project is covered under Crown Copyright, Government of Canada, and is distributed under the MIT License. So the code is permissive in the usual way, and there is a licence file in the repository along with a French version of the terms, Licence-fr.txt, which is what you would expect from a bilingual federal project.

Then the second half, which is easy to miss and expensive to get wrong. The Canada wordmark and related graphics associated with this distribution are protected under trademark law and copyright law, and no permission is granted to use them outside the parameters of the Government of Canada's corporate identity program, with a link to the federal identity requirements.

In other words, a department can use the toolkit, a contractor can use the toolkit, and a Canadian company can use the toolkit, but the maple leaf does not travel with the code. A designer who copies the header graphic from the demo into a commercial site is infringing, and the distinction between the code and the marks is precisely the thing the licence section exists to draw.

There is also a SECURITY.md, a CODE_OF_CONDUCT.md, a CONTRIBUTING.md and a Rakefile, which is the ordinary apparatus of a project with contributors and a disclosure process.

Where WET is the wrong choice

The first wrong-tool case is a product team that wants a modern component workflow. The build is Grunt and Rake, the JavaScript base is jQuery 2, and the tests run through a custom runner. That stack is coherent inside a public sector context where a dozen teams share a standard and long-term maintenance matters more than tooling currency, and it is a mismatch for a team that would rather use a bundler and a current framework.

The second is a project outside Canada with no public sector obligations. The value of WET is its accessibility and bilingual machinery, and if your organisation does not have the corresponding regulatory pressure, the same requirements can be met with a smaller, more modern toolkit.

The third is a team that wants to ship quickly with an existing design system. WET brings its own themes, its own plugins and its own widgets, and adopting it means adopting those, including a visual language that was designed for government services. Retrofitting it around an existing brand is a project in itself.

And there is the version question. The release list shows v4.0.98 from October 2026, v4.0.97 from July and v4.0.96.3 from June, so the project is alive, but a 4.0.x line that has been going for a long time is a sign of a stable rather than a fast-moving toolkit, and the WCAG 2.0 conformance claim should be checked against the standard your own obligations name.

Editorial conclusion

Adopt WET if you build public sector sites where accessibility conformance, bilingual delivery and a documented component library matter more than a modern build toolchain, and start from the downloadable package rather than from the source tree. Do not adopt it for a product team that wants a modern component workflow, since the build is Grunt and Rake with jQuery 2 at its core, and do not use the Canada wordmark or the related graphics, which are protected separately from the code. Before you deploy, read the terms and conditions page and check the current version, since the project ships frequent point releases and the accessibility claim is tied to a specific WCAG version.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. wet-boew/wet-boew on GitHub