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)
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.
|Bootstrap 3||Bootstrap 4 (experimental)|
|Header||Source code, line 1 to 89||Source code, line 1 to 66|
|Footer||Source code, line 187 to 233||Source code, line 84 to 122|
|Special assets||Download GCWeb||Download experimental CSS|
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):
- Demos (Where you can see all the area where a change apply):
- Workaround for implementer:
- Temporary internal list of issues and todo
Noticable visual difference with no markup change
- 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
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=noneare not widely supported yet.
- Originally the attribute
aria-haspopupwas 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
trueis 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
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".
Adding Font Awesome icons
Based on the discussion FontAwesome originally opened February 2017.
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 collects data about use of its content delivery networks.
Use of font smoothing anti-aliasing
Configure the font smoothing anti-aliasing CSS for GCWeb theme v5.
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
[...] 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
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 -
- 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.
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 3rd 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.
- The use of the
aria-controlson 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=nonefor 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=presentationinstead 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. The custom SCSS added in
variantwould not conflict when updating your GCWeb version.
- Custom plugin: Follow the wet-boew plugin guidance/structure and add your code in
- Building: Use the GCWeb build system, all your custom CSS and custom plugin for your variant would be packaged together with GCWeb compiled files.
Report a problem on this page
- Date modified: