A government website has to help people finish real tasks: finding a benefit, understanding a requirement, or submitting information in their preferred official language. Drupal WxT can provide a useful starting point for that work. Choosing it still requires decisions about content, accessibility, hosting, and long-term ownership.
This guide explains what WxT brings to a Canadian public-sector project and what a delivery team should establish before building or migrating a site.
Understand Drupal, WET, GCWeb, and WxT
These names describe related parts of a platform. Drupal provides the content management system. The Web Experience Toolkit, usually shortened to WET, provides reusable web components. GCWeb is the Canada.ca theme built on WET. Drupal WxT brings Drupal together with this ecosystem and additional site-building capabilities.
The WxT project describes a distribution focused on multilingual, accessible, usable, and interoperable websites. It has a community that includes Canadian government participants. That makes it relevant to departments and agencies evaluating Drupal, but it does not mean every federal website uses WxT or that every public-sector project needs the full distribution.
Start with the service and publishing requirements
Before choosing a theme or installing modules, write down the public tasks the site must support. A department publishing policy guidance has different needs from a transactional service collecting applications. Separate those tasks from internal preferences about how the homepage should look.
- Content: identify page types, documents, taxonomies, search needs, and retention responsibilities.
- Languages: define which content requires translation, who approves each language, and how changes remain synchronized.
- Accessibility: record the required standard, testing approach, and who can approve remediation.
- Integrations: list identity providers, forms, search services, analytics, and external systems.
- Operations: agree hosting, monitoring, backups, incident response, and release ownership.
Use this inventory to compare WxT with a smaller Drupal implementation. The WxT architecture documentation describes a modular approach with optional extensions. Evaluate the features your project will actually use and the dependencies your team can maintain.
Design bilingual publishing as a workflow
A language switcher is only the visible part of a bilingual service. Editors also need a clear process for creating translations, reviewing updates, and deciding what happens when one version is ready before the other.
Test a complete journey in both languages: navigation, search, forms, confirmation messages, error pages, and linked documents. Check that changing language takes a visitor to the corresponding content when available. The Canada.ca language-toggle pattern provides specific guidance for that interaction.
For example, if an editor changes an eligibility deadline in English, the workflow should make the French version's review status visible. A translated page that quietly retains an old deadline is an operational problem even when both pages look polished. Give each content type a translation owner and include translation checks in release acceptance.
Treat accessibility as ongoing delivery work
Reusable components can reduce repeated implementation work. They cannot guarantee that a finished site, its custom features, or its documents meet the required accessibility standard. Content choices, component configuration, and later editorial changes all affect the experience.
- Navigate menus, dialogs, and forms using a keyboard, with a visible focus indicator.
- Check heading order, link purpose, alternative text, and understandable form instructions.
- Test error identification and recovery, including how assistive technology announces errors.
- Inspect zoomed and narrow-screen layouts, contrast, and text that expands in translation.
- Include downloadable documents and embedded third-party services in the review.
Combine automated checks with manual testing and representative user tasks. Record issues with a reproducible example and an owner. Our Drupal accessibility service and accessible content guide cover complementary parts of this work.
Install and update through a reproducible process
Check the supported Drupal, PHP, and dependency versions for the WxT release you select. Use the project's Composer instructions so its dependencies are included; copying a profile directory is not a complete installation. The WxT update guide explains its Composer-based update process.
Build the selected configuration in development, export it to version control, and test the same dependency lock file on staging. Keep custom code separate from contributed code. For every update, exercise both language journeys, editorial permissions, search, and the forms your service depends on. Record custom patches and their upstream issues so the next upgrade has a clear starting point.
Plan migration and ownership together
For an existing site, map old URLs, content identifiers, translations, documents, and redirects before moving data. Test a small representative migration first: a bilingual page, a document-heavy page, a form, and content with restricted access. Compare the result with the original and let editors try their normal tasks.
Finish with a support plan that names responsibility for security updates, translation reviews, accessibility fixes, and recovery tests. A well-organized handover gives the next team evidence of what works and a practical way to keep it working.
Planning a public-sector platform? Explore Druproid Support's government Drupal services or discuss your WxT requirements with us.