Websites that behavelike business systems.

Scroll the table sideways to read it.

Three ways to have a website, and they are not three tiers of the same product. They cost different amounts, they fail differently, and the cheapest one is the right answer for a lot of companies.

A public website is the surface a regulator, a customer, and a procurement officer can all reach without asking anyone's permission. These are the requirements this service is designed around.

• AccessibilityWCAG 2.2 AA, plus AODA and the provincial equivalents, and the Accessible Canada Act where it applies

  What we design forEvery path completed with a keyboard and no mouse, every page read end to end by a screen reader, contrast and text sizing checked on the surface we shipped rather than in the design file, reduced motion honoured with a still version that still communicates, and forms whose errors are readable and recoverable.

  What we document for your counselThe test results per template, the standard tested against, and the date. So a barrier report can be answered with a measurement, and so a procurement questionnaire can be answered from a document instead of from memory.

• PrivacyPIPEDA, Quebec's Law 25, and the provincial private-sector statutes where they apply

  What we design forA stated purpose for every piece of data the site collects, the smallest set of fields that does the job, consent captured before analytics and marketing scripts run rather than after, retention set per record type rather than left at a default, and a cookie preference surface that actually changes what loads.

  What we document for your counselWhat the site collects, where it is stored, which processors see it, who internally can reach it, and how long it is kept.

• LanguageQuebec's Charter of the French Language, where the business operates there

  What we design forPer-language authoring as a first design decision rather than a translation pass at the end, which means the content model, the layout, the URLs and the search research are built for it from the start. Customer-facing text is authored per language, including the forms, the error messages and the automated acknowledgement.

  What we document for your counselWhich surfaces are authored per language and which are not yet, so the gap is a list somebody owns rather than a surprise.

• Electronic messagesCASL, for anything the site sends or subscribes somebody to

  What we design forConsent and its basis recorded against the record at the moment it is given, no pre-ticked boxes, an unsubscribe that works in one action, and the identification and contact information the legislation asks to be present in a commercial message.

  What we document for your counselThe consent basis per subscriber and the send log, which is the evidence the legislation asks you to be able to produce.

• Where the data livesAnd which processor sees it

  What we design forThe hosting region, the form processor, the analytics processor and the email processor named in the scope before the build, chosen rather than inherited from a default.

  What we document for your counselEach processor, what it sees, the region it sees it in, and what changes if you move region later.

Where the business also operates in the United States, the equivalent requirements are named in the scope.

HUREAL designs to a standard, tests against it, and documents what was built. The determination belongs to your counsel or your privacy officer. Our own accessibility target and how to report a barrier are on the accessibility page.

• Who writes the content?

  We do, from your material, your people, and the questions your sales team already answers. You review every word before it ships. If you have a writer you like, we work with them and supply the structure, the brief, and the search research.

• Can our marketing team change it afterwards without a developer?

  Yes, and that is a design requirement rather than a feature. The content model is built around your actual content types and your approval flow, and your team is trained on it before launch day.

• What moves the price of a build?

  How many systems it connects to, how many languages are authored natively, whether customers log in, and whether anything has to be migrated. Not how many pages you want. The full list of what moves a price is published in Insights.

• Will we lose our rankings when we move?

  Not if the redirect map is done properly, and it is a named step before launch rather than a task somebody remembers. Every old URL points at its new home, internal links are updated to match, and the map is a deliverable you can check.

• Do we have to move off our current content system?

  Often not. The system holds the content and the templates decide what a visitor experiences, so in a lot of projects the sensible scope is new structure, design, and templates on what you already run. If a move really is warranted, you get the reasoning in writing before you decide.

• Can we launch in English and add French later?

  Yes, and it costs less that way than retrofitting a translated layer, because the structure is built for a second language from the start. Adding it becomes authoring and review rather than a rebuild.