Government of Ontario Web Standard
Version : 2.7
Prepared for the Information Technology Standards Council (ITSC) under the delegated authority of the Management Board of Cabinet
Government of Ontario reserves the right to make changes in the information contained in this publication without prior notice. The reader should in all cases consult the Document History to determine whether any such changes have been made.
Â© 2010 Government of Ontario. All rights reserved.
Other product or brand names are trademarks or registered trademarks of their respective holders. This document contains proprietary information of Government of Ontario, disclosure or reproduction is prohibited without the prior express written permission from Government of Ontario.
|Template Name||Template #||Template Version No.||Template Author||Template Completion Date|
|GO-ITS Template||09.03.26||2.0||Design: PMCoe
|2009-11-25||V1 draft prepared by Working Group and reviewed by the Web Coordinators Committee|
|2010-01-22||V2 draft prepared and ready for consultation|
|2010-01-29||V2.1 draft prepared and ready for approval|
|2010-02-10||V2.2 draft prepared with edits from Security, GSDC, CCAS, OCIPO|
|2010-02-17||V2.3 draft prepared with edits from the Web Coordinators Committee|
|2010-03-24||V2.4 draft prepared with additional comments from OCIPO|
|2010-05-07||V2.5 draft prepared based on feedback from ITSC|
|2010-06-29||V2.6 draft prepared based on feedback from ITSC Chair during June ITSC meeting|
|2010-08-16||V2.7 draft prepared based on feedback from ITSC following June meeting|
|2010-09-13||Endorsed: IT Standards Counsil endorsement|
|2010-09-30||Approved: Architecture Review Board approval|
2.1. Background and Purpose
2.2.1. In Scope
2.2.2. Out of Scope
2.3. Applicability Statements
2.3.2. Other Applicability
2.4. Requirements Levels
2.5. Contact Information
2.5.1. Roles and Responsibilities
2.6. Recommended Versioning and/or Change Management
2.7. Publication Details
2.8. Compliance Requirements
The web is, for a rapidly growing number of Ontarians, the preferred communications and service delivery channel.
As a number of different areas are responsible for diverse aspects of successful website development and management, this standard refers to other authoritative documents relating to the web such as legislation, directives, policies, guidelines, other GO-ITS standards and regulations. (See: Appendix)
This standard defines directions in the areas of corporate functionality, accessibility, usability, look and feel, and responsibility for Government of Ontario websites:
The objectives of the standard are to:
This standard can be used in association with the resource called “Techniques for Implementing the GO-ITS 23 Web Standard” found on OPSpedia intranet site.
This standard applies to both internal and external Government of Ontario websites (See: Glossary), regardless of hosting location. Mandatory and recommended elements may be different for Internet and intranet sites. The scope of this document is not limited to the current or named technologies. This standard also covers the use of third party web services. Questions or clarifications about the applicability of this standard should be directed to the Standards and Guidance Coordinator in the Government Services Cluster (Web Coordinators Committee Co-Chair).
Back office and administrative interfaces (e.g. human resources, financial administration or content management contribution interfaces) are not in scope.
Government of Ontario IT Standards and Enterprise Solutions and Services apply (are mandatory) for use by all ministries/clusters and to all former Schedule I and IV provincial government agencies under their present classification (Advisory, Regulatory, Adjudicative, Operational Service, Operational Enterprise, Trust or Crown Foundation) according to the current agency classification system.
Additionally, this applies to any other new or existing agencies designated by Management Board of Cabinet as being subject to such publications, i.e. the GO-ITS publications and enterprise solutions and services – and particularly applies to Advisory, Regulatory, and Adjudicative Agencies (see also procurement link, Ontario Public Sector/Broader Public Sector Client Definition from MGS). Further included is any agency which, under the terms of its Memorandum of Understanding with its responsible Minister, is required to satisfy the mandatory requirements set out in any of the Management Board of Cabinet Directives (cf. Operational Service, Operational Enterprise, Trust, or Crown Foundation Agencies).
As new GO-ITS standards are approved, they are deemed mandatory on a go-forward basis (Go-forward basis means at the next available project development or procurement opportunity).
When implementing or adopting any Government of Ontario IT standards or IT standards updates, ministries and I&IT Cluster must follow their organization’s pre-approved policies and practices for ensuring that adequate change control, change management and risk mitigation mechanisms are in place and employed.
For the purposes of this document, any reference to ministries or the Government includes applicable agencies.
This standard applies to work provided by vendors. Third party service providers who are hired to develop websites are required to adhere to this standard and sign a procurement agreement.
Multi-jurisdictional sites must meet all aspects of this standard, with the look and feel to be determined by agreement of the partners.
Within this document, certain wording conventions are followed. There are precise requirements and obligations associated with the following terms:
|Must||This word, or the terms “REQUIRED” or “SHALL”, means that the statement is an absolute requirement.|
|Should||This word, or the adjective “RECOMMENDED”, means that there may exist valid reasons in particular circumstances to ignore the recommendation, but the full implications (e.g. business functionality, security, and cost) must be understood and carefully weighed before choosing a different course.|
See: Glossary for more useful definitions.
Accountable Role Definition
The individual ultimately accountable for the process of developing this standard. There must be exactly one accountable role identified. The accountable person also signs off as the initial approver of the proposed standard before it is submitted for formal approval to ITSC and ARB. (Note: in the OPS this role is at a CIO/Chief or other senior executive level)
|Title:||Head, Web Stewardship and Ontario.ca Branch|
|Ministry/Cluster:||Ministry of Government Services|
|Division:||Government Services Cluster|
Responsible Role Definition
The organization responsible for the development of this standard, There may be more than one responsible organization identified if it is a partnership/joint effort. (Note: the responsible organization provides the resource(s) to develop the standard)
|Ministry/Cluster:||Ministry of Government Services|
|Division:||Government Services Cluster|
|Branch:||Web Stewardship and Ontario.ca Branch|
Support Role Definition
The support role is the resource(s) to whom the responsibility for actually completing the work and developing the standard has been assigned. There may be more than one support role identified. If there is more than one support role identified, the following contact information must be provided for each of them. If there is more than one support role, the first role identified should be that of the editor â€“ the resource responsible for coordinating the overall effort.
Support Role (Editor):
|Ministry/Cluster:||Ministry of Government Services|
|Division:||Government Services Cluster|
|Branch:||Web Stewardship and Ontario.ca Branch|
|Section:||Enterprise Web Development|
|Job Title:||Standards and Guidance Coordinator|
Name: Susie Floresco
The above individual will be contacted by the Standards Section once a year, or as required, to discuss and determine potential changes and/or updates to the standard (including version upgrades and/or whether the standard is still relevant and current).
Please indicate who was consulted as part of the development of this standard. Include individuals (by role and organization) and committees, councils and/or working groups.
(Note: consulted means those whose opinions are sought, generally characterized by two-way communications such as workshops):
|Organization Consulted (Ministry/Cluster)||Division||Branch||Date|
|Cabinet Office||Communications||Strategic New Media||2010-02-10|
|Ministry of Government Services||Corporate Security||2010-02-10|
|ServiceOntario||e-Channel Branch and Marketing Branch||2010-02-10|
|Committee/Working Group Consulted||Date|
|Web Coordinators Committee||2009-11-25 and 2010-02-17|
|GO-ITS 23 Working Group||May-November 2009|
|IC Issues Working Group||2010-02-04 and 2010-02-18|
Please indicate who was informed during the development of this standard. Include individuals (by role and organization) and committees, councils and/or working groups.
(Note: informed means those who are kept up-to-date on progress, generally characterized by one-way communication such as presentations):
|Solutions Development Leadership Committee||2009-10-07 2010-04-29|
|Committee/Working Group Informed||Date|
|Technical Architecture Domain Working Group||2010-04-26|
Changes (i.e. all revisions, updates, versioning) to the standard require authorization from the â€œresponsibleâ€ organization.
Once a determination has been made by the responsible organization to proceed with changes, the Standards Section, Technology Adoption Branch, OCCTO, will coordinate and provide assistance with respect to the approvals process.
The approval process for changes to standards will be determined based on the degree and impact of the change. The degree and impact of changes fall into one of two categories:
Minor changes – requiring communication to stakeholders. No presentations required. No ITSC or ARB approvals required. Changes are noted in the â€œDocument Historyâ€ section of the standard;
Major changes – requiring a presentation to ITSC for approval and ARB for approval (Note: ARB reserves the right to delegate their approval to ITSC)
Below are guidelines for differentiating between minor and major changes:
The web is an area where new technologies are emerging rapidly; this standard should be revised every 3 years to ensure its currency, or prior to that time if required by changes to technology or infrastructure.
This standard is owned by the Web Stewardship and Ontario.ca Branch under the custodianship of the Standards and Guidance Coordinator (Co-Chair of the Web Coordinators Committee).
Revisions to the standard are managed and led in consultation with the Web Coordinators Committee. All inquiries or clarifications on this standard should be directed to the Co-Chairs of the WCC. Each ministry and cluster must participate in the WCC (See: 3.2.1 Reporting Requirements).
All approved Government of Ontario IT Standards (GO-ITS) are published on the ITSC Intranet web site. Please indicate with a checkmark below if this standard is also to be published on the public, GO-ITS Internet Site.
|Standard to be published on both the OPS intranet and the GO-ITS Internet web site (available to the public, vendors etc.)||âœ”|
All new web development must be in compliance with this standard prior to launch.
All existing websites are expected to comply within two years or a period agreed upon in consultation with the Standards and Guidance Coordinator.
All websites must be in compliance with all provincial accessibility legislation and their associated regulations. (See: 5.1.2 Legislation) Consult with the Standards and Guidance Coordinator for testing tools and techniques.
All websites must collect statistics about site performance and traffic.
Ministries must provide statistics monthly for flagship Internet and intranet websites to the Standards and Guidance Coordinator.
Analytics tools must be used to track only aggregate behaviour, not individual user behaviour.
Information gathered using analytics software (e.g. IP addresses) must not be used to identify individuals unless authorized by law. (See: 3.15 Privacy and Security)
Third party analytics services which store traffic data outside the Ontario government network must not be used.
The Web Coordinators Committee (WCC) is the central governing body for websites.
Each Ministry and Cluster must appoint a Web Coordinator to sit on the Web Coordinators Committee. Co-Chairs must be appointed by Cabinet Office Communications (COC) and the Office of the Corporate Chief Information Officer (OCCIO). Enterprise Coordinators must be appointed by the OCCIO or Deputy Minister of MGS.
Ministries and Clusters must supply WCC Co-Chairs with contact information for their Web Coordinators and backups.
An annual plan and quarterly reports must be submitted to WCC Co-Chairs by Ministry and Cluster Web Coordinators.
Enterprise Web Coordinators and the Co-Chairs of the WCC must be informed of new web initiatives through Ministry and Cluster Web Coordinators.
Government-wide changes to websites must be communicated through the Web Coordinators Committee.
Ministries and Clusters must maintain an accurate and current listing of their websites in the OPS Websites Database.
Sites must support, function and display as designed for browsers appropriate to the audience.
Sites must support screen resolution sizes appropriate to the audience. Websites must be designed to display in a browser without horizontal scrolling.
Websites must not prevent users from applying custom browser display settings (e.g. text size, colour contrast).
All content created by Government employees in the context of their work is subject to Crown copyright.
All non-HTML documents published to the public web must have a copyright statement in the footer.
All public websites should link to the Ontario Governmentâ€™s central copyright statement (See: 3.10 Look and Feel)
All website content must be reviewed in accordance with a maintenance schedule to ensure accuracy and currency of ownership.
Headings and labels must describe the topic of the content.
Help should be provided for the user, including, but not limited to: page or form description and identification, glossary of terms, frequently asked questions and answers (FAQ), detailed instructions.
The reading level of the content must be appropriate to the audience. Websites should provide a plain language summary of documents where the specific audience requires more technical language (e.g. health professionals).
When using technical vocabulary, abbreviations and acronyms, websites must define the terms used in context. To assist the audience, websites should provide a glossary and pronunciation guide where appropriate.
Certain publications (See: Glossary) are required to have ISBNs for each online format.
Websites must use HTML/XHTML as the primary document format. All other formats are considered secondary and must be made available alongside the primary format, on the same page. Websites must use HTML versions and encoding requirements appropriate to the audience.
Where information is available only in portable document format (PDF) due to a legal or security requirement, it must be as accessible as technically possible. To mitigate the risk this represents, contacts (telephone number, fax number or email) where people can request the information in an alternate accessible format must be provided.
Links to other formats must identify the file format used and include file size. (e.g. â€˜Brochure [PDF - 2 MB]â€™)
Websites must not use proprietary formats requiring users to purchase plug-ins/software.
MS Office documents must not be posted to public-facing websites, unless authorized by legislation. MS Office documents published on intranet sites should not contain previous versions or edits (e.g. track changes).
When providing documents in alternate formats:
Source documents must be created to allow for maximum accessibility when creating other formats (e.g. use Word styles instead of text formatting for document structure).
Websites must support connection speeds appropriate to the audience.
New public-facing websites must not be created without prior approval from Cabinet Office Communications. Do not register any new external domain names. Use only subdomains within gov.on.ca or ontario.ca keywords (e.g. Ontario.ca/flu).
All public-facing domains must belong to the OPS Domain Registrar. Government domains owned by other entities must transfer ownership to the OPS Domain Registrar. Domain requests must be approved by the OPS Domain Registrar.
All domain names must comply with the guidelines established by the OPS Domain Registrar with the advice of the Domain Advisory Group.
Decommissioned domains must be reported to the OPS Domain Registrar and recorded in the OPS Website Database.
Websites must use a fully qualified domain name and not be referenced by IP number or server name.
All government public communications must use Ontario.ca Keywords unless exempted by Cabinet Office Communications. External or gov.on.ca domain names must not be used for advertising.
The French Language Services Act applies to public-facing websites. Intranets are not required to be bilingual.
French content must be posted in accordance with guidelines provided by the Office of Francophone Affairs.
When there is a delay (e.g. due to translation) in posting the French version of a document, a disclaimer must indicate when the French version will be available and provide contact information.
Language links (English/FranÃ§ais) should link directly to corresponding content in the alternate language.
Link text to alternate English or French content must be in that language (e.g. If the document is also available in French, the hyperlink indicating this should be in French.)
Websites must identify the language on each page and language changes within a page.
Website content in other languages must follow the Multilingual Web Content Guidelines.
Hyperlinks must not trigger pop-up windows. Spawning new browser windows is only permissible if the user is notified in advance.
All hyperlink targets must be reviewed in accordance with a maintenance schedule to verify the destination still contains appropriate content.
Broken hyperlink checks must be done in accordance with a maintenance schedule, and all broken links must be addressed.
Hyperlink text must be meaningful when read out of context (e.g. don’t use “Click Here”).
Web content must be accessible by a Uniform Resource Indicator (URI/URL).
Presentation of hyperlinks must be consistent across the site and must stand out from surrounding content. Underlined text must not be used, other than for hyperlinks.
Hyperlinks must inform the user when they are being directed to a non-government website.
When a website undergoes a major transformation (e.g. relaunch or content reorganization) and hyperlinks will change, redirects must be created for important pages.
Where other formats are used, file size and format must be indicated within the hypertext link (e.g. Document Title [PDF-2MB]).
Links to alternate versions of a page (language or format) must lead to an equivalent page to ensure consistent navigation. Do not link to a splash or section index page.
All public-facing ministry websites must follow the Online Design Program (ODP). (See: 5.1.6 Online Design Program (ODP)) Each ministry has been provided with an ODP template and colour palette. The Online Design Program identifies the mandatory header and footer elements for public-facing web pages as well as the requirements for public-facing splash pages.
Websites must use the ministry’s ODP template or, with approval, the Ontario.ca ODP template. Exemptions must be approved by Cabinet Office Communications in advance..
Websites must not use frames. Use of iframes is discouraged unless there is no technical alternative.
Cascading Style Sheets (CSS) must be used to control style and layout. CSS must accommodate alternate user agents and must define print and mobile display. Pages must still be functional when CSS is not enabled.
Websites must not use tables to control layout. Data tables are permitted.
Websites must not overuse ALL CAPITALS, bold or italicized text, which can be difficult to read.
Links that return the user to the top of the page should be included when the page is long. Provide internal page links (anchors) at the top of the page to act as a table of contents for easier navigation within the page.
Intranet websites must follow the approved look and feel maintained by the Ministry Communications Branch.
Graphic “buttons” must not be used on public-facing websites. The Ad Banner Service should be used to promote government initiatives on public-facing websites.
Sites must comply with the approved Web Metadata Standard, GO-ITS 43 (See: 5.1.1 Standards).
A descriptive and concise Title Tag must be included in the header section <head> of every page, and must be unique to that page.
Format of website name must include Ontario before the Ministry Name, to show jurisdiction to users.
Metadata must be applied to all formats of web resources.
Title tag should be formatted as â€˜document title | website nameâ€™. For search engine optimization, the maximum character string is 65.
When presented as Ontarians, photographs and videos of individuals on public-facing websites must be residents of Ontario. Photographs and videos of individuals must not be used on websites without license or consent.
Rich internet applications (e.g. Flash) must be accessible. Content provided using rich internet applications must be available in other formats.
Where an audio/video presentation is incidental to the user experience of the website, the option of navigating through or skipping the presentation must be provided.
The Media Delivery Service should be used for hosting multimedia on public-facing websites. Third party video sites may be used as alternate distribution channels.
Navigation must use plain language and be applied consistently across the website.
Users must be able to search for content and browse a site map.
A table of contents must be provided for large documents or sections.
Consistent labels must be applied to like elements or functions
Users must be able to navigate government websites without a mouse.
Websites should provide plain language 404 pages (file not found) with resources to assist the user and provide suggestions for the correction of common errors.
When moving popular documents, websites should use a proxy redirect or a 301 page (moved permanently) explaining how to access the information before redirecting.
Where practical, users should be able to bypass large blocks of repeated navigation or other embedded elements (e.g., skip to content).
Public-facing websites collecting personal information must contact the Office of the Chief Information and Privacy Officer to determine if a Privacy Impact Assessment (PIA) is required. All relevant legislation and OPS I&IT Standards and Policies on privacy apply. (See: 5.1 References)
Websites should only collect information that is required to perform the service. Non-essential information must be identified as optional.
Personally identifiable information stored in application and/or server access logs (e.g. IP addresses) must not be used to identify individuals unless authorized by law.
Personal information must not be retained for longer than needed to perform the service or comply with appropriate legislation. Apply records retention schedules where appropriate.
Public-facing websites must contact I&IT Security to determine if a Threat Risk Assessment (TRA) is required. All relevant OPS I&IT Standards and Policies on security apply. (See: 5.1 References)
Websites collecting personal information must use encryption and transport layer security (See: GO ITS 25.12 Security Requirements for the Use of Cryptography and GO ITS 25.13 Security Requirements for Internet Accessible Web Applications).
State management mechanisms must be designed to prevent unauthorized access to personal information (See: GO ITS 54 for application development requirements).
Where search is required, the Federation Search Service must be used by all Government of Ontario websites with non-classified and low sensitivity information.
All sites must be able to be indexed by the Federated Search Service.
For public-facing sites, the Online Design Program controls the layout of site search.
A search box with the current search terms must be displayed at the top of the search results page. The search results page must contain options for refining the search (e.g. filters) or search help.
The total number of results found and the number of results per page must be displayed.
The search term must be highlighted in the search results listing.
The bottom of the page must indicate the segment of the results being displayed on the page.
Results display should not contain duplicate returns for a single URL.
Information published on third party websites or services must be equivalent to information available on government sites.
Public-facing websites with embedded third party services must notify visitors and link to a privacy statement.
Websites should use internally-hosted social media tools.
User Interactions include any online experience where the user actively submits information to a website (e.g. sending feedback, posting a comment) and the site provides a response. There are many types of online transactions that involve user interaction (e.g. multi-screen transactions, forms, e-commerce/payment, user profiles, zooming in on a map, validation and error handling).
Threat Risk Assessments (TRA) and Privacy Impact Assessments (PIA) should be performed for websites that involve user interaction (See: 3.15 Privacy and Security for details).
Websites must list all prerequisites for successfully completing a transaction before the transaction begins (e.g. valid health card).
For complex transactions, users must be able to review, modify and confirm entered information before it is submitted.
Mandatory and optional fields must be clearly identified within the data entry interface.
The submit button must be located at the end of the data entry section. The submit button must be clearly labelled.
If data must be entered in a specific format, an example of the correct format must be shown next to the input field.
All data entry fields must indicate units of measurement where applicable (e.g. hours or $). Websites must provide a choice of formats where appropriate for the audience (e.g. people might choose to enter their height in metric or imperial units).
Help should be provided in the context of the transaction.
Websites should notify the user of the results of their interaction (e.g. success, failure).
The DD/MM/YYYY date format should be used for date input fields, where the date can be converted to the standard format for date storage (See: GO ITS 74 Date Format).
Buttons for navigating a multi-screen transaction must be clearly labelled.
Radio buttons should be used instead of drop-down menus for selections of up to 3 options. Drop-down menus should be short enough not to require the user to scroll, except for choices where the user will know all of the available options without seeing them (e.g. a selection of US state or Canadian province).
On mandatory fields, the most popular options should be default or the most logical order should be followed; for non-mandatory fields the blank option should be default.
E-commerce transactions must always take place via a secured connection, using transport layer security (See: 3.15 Privacy and Security).
Shopping cart functions must be prominently displayed and easily identified.
Where an e-commerce transaction takes place, an e-mail confirmation of purchase must be sent to the user, and an option must be provided for the user to print the invoice page.
All public-facing sites must provide a feedback form. Alternate channels of communication (e.g. telephone, TTY, FAX, email address, postal address) must be identified where available.
Where users submit personal information, the Notice of Collection must be included. (See: 3.15 Privacy and Security)
Anti-spam measures must be used where email addresses are published on websites.
Public-facing websites must also comply with all related policies, including the Accessible Customer Service Policy and the Ontario Government Common Service Standards as they relate to feedback forms. (See: 5.1.1 Standards and 5.1.4 Policies)
Log-in screens must identify to the user what they are logging into. A description of the service must be provided, either on the same page or by linking to another page.
Log-in screens must provide instructions for user registration, either on the same page or by linking to another page.
Log-in screens must provide help for users who have forgotten their account credentials. There should be a mechanism for recovering lost credentials.
The sign-up page must have a Notice of Collection (See: 3.15 Privacy and Security) and description of the subscription service. Ministries must not use or share subscriber information for any reason beyond the stated purpose.
Subscriber information must be stored in a secure location that is not publicly accessible. Access to subscription information must be restricted to authorized personnel only. (See: 5.1.4 Information Security & Privacy Classification Policy).
Mechanisms to discover the actions or preferences of specific subscribers (e.g. embedded links with unique identifiers) must not be used, unless it is lawfully authorized and required to perform the service.
Each email must provide a mechanism for unsubscribing (automatic or manual).
Each email must link to a feedback form.
Subscription services should only collect information that is lawfully authorized and required to perform the service. Non-essential information must be identified as optional.
All form fields must have validation to prevent errors and/or manipulation of input. Form data should be validated at every tier.
Users must be able to correct errors by editing their original input.
Error messages must contain a plain-language description of the problem and how to correct it.
In the case of multiple errors, a summary should be provided at the top of the data entry area.
Incorrect field(s) must be highlighted.
|GO-IT Standard||Impact||Recommended Action|
|GO-ITS 23.1 Government of Ontario Public Web Standard||Merged into this document.||This standard should be repealed/archived when GO-ITS 23.0 is published.|
|GO-ITS 23.3 Internet Web Application Interface||Merged into this document.||This standard should be repealed/archived when GO-ITS 23.0 is published.|
|GO-IT Standard||Impact||Recommended Action|
|All Government of Ontario Internet and intranet websites.||Update from GO-ITS 23.1 and 23.3 to the most recent standards detailed in this document.|
Documents that appear in this section provide rules and guidelines to which reference is made in the standard in such a way as to make it indispensable for the application of the standard:
IT Standards (Ontario.ca/ITstandards)
Web Metadata Standard (GO-ITS 43) – Defines the metadata requirements for Government of Ontario web resources.
Advertising Content Directive (PDF â€“ 200kb)
Information & Information Technology Directive (PDF â€“ 194kb)
Information & Information Technology Security Directive (PDF â€“ 172kb)
Procurement Directive July 2009 (PDF – 196KB)
Operating Policy on Open Source Software (intranet site)
Information Security & Privacy Classification Policy (PDF â€“ 331kb)
Project Gateway – Operational Policy (PDF â€“ 202kb)
Communications in French â€“ New Media Guidelines
Ontario Terminology (ONTERM) http://www.onterm.gov.on.ca/
The Online Design Program (ODP) defines the look and feel for public facing government sites. ODP standards and guidelines are maintained by Cabinet Office Communications. This Style Guide is produced by Cabinet Office and outlines the visual representation of the Government of Ontario on the Internet. The Ontario Government style guide is accompanied by individual ministry style guides produced in conjunction with Cabinet Office New Media. Keyword: Ontario.ca/ODP
The OPS Domain Registrar is responsible for maintaining Government of Ontario domains, approving new domain requests and enforcing the Domain Name Guidelines. This position is appointed by the CCIO.
Domain Advisory Group
The Domain Advisory Group exists to provide guidance on requests for exemption and proposed changes to the Domain Name Guidelines.
The Ontario.ca Keywords program provides short, memorable web addresses for online initiatives (e.g. Ontario.ca/flu). Cabinet Office Communications is responsible for maintaining existing keywords and approving new keyword requests.
|Copyright||Copyright gives the creator of an original work exclusive right for a certain time period in relation to that work, including its publication. The copyright year refers to the year the item was first published. It does not change with the year since it indicates when copyright protection of the work began. If the content of the work has been significantly modified, then the new copyright notice should be the year of the modification.
Link to the central site copyright page: http://www.ontario.ca/en/general/004222
|Domains||A domain name is an identification label that defines a realm of administrative autonomy, authority, or control in the Internet, based on the Domain Name System (DNS). The first-level set of domain names are the top-level domains (e.g. com, net and org), and country code top-level domains (e.g. ca).
The Government of Ontarioâ€™s top-level domains include: gov.on.ca, gouv.on.ca, edu.on.ca and Ontario.ca
|Internet||The Internet is a world-wide collection of computer networks that are linked using a set of common communications protocols (TCP/IP, HTTP, SMTP etc.). It is used as a communication medium for all types of data and applications. Some Internet sites are password protected; these are sometimes known as “Extranets”.|
|Intranet||A network based on Internet protocols belonging to an organization, usually a corporation, accessible only by the organization’s employees. An intranet’s websites look and act just like any other websites, but a “firewall” surrounding an intranet prevents unauthorized access.|
|ISBN/ISSN||International Standard Book Number (a unique numeric commercial book identifier) and International Standard Serial Number (a unique eight-digit number used to identify a print or electronic periodical publication).|
|Metadata||Data that describes data and that enables collaboration and interoperability. Metadata also describes how, when and by whom a particular set of data was collected, and how the data is formatted.|
|Portable Document Format (PDF)||A standard document format (generally Adobe Acrobat portable document format) capable of being viewed with a web browser plug-in. The portable document format enables the document author to specify the layout and presentation of the document, and documents in this format are more difficult to tamper with than regular HTML documents.|
|Privacy Impact Assessment (PIA)||A privacy impact assessment (PIA) is a process that helps to determine whether new technologies, information systems, and proposed programs or policies meet basic privacy requirements. It measures both technical compliance with privacy legislation and the broader privacy implications.|
|Publications||Publications that are intended to be regularly updated or continued indefinitely (such as journals, magazines, newspapers, updating loose-leafs, updating websites) shall not receive an ISBN. Publications that are issued only once, without anticipated modifications (e.g., reports, budgets, plans) must have ISBNs assigned.|
|Rich Internet Applications (RIAs)||Rich Internet Applications (RIAs) are web applications that have most of the characteristics of desktop applications, typically delivered either by way of a standards-based web browser, via a browser plug-in, or independently via sandboxes or virtual machines. Examples of RIA frameworks include Ajax, Curl, GWT, Adobe Flash/Adobe Flex/AIR, Java/JavaFX, Apache Pivot, Mozilla’s XUL, OpenLaszlo and Microsoft Silverlight.|
|Search||A tool that allows users to find content quickly on websites without browsing or using navigation. “Advanced Search” allows for a refined search based on more than one parameter.|
|Social Media||A category of websites that are based on user participation and user-generated content. This includes: social networking sites, social bookmarking sites, social news sites, blogs, forums, wikis, etc.|
|Splash Page||A simple page that serves as a gateway, making it clear to users that there are two languages available for Government of Ontario websites (English and French). A splash page typically resides at the root URL for the site and leads to the main home page.|
|TeleTYpewriter (TTY)||A text display device that lets people who are deaf, hard of hearing, or speech-impaired use the telephone to communicate, by allowing them to type messages back and forth. A TTY is required at both ends in order to communicate.|
|Threat Risk Assessment (TRA)||A Threat Risk Assessment (TRA) is a formalized process used to determine the risks to Information and Information Technology (I&IT) assets and to provide recommendations about ways in which program owners can lower these risks to acceptable levels. It allows program areas to manage risks to their services.|
||Software that retrieves, renders, and interacts with web content via computers, mobile phones and gaming consoles. This includes: Web browsers, media players, plug-ins, and other programs including assistive technologies.|
|User Interaction||Any online experience where the user actively submits information to a website (e.g. filling out a form, making purchases, searching, post a comment) and the site provides a response. This is in opposition to passive browsing, where a user simply reads the page.|
|WCC||Membership in the Web Coordinators Committee is made up of appointed members from each Government of Ontario ministry, cluster, and from enterprise sites and other stakeholders. Created in June 2007, this is the first formal group for web governance. Previously, the GO-Web Committee had served for communications and connections. The Committee meets monthly.|
|Web Browser||Also known as a “User Agent”, a browser is software that retrieves and presents web content for users via computers, mobile phones and gaming consoles. Not all browsers are created equal: since different browsers have different capabilities, not all web content can be accessed via all web browsers.|
|Web page||A document on the World Wide Web. Every web page is identified by a unique URI (uniform resource indicator) or address location. A web page may contain embedded resources (e.g. images, audio, video, applets, other HTML files), and may be generated by a database. These resources may reside at different network locations.|
|Website (or Web site)||A collection of web pages accessed through a user agent. It is acknowledged that anything displayed in a browser is covered.|