GCWeb theme - Meta information

On this page:

• Menu CDN
• GCWeb Canada.ca theme) visual update - V5
• Evaluation and report
• Special notes
• Static header and footer
• Customizing GCWeb for your implementation variant
• Test cases
• Implementing GCWeb
• Version history (Release notes)

Menu CDN

Principal publisher udpate those following HTML fragment file every time there is a change to Canada.ca top menu.

• English: https://cdn.canada.ca/gcweb-cdn-live/sitemenu/sitemenu-v5-en.html
• French: https://cdn.canada.ca/gcweb-cdn-live/sitemenu/sitemenu-v5-fr.html

Static header and footer

Static HTML header and footer that you can just copy and paste in your project, with slight modifications e.g. metadata.

GCWeb Canada.ca theme) visual update - V5

The GCWeb v5 (Canada.ca theme) visual update are supporting the Canada.ca Content and Information Architecture Specification 2.0.

• Migration instruction (from v4.0.29 to v5)
  • Change: Page footer
  • Change: Page header Structure
  • Change: Menu
  • Change: Home Page
  • Change: How to identify navigation pages (Themes, topics,...)
• New features (for web publisher):
  • Double space for list
  • Responsive list
  • Linked figure design pattern
  • Content block with a limited width
  • Call to action button
• Demos (Where you can see all the area where a change apply):
  • Home page
  • Content page - Limited width content
  • Content page
  • Theme template
• Workaround for implementer:
  • See the section bellow Temporary avoiding the visual difference
  • Content page - GCWeb 4.0.29 font style
• Temporary internal list of issues and todo

Noticable visual difference with no markup change

This is a list of perceptible changes that would be visually noticiable if only the GCWeb javascript and CSS are replaced without doing any markup change as identified by the migration instruction.

• Language Toggle link: Font changed
• Breadcrumbs: Font changed
• Breadcrumbs: arrow replaced with chevron
• Search box: Larger, white background replaces grey, closer to menu
• Menu: Font changed
• Header: White background replaces light grey
• <h1>: Larger font
• Text: Font larger
• Social Media Strip: Lowered
• <h2>: Smaller font
• <p>: Larger font

Temporary avoiding the visual difference

The increased font size and the new line-height might impact some visual design. Mostly the one where it was thighly designed for desktop first, like some campaign pages.

Here a list of design items to look at:

• Pages where the number of characted (like in a title) are closely counted to ensure it fit in a specific container, like to remain in one single line. For example the title of a feature tile.
• Pages where there is textual content inside a column of a width of 1 and 2. Textual content inside a column of width of 3 might or might not cause issue. Those cases might require you to re-think how to present the information.
• Pages where datatables was intentionally skrinked in order to fit all columns inside the extra-large view port (desktop). For example a datatable with 10 columns or more in a report.

The visual difference is avoided for:

• Form content inside a form
• Button (exception of the new call to action button)
• Content inside a container with the CSS class force-style-gcweb-4-0-29

Here a working example: Content page - GCWeb 4.0.29 font style

Reference and notes

• The menu was designed similary like the menu design pattern from WAI-ARIA 1.1
• The double role on list item in the menu was added as suggested by the W3C validator because the role=none are not widely supported yet.
• Originally the attribute aria-haspopup was set with the value menu. But in order to pass the whatwg validation, when the markup are validated as output by the server, as a best practice because w3c , the value of aria-haspopup was change to true. As per the WAI-ARIA 1.1 spec. the value true is equivalent to setting the value menu - https://www.w3.org/TR/wai-aria-1.1/#aria-haspopup (Note the validation, as per WCAG 2.0 and WCAG 2.1 should be done after all JS has run and the DOM is mark "ready". Also the DOM markup should validate after any DOM manipulation that are happing in the page)
• The menu item focus are managed by using a Roving tabindex. - https://www.w3.org/TR/wai-aria-practices-1.1/#kbd_roving_tabindex
• WAI-ARIA Practices 1.1 - 3.15 Menu Button
• WAI-ARIA Practices 1.1 - 3.14 Menu or Menu bar
• WAI-ARIA Practices 1.1 - Editor Menubar Example
• WAI-ARIA Practices 1.1 - Action Menu button using element.focus()

Evaluation and report

• February 20, 2019: Test on the menu component (French only)
• November 16, 2018: 2 - Regression user acceptance testing of WET plugin for GCWeb theme version 2
• November 14, 2018: 1 - Accessibility assesment of GCWeb theme version 2
• October 22-26, 2018: Partial screen reader compatibility test has been made to the new menu, but for a different markup compared to the one published as Oct 31. From that test, the recommendation was to replace the button text "top menu" by "main menu".

Special notes

Adding Font Awesome icons

Requirement

Based on the discussion FontAwesome originally opened February 2017.

Background

Adding Font Awesome to GCWeb should allow its icons to be relied upon for any Canada.ca content. This can allow for richer content than what's available from GlyphIcons.

The preferred means of installing FontAwesome is to use the style sheet link as described on the Font Awesome Start using FontAwesome page.

The style sheet link includes a hash for the integrity check.

Font Awesome's privacy policy notes that it tracks use of the CDN including what fonts are downloaded and when, with no personally identifidable data tracked.

Font Awesome collects data about use of its content delivery networks.

Use of font smoothing anti-aliasing

Requirement

Configure the font smoothing anti-aliasing CSS for GCWeb theme v5.

Background

November 2^nd, 2018

It is explicitly said that anti-aliasing CSS is not in a standard track and it is recommended to avoid. Currently that feature is only limited to webkit browser and FF by applying some prefix vendor.

It was an experimental feature that was removed from an old CSS W3C editor draft. It is only supported by Chrome browser. That feature wasn't consistently supported by Chrome. Considering the published article referenced by Mozila that support to avoid font smoothing and it's removal from the old editor draft specification, the wet-boew team lead consider that feature at risk and recommend to avoid it. At the time of publishing this, no extensive research was made to find an alternative solution that would meet the above requirement.

• Though present in early (2002) drafts of CSS3 Fonts, font-smooth has been removed from this specification and is currently not on the standard track. - https://caniuse.com/#search=font-smoothing
• This feature is non-standard and is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future. - https://developer.mozilla.org/en-US/docs/Web/CSS/font-smooth
• Outdated working draft - W3C CSS font - https://www.w3.org/TR/WD-font/#font-smooth
• See also: Please Stop "Fixing" Font Smoothing – UsabilityPost
• See also: Laissez-faire font smoothing and anti-aliasing

The above article makes reference that playing with the anti-aliasing feature make the font more blury for use, so less readable.

Rational / Justification

November 16, 2018

[...] we seem to be unsure if there is actually a technical or other issue with implementing the font smoothing for various browsers. Right now there are two calls to font smoothing - code for smoothing which is for several browsers (Chrome, etc), and then code for the Mozilla specific smoothing for Firefox.

We would like to pursue this because the smoothed fonts are what we've been showing everyone in for approval, and it’s what we’ve been testing positively with users (across many browsers).

We should also mention that the majority of our users see the site in Chrome so we want to give them the best experience possible.

Not having the font smoothing available to EI users does not cause them any harm.

We would like to pursue the implementation in a way that could be done immediately, but we understand it may need to be implemented differently long-term.

The use of [aria-expanded] in the menu

The menu was designed as per the WAI-ARIA Practice 1.1 for the Menu or Menu bar. In the section WAI-ARIA roles states and properties the fifth bullet items say the element with the role menuitem has the aria-expanded state. The use of that state is illustrated by the WAI-ARIA Practice 1.1 menu bar example 2.

It was noted that as per the description of the aria-expanded attribute in WAI-ARIA 1.1 spec it don't allow to have the attribute aria-expanded set on element with the role menuitem.

However, a research revealed the WAI-ARIA specification 1.2 (working draft) have an updated definition for aria-expanded. It now allow to use that state on on element with the role menuitem. Here some reference:

• W3C Working Draft - Accessible Rich Internet Application (WAI-ARIA) 1.2 - aria-expanded (state)
• w3c/aria github issue #454 - ARIA 1.1: aria-expanded is not supported on menuitem roles
• w3c/aria-practices github issue #630 - For Navigation Menubar Example, aria-expanded should go on menu, not menuitem

Use of Google API

GCWeb was already leveraging Google API to retreive jQuery library and now with the new look it leverage Google API to retreive two fonts, Lato and Noto.

Here an excerpt of the answer we got from TBS on the usage of Google API for GCWeb.

December 12 2018

I don’t see an issue with this at all. It looks to be just a public open source API, so I would just go ahead and consume it. If you already have another Google API you’re consuming, you’ll likely even be able to use the same key.

If you’re encountering questions and resistance, feel free to loop me in. Whenever you’re using a 3‌rd party API, latency and reliability is obviously a consideration. I would just ensure you think through the various failure scenarios to understand what happens to your website if the API is down, unreachable because of GC network outage, or if there are delays in the API responding.

Technical note about the design of the menu

• The orientation of the sperator before the most requested sub-menu change from vertical to horizontal in tablet/mobile view
• The most requested sub-menu has an attribute to indicate the JS plugin that sub-menu need to remain expanded in medium and large device. data-keep-expanded="md-min"
• The use of the aria-controls on menu item that open sub-menu might not required. Before to take a decision, we should do more testing to confirm the useless of that property on sub-menu items. Comments received from one user testing with a screen reader has recommended to remove it for the menu button.
• role=none: As per WAI-ARIA 1.1 practice, there example use the role=none for each list item. The W3C validator has recommended to use both role "none" and "presentation" because the role "none" is not yet widely supported. The use of the role "none" currently (2018-12-28) trigger an error by the validator.nu but not by the W3C validator. The issue is the validator.nu don't support yet WAI-ARIA 1.1 and because of that we would only keep one role role=presentation instead of having a dual role. The list item role should be updated once the role "none" would be widely supported.
• aria-haspopup=menu: As per WAI-ARIA 1.1, the aria-haspopup property can have multiple value other than "true". The value set to "true" is the same as being set to "menu". Ideally, the menu design would use aria-haspopop=menu instead of aria-haspopup=true because it is more explicit. The validator.nu trigger an error when the aria-haspopup is set to menu instead of true because it don't support WAI-ARIA 1.1. The anchor and the button with the attribute aria-haspopup should be updated once validator.nu support WAI-ARIA 1.1. Using "menu" instead of "true" shouldn't impact assisstive technology that only support WAI-ARIA 1.0

Customizing GCWeb for your implementation variant

The build script of GCWeb has been adapted to allow implementation variant to include their specific CSS with the gcweb CSS in a way that reduce potential git conflict when updating to the latest version of gcweb.

• Create a fork or an clone of GCWeb project.
• Custom Style: Copy and rename the folder src/variant-default for src/variant. The custom SCSS added in variant would not conflict when updating your GCWeb version.
• Custom plugin: Follow the wet-boew plugin guidance/structure and add your code in src/plugin folder.
• Building: Use the GCWeb build system, all your custom CSS and custom plugin for your variant would be packaged together with GCWeb compiled files.

Test cases

• From examples - test cases