������Ƶ

As a companion document to the web governance policy, this web governance procedure provides information and guidelines covering the following topics:

• The creation and management of primary public-facing websites and private intranet sites, secondary sites managed by departments and/or faculty, and sites for major initiatives such as the capital campaign.
• Content lifecycle processes to define the roles and responsibilities, workflows and approvals, the appropriate location of content, and the review, archiving, and/or deletion of content.
• Approval processes for the creation of new websites and the retiring of obsolete websites.
• Minimum standards for accessibility, SEO, and analytics.
• Identification of the technology platforms used for public and private websites, how the platforms should be monitored and maintained, and under what circumstances an alternate platform may be endorsed.
• While the web governance policy itself shall be reviewed every two years and either amended or confirmed, the procedure should be considered a “living document,” referred to and fine-tuned when opportunity permits as web properties are built and maintained.

VALUES APPLICABLE TO WEBSITE & DIGITAL ASSETS

A ������Ƶ Allison resource. The website is an institutional asset and is designed and supported to serve the academic mission in its broadest sense. This includes information pertinent to teaching, research, and learning; student supports and many services; development and fund raising; and alumni relations. Those involved in web governance activities, including site planning, platform selection, content creation, editing, and ongoing maintenance, do so with the University’s short- and long-term interests in mind.

Audience-centric. To serve the University’s interests, the website must be designed with a priority for the end user experience. It is recognized that the University serves a diverse set of stakeholders. While it is difficult to align site structure and content to meet the needs of all stakeholders, information should be maintained and structured to make it straightforward to navigate, search, and locate relevant content on the site. Text, images, videos, and other content should be regularly checked and updated. Content should be accurate and free of typographic errors.  Site design should incorporate standards designed make content accessible to a wider range of people, addressing issues for people with visual impairments and low vision, hearing impairments and hearing loss, learning disabilities, cognitive limitations, limited movement, speech disabilities, photosensitivity, and combinations of these.

Designed for multiple platforms. A wide range of devices are used to access the website and online content; therefore, the website should be designed to deliver a positive user experience across all standardized platforms. This also means that the CMS platform and website should be periodically assessed against available technological trends and updated, as necessary. With mobile usage constantly on the rise, we consider the mobile experience before the desktop experience, in terms of design and site architecture. Our website is responsive, which means it automatically resizes to fit the screen of the device used (smartphone, tablet, laptop, or desktop computer) to view the website.

Privacy and security of data. MtA web properties are by design accessible by the public. Therefore, consideration needs to be given to the sensitivity of all information being published. Avoid publishing information that would be considered private or confidential, or only of use for people already at the University. Similarly, when using forms for receiving information from users, proper measures need to be taken to protect the information obtained and to ensure that it is only used for the purpose it was collected. Be especially cautious if Personally Identifiable Information (PII) is required such as birth date, banking information, or any other details that can be used to uniquely identify a person.

Brand-focused. The experience users have while using the website is an important influence on their perception of ������Ƶ Allison and its reputation as a university. Our brand is not just a logo. Our brand has a voice that communicates who we are as a University and our values. Web content needs to consistently reinforce MtA's brand to all audiences.

WEB PROPERTY OBJECTIVES

Objectives for each web property should be reviewed on an annual basis, adjusted as required, and referenced when determining specific goals or key performance indicators for the site. Goals for ������Ƶ Allison web properties site should consider:

• Initiatives outlined in the ������Ƶ Allison Strategic Plan
• Planning guidance found elsewhere across the University, such as in the Academic and Research Services plan, University Advancement Plan, Recruitment Plan.
• Operational initiatives of University departments.
• Evolving trends relevant to post-secondary education and web/online communications, including target audience/ demographics, desired user experience, website content and functional standards, accessibility standards, website CMS/ technology capabilities, website performance standards.

MANAGEMENT ROLES & RESPONSIBILITIES

It is the responsibility of the leadership groups to set strategy and KPIs for web properties, set governance roles, ensure appropriate resourcing, and approve/monitor all web-related activities and initiatives.

Group	Members	Roles/Responsibilities
Web Working Group	Director of Marketing and Communications Communications Officer Web Communications Officer Director of Information Technology Network Manager Systems Programmer Web Developer	Responsible for managing the infrastructure, information architecture, branding, privacy, accessibility, security, training, and maintenance of web properties
Web Management Team	Director of Marketing and Communications Director of Information Technology	Responsible for setting objectives, budgets, resources, and approval to changes to governance
Web Advisory Committee	Members represent the stakeholders and administrative and academic departments of the University. Student representatives are also included. Membership may vary year to year.	Responsible for providing oversight and input to the Web Management Team around the governance and management of web properties. A regular meeting schedule should be established.

FEEDBACK MONITORING

If the web property implements a mechanism for collecting user feedback (e.g., feedback form, chat, etc.), a role or individual must be assigned to monitor and triage this feedback, identifying items that require immediate response and items that represent opportunities for improvement. These should be brought to the owner of the site or of the specific content for consideration.

WEBSITE AUDITS

All University web properties should be audited at a minimum of once per year to identify issues, review the appropriateness and relevance of content, check accessibility, brand alignment, and technical/security conformance.

INVENTORY OF WEB PROPERTIES

Web Property	URL	Owner	Access	Platform
Public Website	mta.ca	Marketing Communications	Public	Drupal 8
Recruit		������Ƶ	Public/Private	Ellucian Recruit
Intranet		Marketing Communications	Private	SharePoint
Owens Art Gallery	mta.ca/owens	Owens Arts Gallery	Public	WordPress
������Ƶie Pride		Athletics and Recreation	Public	Presto Sports (Saas)
Library		Library	Public	SpringShare
Bookstore		Administrative Services	Public/Private	MBS (Hosted)

FACULTY RESEARCH SITES

Research sites are defined as websites designed to publish their academic content or research-in-progress, either by an individual researcher or a group of researchers. A research site is the intellectual property of faculty member(s), in the same way that a faculty member’s research output is their intellectual property. Due to breadth and variety of research undertaken by the faculty, and the varied nature of research output (written, visual, numerical, database-driven) content and display that would be required, the University website platform is not able to support such sites.

Oversight and maintenance of research sites falls to the researcher(s) in question. Faculty members control the development, hosting, and maintenance of these sites on platforms of their choosing. As such, research sites fall outside the parameters of this web governance protocol.

Faculty directory pages that reside on the University website are part of the University website, and the content supported as part of the support for the website platform. Faculty directory pages can contain links to faculty research published elsewhere (in journals, books, or sites of independent outside organizations, including a link (s) to a faculty member’s own standalone research site(s).

The University will provide support to meet obligations arising from research content obligations from Tri-Council funded research; specifically, to a) ensure research content is maintained, secure, and accessible in an online format, and b) ensure that funded research can be secured and archived for future access.

• With respect to ensuring research is maintained securely in an online format, Computing Services will assist faculty by providing hosting of faculty site(s) within MtA’s IT environment (upon faculty request) and/or provide advice to faculty about external hosting options. Faculty sites that are being hosted in the University’s IT environment will continue to be supported in this manner, until such time as faculty no longer require such services.
• With respect to ensuring archival access to funded research Computing Services will collaborate with ������Ƶ Allison Library and Archives to ensure research is accessible.

APPROVAL PROCESS FOR NEW WEBSITES

In general, most website content pertaining to the University should be part of the main website mta.ca and/or developed on the web CMS platform. Requests to develop University sites outside of mta.ca/the Drupal platform are allowed, following assessments based on technological, informational, and/or user experience reasons. Currently, there are a small number of standalone websites for certain aspects of University operations. These are: the Owens Art Gallery, Athletics and Recreation, the University Library and Archives, and the University Bookstore. In each case, the content of these sites is managed by the department or organizational unit in question, and not by the Web Working Group.

As all sites represent a part of the ������Ƶ Allison digital eco-system, authorization to create a new University web property, separate from mta.ca, must be assessed by the Web Working Group for feasibility. Final approval must come from the Web Advisory Committee. NOTE: Faculty research sites do not require MtA approval before being developed. As outlined above, faculty have full control of the creation and ongoing maintenance of site(s) that contain their research.

Approval requests for sites (other than faculty research sites) that are built outside the University’s web platform should be submitted in writing to the Web Working Group, including the following information:

• Group requesting approval for the new site and who will be managing it
• Purpose of the site
• Whether the site is going to be public or private
• Audience — who will be using the site
• Outline of the content/functionality for the site
• The desired domain name (or subdomain)* for the site
• Platform on which the site will be created**
• Who will be developing the site (i.e., external vendor, in-house)
• Who will be developing and managing the site content
• Anticipated lifespan of the site

* See Domain names, in Section 4: Technology

** See Technology standards, in Section 4: Technology

Inquiries with respect to this should be directed to the director of information technology or the director of marketing and communications.

ACCESSIBILITY GUIDELINES

While the Province of New Brunswick does not have its own accessibility legislation, it was a recommendation in their recent Disability Action Plan, targeting the end of 2021. This legislation is expected to be similar to legislation in Ontario and Nova Scotia, which requires that websites be compliant with the World Wide Web Consortium’s accessibility standard. Therefore, all University web properties should be designed to meet the Web Content Accessibility Guidelines (WCAG) 2.0 AA standard. This is available for reference at

PRIVACY

All University web properties should follow the Government of Canada’s Personal Information Protection and Electronic Documents Act (PIPEDA) and/or the Government of New Brunswick’s Right to Information and Protection of Privacy Act (RTIPPA). This includes, but is not limited to, maintaining and enforcing a privacy policy that covers all collections, uses, and disclosures of personal information made via the site.

COOKIES

All publicly accessible University web properties should respond appropriately to notify website users of the use of “cookies” or other non-visible tracking tools (e.g., Facebook pixels) and to explain such practices. If doing business within the EU, the website should offer the ability to opt out of third-party cookies.

WEB FORMS

The University hosts many forms on their web properties to collect information from users. Multiple tools are leveraged for this depending on the functionality required, the sensitivity of the information collected, and other factors such as the anticipated volume of submissions and lifespan of the form. The following table lists the current form methods and recommended usage:

Form type	Usage
Drupal webforms	Public website, protecting personal information
Microsoft Forms	Intranet, protecting personal information
Registration portal	discover.mta.ca, protecting personal and financial information
PDF form	Public website, personal information

Each form must be submitted for approval for publication by the Web Working Group by providing the following information:

• Purpose of the form (i.e., what is being done with the information collected)
• List of form fields, indicating which are required vs optional
• Where the form should be placed on what website
• Who should receive notification of form submissions to view the data
• The period the data will be kept
• How the user can request a change to, or removal of, the information submitted

General guidelines:

• All forms should use SSL encryption
• Forms should only collect the information required to fulfill the request
• Forms may collect and store personally identifiable data according to the University privacy policy (in development)
• Form data should NOT be sent in e-mail submission notifications or auto-responders
• Forms should NOT be used to collect and store sensitive information such as financial information, social insurance numbers, passport numbers, etc. Forms such as these are managed by Computing Services.

 CONTENT ROLES & RESPONSIBILITIES

The following roles represent a range of content creation and editing within the CMS. Employees are assigned roles by the Web Working Group, based on requirements of their position description and/or duties assigned by their manager, supervisor, or department. Permissions within the CMS platform allow an individual to perform the functions described. An individual may have more than one role assigned to them, meaning they can perform all the tasks defined for each role.

Role	Roles/Responsibilities
Content Supervisor	Subject matter experts for a given area or web section(s). Takes the lead for the development of content for their assigned section(s). Reviews and provides final approval of content. Ensures content is accurate and up to date on a regular basis. Typically, an academic department head or manager of an administrative department(s). Consults with Marketing and Communications Office and Web Working Group as required.
Alert Managers	Can create and publish/unpublish alerts on the main MtA website.
Enhanced Content Editor	Have training on the website CMS and are responsible for creating and editing content and uploading images/documents for their assigned area(s) of the site.
Form Submission Viewer	Can view, print, and export form submission data in the CMS.
Form Builders	Can create new forms and edit existing forms in the CMS. Limited to Computing Services or Marketing and Communications personnel.
CMS Manager	Have access to all the features of the CMS except for site-level configuration, source code, and server settings. Access includes layout builder, content blocks, redirects, aliases, menus, editorial access, and HTML view.
Content Authors	An individual that prepares or may be called upon to prepare content for use on the site. This individual may or may not have a role within the CMS.
Web Administrators	Have full access to the CMS, site-level configuration, and source code for the website. Can create, delete, edit any page or web section on the site and perform all content functions as configured within the CMS.
System Administrators	Have administrative access to the underlying hosting infrastructure for the website.
Help Desk	Able to provide support to CMS users who require support in accessing the CMS platform or with their browser or related software tools.

CONTENT LIFE CYCLE

The following diagram shows the suggested content life cycle for mta.ca. Note that by design, this workflow is not enforced within the CMS (i.e., content editors can publish content immediately); rather, it is a guideline for how the content approval process should flow. Also, in many cases, one or more of the identified roles may belong to the same individual. For example, a content supervisor may also be the author, or the content author may be the CMS editor. The process for other web properties including the intranet will be similar, except the audience for that site would be private.

TRAINING

Access to the CMS for web page editing is granted by the Web Working Group to individuals who will be responsible for the ongoing maintenance of content on any of the University web properties. The general philosophy is that only those individuals who will be using the software on a regular basis will be trained and granted access to perform a content editing role. Content supervisors and/or other subject matter experts who are not often required to update content may instead work with these editors to have content on the web site updated at their request.
Training, documentation, and support is provided for individuals responsible for maintaining web content through the following methods:

• The Marketing and Communications Office is responsible for initial training/orientation for the CMS. This may include individual or group training for administrative or academic departments and can be held remotely via videoconference or in-person. Sessions may be scheduled upon request or at regularly scheduled group training events.
• Links to generic CMS documentation is available via the software.
• University-specific guides and/or videos are available for CMS concepts and tasks.
• Support for CMS-related tasks (e.g., editing a web page, uploading an image, etc.) is provided via e-mail, Microsoft Teams, or phone by the Marketing and Communications Office.
• Technical support for accessing the CMS (e.g., logins, web browsers, computer-related issues, etc.) is provided via e-mail or phone by the Computing Services Helpdesk.

PDFs

Use of PDF documents are not best practice for website content management They are problematic in terms of site accessibility and usability, particularly when viewed on mobile devices. For this reason, use of PDF documents should be extremely limited. Specific cases where PDFs can be used are as follows:

• Publishing a document where the original formatting must be retained for printing, etc.
• Publishing reports, manuals, books, magazines, academic calendar, etc. where it would be too labour intensive to reformat as web pages.
• When providing financial or other information that has been certified as accurate.

If it is necessary to publish in PDF format, it is critical that each PDF be optimized for accessibility. Adobe has created a series of accessibility guides for Adobe Acrobat Pro DC to assist content authors in creating accessible PDF documents.

TRANSLATION

In general, the language of website content is English. Should there be a requirement to have content on the website presented in a language(s) other than English, please consult with the Web Working Group. An assessment of the request will be undertaken, as to the best approach. Two common ways of presenting content in other languages are:

Providing a subset of content in one or more languages
In this case, the page(s) will be created and maintained as part of the English website, where they can be grouped together and linked to from an index page. With this approach, there is no ability to toggle between languages because there is not a one-to-one relationship between pages for each language.

Providing programmatic translation of content
In this case the goal is to make the English content more accessible to users of a different language. The approach will include the configuration of an automated translation tool such as Google Translate, which provides users the ability to toggle to a language of their choice from each page. The translation should be of sufficient quality to effectively communicate to with users.

RETIRING & ARCHIVING WEB PROPERTIES

Following an annual website audit, if a web property has been recommended for retirement, this should be brought to the Web Working Group and Web Advisory Group for approval. Web properties should be archived by creating a static copy of the website using an appropriate tool, such as HTTrack, and by keeping a backup of the website source files and database, as applicable. If the web property is hosted at a unique domain or subdomain, the Web Working Group should decide whether to keep the domain name or let it expire on its renewal date.

BRAND STANDARDS

The design and content of all web properties should reflect the University brand. Updated brand guidelines and templates for use by staff are now available on the Faculty & Staff Gateway on the Communications support page in the Campus services & facilities site.

ANALYTICS

The standard tools for analytics on ������Ƶ Allison web properties are Google Analytics, Google Tag Manager, and Google Data Studio.

• Computing Services and Marketing and Communications will collaborate on regular website analytics website.
• All web properties should be configured with Google Analytics prior to publishing. The configuration of the site should be done within the primary Google Analytics account, managed by the Marketing and Communications Office. Approved vendors may, from time to time, be engaged to assist with analytics set-up, reporting (dashboard) and custom analysis.
• Website goals and key performance indicators will be identified and configured within analytics, leveraging the tools provided in Google Tag Manager (for user event tracking) and Data Studio (for reporting). Other software tools may be used depending on requirements.
• Website goals should be established help inform and assist with recruitment as well as development (fund-raising) and alumni relations activities. Goals should consider both macro conversions (e.g., applying to university, registering for a campus tour, making an online donation) will micro conversions (e.g., watching a video, accessing a specific page/ website section, subscribing to a newsletter, sharing content on social media, etc.). Goals will change over time
• Computing Services will utilize analytics to understand overall website and web server performance, such as monitoring site reliability (up-time), file and page loading times and optimization, assessing 404 and other page-loading errors and other aspect of website performance.
• Relevant analytics/ data should be shared with other University departments, the senior leadership team, and Website Advisory Committee, as may be informative and/or assist with key operational goals.

SEARCH ENGINE OPTIMIZATION (SEO)

Public and private web properties should have a base level of search engine optimization (SEO) to improve the findability of content and, for public sites, improve the discoverability and volume of traffic via Google Search. At a minimum, content authors should identify the keywords that visitors may use to find their content, then incorporate these keywords into the titles of their page(s). Additional benefit can be realized by optimizing alt tags for images and the meta description for each page. The Web Working Group will provide editors of additional best-practices for making their web content SEO-friendly.

EMERGENCY COMMUNICATION

All emergency communication will be published on mta.ca or the intranet by the Marketing and Communications team. Emergency communications on the public website will leverage the notice bar, setting either informational or emergency alert status. This bar is visible on all pages of the site. The emergency alert also appears as a window that needs to be acknowledged by the user before proceeding. Other communications may also take the form of news releases or support pages of content within the sites.

REDIRECTS

Redirects are often needed for long URLs that need to be printed on marketing material. For instance, rather than using the full URL /admissions/tours-events-and-info-sessions/open-house, the shorter URL mta.ca/openhouse could be used to redirect to the longer URL. To ensure that the use of redirects is governed appropriately (i.e., avoiding duplicates), specific requests for redirects must be sent to a member of the Content Managers group for approval and implementation at the CMS level.

Redirects may also be used at the server level to redirect users from pages that are retired to new pages, as appropriate. This is particularly helpful when redesigning a website when there are changes to the site map that impact the page URLs. This list of redirects is maintained by a web administrator and should be reviewed annually by the Web Working Group to remove redirects that are no longer required based on traffic analysis.

AGENCY SUPPORT

Understand when to invest in internal resources vs. hiring consultants or an agency to support the marketing, creation, and/or maintenance of ������Ƶ Allison web properties. If hiring a freelance consultant or an agency:

• Be clear with goals, expectations, timelines, and budgets
• Understand when the process must go through a formal request for proposals (RFP)
• Organize your information and content
• Understand and establish roles
• Communicate proactively and often
• Understand the process to escalate issues

Once the individual(s) or agency has been selected, you must work with Computing Services’ Network Services for the onboarding process to grant them access to the required internal systems and resources.

 

TECHNOLOGY PLATFORMS

The following table outlines the technology platforms used for the current web properties.

Web property	Technology platform	Hosting	Source control
Public website	Drupal 9.x	UNB	Git
Legacy website (Ektron)	Apache	UNB	n/a
Intranet site	SharePoint	Office 365	n/a

The technology standard for public websites is Drupal. For the internal site it is SharePoint. If another platform is being requested, rationale must be provided along with how site maintenance and hosting will be addressed. Example acceptable rationale are:

• The standard platform does not provide the functionality required
• The individuals building the site are doing it in-kind and do not work with the standard platform
• The required timeline to create the site is too short to use the standard platform

WEBSITE ACCESS

The following table indicates who has access to the primary web properties of the University and how they will authenticate on the site.

Web property	Groups with read access	Authentication
Public website	Members of the public	No authentication required; browsing is anonymous.
Discover	Propspective students self-register	Authentication required after registration
Intranet / SharePoint	Faculty and staff Students	Only available from within the University network, Authentication via Active Directory on the physical network or on VPN.
Owens Art Gallery	Public access	No authentication required; browsing is anonymous.
Library	Public access	No authentication required; browsing is anonymous.
Athletics	Public access	No authentication required; browsing is anonymous.
Bookstore	Public	No authentication required; browsing is anonymous.

UPTIME MONITORING

Publicly accessible web properties should be monitored for uptime using a third-party service to ensure that the sites are always available for public viewing. The configuration should determine what duration the site is unavailable before it is considered “down” and who should be notified to take action.

Internal web properties, such as the intranet, are monitored from within the internal network to ensure the sites are available for internal users. As with the public site, the unavailability threshold and notification roles must be determined.

SOFTWARE MAINTENANCE

Web properties that have been built on CMS platforms maintained by the University should be monitored weekly to ensure they are up to date with the latest security patches and software updates. Security patches should be installed and verified on a staging environment followed by production as soon as they are made available. Software updates should be incorporated into the next scheduled release of the website.

RELEASE / UPDATE MANAGEMENT PROCESS

The website operates under a continuous improvement model of development, with regular technical, security, CMS, and website functionality updates.

• The primary web properties and associated CMS is updated regularly with new features, functionality improvements, bug fixes, and/or general maintenance.
• New releases of the content management software typically occur quarterly, but the schedule may be altered to accommodate larger initiative or resource constraints.
• Security-related updates to the CMS and/or underlying technology stack should be applied as a hotfix as these become available instead of waiting for the regular release schedule.

The Website Working Group will plan and manage updates and communicate to internal stakeholders when any material updates are being undertaken. Planning for website functionality enhancements should include consultation with key stakeholders within the University community.

PERFORMANCE STANDARDS

Performance standards should be set for each of the primary web properties. This should include a maximum average load time for key pages (e.g., home page, landing pages) and a minimum desktop and mobile score on a third-party performance measure, such as Google PageSpeed Insights (). PageSpeed scores between 90-100 are considered good, while scores between 50-89 need improvement. Scores under 50 are considered poor and should be avoided.

TOOLS (END USER)

For the primary web properties, end users who will be editing content on the site should be using a modern web browser that is either the latest release or the release one prior to the latest release.

• Supported web browsers include Chrome, Safari, Firefox, and Edge.
• Supported operating systems include the latest release or the release one prior to the latest release of Windows 10 and MacOS.
• Support for mobile platforms (browser and OS)
• Content is typically authored and approved in Office 365 (Word, Excel, PowerPoint, etc.) prior to being created in the CMS.
• Images should be edited, cropped, resized, exported, and optimized to web format.

DOMAIN NAMES

Domain names or subdomains that represent the University should be approved by the Marketing and Communications Office and created/managed by Computing Services’ Network Services. Domain name best practices:

• Domain name should be on-brand and specific to the scope of the content.
• Subdomains (i.e., subdomain.mta.ca) should be structured consistently and be specific to the scope of content.
• The domain name should be owned by the University (the registrant) and ideally registered with the same domain name registrar and account as the existing University domains.
• E-mail and phone associated with the domain account should be under University control, not personal e-mails or phone numbers.
• Domain accounts should have two-factor authentication enabled.

THIRD-PARTY WEBSITES

Sometimes, a third-party website or Software as a Service (SaaS) is required to provide content or functionality that the University requires instead of building and/or maintaining it on-premises. Approval to use these types of services should come from the Web Advisory Committee, with additional input and approval from both the Marketing and Communications Office and from Computing Services’ Network Services. If a third-party website or SaaS is approved, the Web Working Group should provide guidance on branding the site appropriately and ensuring that it meets the University’s privacy, accessibility, and security standards.

SERVICE REQUESTS

Service requests for web-related work should be made by submitting a ticket to the Helpdesk, where it will be reviewed and assigned accordingly. The Helpdesk will refer requests to the Web Working Group for discussion/approval as needed.