Please update jQuery dependency. 3.3.1 has vulnerabilities.

This is currently hardcoded into the front-end .ss templates.

PRs

• #112
• #113

Medium priority:
There is no permanently visible label for the search field. The placeholder text should not be used as a replacement for a label.

When a person enters information into an input, its placeholder content will disappear. The only way to restore it is to remove the information entered. This creates a challenging experience for users with cognitive impairment where guiding language is removed as soon as the person attempting to fill out the input interacts with it.
Solution: Provide a permanently visible "Search" label.

Note: Could possibly be needed to be ported into Starter too.

cc @silverstripeux

CWP 2.3.0-rc2 w/ Wātea 3.0.0

In order to be automatically included in the TinyMCE bundle, it needs to be in css/editor.css and listed in vendor-expose.

See https://github.com/silverstripe/cwp-watea-theme/blob/1.1.1/templates/Includes/Footer.ss#L63-L67

The field for the image is here: https://gitlab.cwp.govt.nz/cwp/agency-extensions/blob/master/code/Extensions/CWPSiteConfigExtension.php#L149-158

Version: CWP 2.2.0-rc1

In CWP 1.x it looks like this:

In CWP 2.2.0-rc1 it looks like this:

Version(s) affected

3.0.0, but probably affects all versions

Issue

The menu navigation works fine when viewing the page is not inverted.

However, when the page is upside down, the menu navigation does not display correctly as the carousel image is overlaying on top of the dropdown. The carousel image also seems to overlay on top of the carousel controls/heading, making the site even less accessible.

Note: when taking the background-image off the carousel items, the navigation and carousel controls work correctly.

Boostrap-accessibility-plugin 1.0.2 relies on jQuery 1.

Yet this theme's v2 templates use jQuery 3. This can lead to errors - in my case for example "size" call, used in the plugin, is deprecated.

Looks like v2 should either not be using the plugin OR not using jquery 3 (but then see jQuery 3 vulns).

Needs a docs update? https://github.com/silverstripe/cwp-watea-theme/tree/master/src/scss

Pull requests

• silverstripe/cwp-starter-theme#69
• #32

Version: 3.x

The underline currently overhands the navbar. New designs indicate it should be inside its container instead.

Original:

New designs: https://invis.io/AWO7CJSK426#/331465174_Wa-tea_Plus_Landing_Page

cc @silverstripeux

Note: CWP demo site: (Quicklinks section)

Medium priority:
The "Introducing CWP 2.0" and "the CMS" links are distinguished within the sentences by use of colour alone.

People with low vision/colour vision difficulties will be unable to distinguish that these are links. While some links may be visually evident from page design and context, links within text are often visually understood only from their own display attributes. Removing the underline and leaving only the color difference for such links would be a failure because there would be no other visual indication (besides color) that it is a link.

Use a method other than colour to distinguish links (e.g. bold, underline, italics).

I'd suggest using an underline in this case.

Watea 3.0.x-dev with CWP 2.3.x-dev

Wātea 3.0.x-dev

Language selector background colour is added to demonstrate the issue.

Moved to https://github.com/silverstripe-security/security-issues/issues/26

Wātea 3.0.x-dev

https://screencast-o-matic.com/watch/cqhh0jZdcW

Hard refresh shows this, standard refresh doesn't.

Chrome on MacOS

High priority:
Upon activating the Previous or Next carousel controls, there's no indication to non-sighted users that anything has happened.

There is no way for screen reader users to know that the content of the carousel has changed.

To indicate that the slide has changed, use an ARIA live region to announce the newly displayed slide. The live region should only be populated with the updated slide information upon a user activating the "Previous" or "Next" buttons. When the results screen is first loaded, the live region should remain empty. The live region should be polite, and its text content replaced with something like "Slide 1 of 3:" as appropriate when the slide changes, e.g.

<div aria-label="polite" class="sr-only">Slide 1 of 3: CWP 2.0 is here</div>

Would be nice to have some basic editor.scss / editor.css functionality so that the customer doesn't have microscopic fonts in tinymce

editor.scss can literally be a copy / paste from the top of main.scss

editor.scss:

// Watea theme specific variables and overrides
@import "./variables";

// Starter theme styles
@import "../../../starter/src/scss/main";

// Watea theme mixins
@import "./utils/mixins";

// Watea theme styles
@import "./typography";

At the moment when compiling dist files and making a commit you have to run 'yarn package'. This is different from our other modules (admin etc.) which use 'yarn build'. It'd be good if we could update these for consistency for how we compile across SS.

The suggested agency-extensions module is a key module to providing additional benefit to a CMS user working with a site using Wātea. We should be making this more clear in the docs, including describing what those features are, in order to entice anyone reading this ReadMe to also install agency-extensions

We've currently not enforcing that sites with this module access the following CDN over HTTPS, which apparently could be as simple as appending 'https' to the link, here:

Uncovered this while running a browser security checker tool, message: Subresource Integrity (SRI) not implemented, and external scripts are loaded over HTTP or use protocol-relative URLs via src="//..."

See guidance from Mozilla: https://infosec.mozilla.org/guidelines/web_security#resource-loading

[User Warning] None of the following templates could be found: Array ( [0] => Array ( [type] => Includes [0] => HeaderSearch ) [1] => HeaderSearch ) in themes "Array ( [0] => watea [1] => $public [2] => simple [3] => $default ) "
GET /my-project/page-not-found/
Line 215 in /var/www/html/my-project/vendor/silverstripe/framework/src/View/SSViewer.php

Not been able to activate the watea theme on my project in config.yml file.

Existing breadcrumbs example:

New designs:

Invision designs:
https://invis.io/AWO7CJSK426#/331465174_Wa-tea_Plus_Landing_Page

cc @silverstripeux

Regression I'm noticing from the accessibility work. The text colour should be #555 it looks like it needs more specificity to override 'body.theme-accent-default-accent a:not(.btn)'

Previously started, ensure that all templates are in the correct file path and regression test.

Watea 3.0.x-dev on Chrome/MacOS

Looks like the border is doubled up, causing a slight increase in opacity

Vanilla CWP 2.3.0-rc2 with Wātea 3.0.0:

(Text is highlighted to show it)

Shown by Axe test

Overview
Currently cwp/agency-extensions is only marked as a suggested module when installing this module.

The concern is that without prior knowledge of the agency-extensions module, it won't be installed on a site and CMS users will be missing out on additional functionality.

RFC
Given these concerns, I'm suggesting we add cwp/agency-extensions as a composer.json requirement and update the this modules docs to list the additional functionality that would be provided.

Version affected:
dev-master / new major branch

Notes:

1. This module is about to receive a new major branch utilising Bootstrap4, this maybe a good time to include agency-extensions as well.
2. Some of the additional features would be opt-out by default, any new docs should make that clear.
3. I'm not yet sure of what the backwards compatibility concerns would be for someone upgrading this module to the suggested new version.

Unless I'm missing something, default Layout templates should exist in a folder hierarchy that matches the namespace of the PageType to which they belong. In this case, it's:

templates
  CWP
    CWP
      PageTypes
        Layout
          EventPage.ss
          NewsPage.ss
          ...

Medium priority:
The blue carousel buttons are not clearly visible due to the low contrast ratio against their adjacent background (Foreground: #0F7EB2; Background:#various). The same issue occurs with the carousel indicators, especially the ones that are greyed out.

People with low vision or colour vision difficulties will be unable to clearly discern the buttons. Use a Contrast finder tool to choose and set a different element colour or background colour to meet the necessary contrast ratio of 3:1 against adjacent colours for all instances of this colour combination (includes focus and hover states).

cc @silverstripeux

We could consider darkening the mask again also. Note: that the white border buttons did not come up as being unaccessible so we could do something similar?

The CI in .github/workflows/ci.yml does not actually do anything

There's a comment in that file explaining why

tl;dr this module requires scss for cwp-starter-theme and expects it to be in a sibling directory, but it's not in a CI context

High priority:
The carousel indicators work for mouse users, but they are not keyboard accessible, and they have no content or accessible name, so are not announced by screen readers.

Users who rely on keyboard will not be able to access these carousel indicators or know what their purpose is.

If they were focusable and keyboard accessible buttons, they should have content like "Slide 1 of 3". As a list of buttons for controlling the carousel, they should have a group name, which can be done with aria-label="Slide controls" or similar on the <ol> Example:

<ol class="carousel-indicators" aria-label="Slide
controls">
   <button aria-label="Slide 1 of 3" class=""><li
data-target="#carousel-slide" data-slide-to="0"
class="" name="carousel-item-1"></li></button> ...
</ol>

CWP 2.3.x-dev with 3.0.x-dev Watea

The paragraph font-weight comes from here:

.theme-font-fira-sans p {
    font-weight: 300;
}

The list item weight comes from here:

body {
    /* ... */
    font-weight: 400;
}

I assume they should be the same.

cc @silverstripeux @jamessilverstripe

Wātea 3.0.x-dev

Is not a problem with only starter installed.

Wātea 3.0.x-dev

These two components have rounded corners, where in version 2.1.x-dev they are more square (I don't have the language selector in this screenshot):

This also doesn't match the dropdown styles from the navigation, which are square:

cc @jamessilverstripe

High priority:
There's no programmatic indication that the entire widget is a carousel, nor of the purpose of the carousel.

There is no way for screen reader users to understand the purpose or role without a programmatic indication that the widget is a carousel.

Apply role="region" and aria-label="Slideshow: CWP 2.0 Theme" or another meaningful and descriptive name to the entire widget's container. Example

<div id="carousel-slide" data-ride="carousel" class="carousel slide text-center" role="region" aria-label="Slideshow: CWP 2.0 Theme">

The region role serves to encapsulate the carousel widget as a discrete unit, making it easier for screen reader users to navigate past as a whole so the "End of carousel" div should be removed (elements that are in the tab order should be focusable anyway).

Remove:

<div tabindex="0" class="sr-only"> End of carousel.</div>

Appears to affect all browsers.

Potentially related issue in IE10 on Starter Theme

The NZGOVT logo is currently linked to: http://newzealand.govt.nz/.

It should be updated to: https://www.govt.nz/

Wātea 3.0.x-dev on Safari/MacOS

When hovering over sub-menu navigation items, the background edge looks a bit choppy:

I think this is because the menu itself doesn't have sharp edges, whereas we have a "background color is grey" rule for hovering menu items.

Many of the core SilverStripe modules with notable frontend assets now have npm linting and build dist file comparisons in Travis to ensure that (A) new changes lint correctly, and (B) that the dist files are correctly rebuilt.

We should add this as a single build step for the CWP themes.

This module would also need to run npm install from inside the starter theme before doing this.

Related: silverstripe/cwp-starter-theme#58

Pull requests

• #24

Watea 3.0.x-dev

The "Spam it" and "Reject it" buttons have the markup <a ... class="btn btn-warning">...</a> for example, and should have white text from default Bootstrap functionality. The CSS specificity is too high from the colour picker functionality, so the text is blue instead.

NewsSummary.ss

<time datetime="$Created.Nice">{$Created.Nice}</time>

should probably be

<time datetime="$Date.Nice">{$Date.Nice}</time>

Date is the cms editable one, and is what's used for sorting NewsPage's

The navigation needs to be properly audited for accessibility against WCAG 2.1, and tested using multiple assistive technologies, across multiple platforms. You'll discover a range of severe accessibility issues with the navigation implementation. The code needs to be reviewed and remediated by somebody with a high level of accessibility knowledge (testing, semantic HTML, correct ARIA usage, etc).

I'd suggest, at a minimum, the navigation should be tested with:

1. VoiceOver on iOS
2. VoiceOver on macOS
3. NVDA on Windows
4. JAWS on Windows
5. TalkBack on Android
6. Keyboard-only
7. axe DevTools

Some current issues I've picked up are:

• Navigation menus cannot be announced by VoiceOver on iOS, with each menu item simply announced as "menu item" - therefore making it impossible for VoiceOver users to know what the menu item actually is
• Keyboard-only users on desktop cannot access expanded dropdown menus in the navigation - the keyboard focus just skips over the expanded content
• Improper use of role=menubar, role=menuitem, role=menu - this results in a huge amount of audio clutter for screen reader users e.g. the "expand" buttons are announced by NVDA on Windows as "menu item menu button collapsed subMenu Display Features submenu pages" - this has a huge amount of clutter and makes the interface hard to understand for screen reader users

Recommendations:
Look at the navigation implementation on digital.govt.nz, how it does not use the menubar/menu/menuitem roles, and provides a screen-reader and keyboard-accessible experience

Just installed the latest version of Wātea (3.0) and the Site name, site tag line and search border in desktop and mobile should be white, this includes the mobile menu border and icon. I think some colours are coming through from the styles 'colour: inherit.'

Also noticing some white borders in mobile above/below the search which shouldn't be there.

I'm also noticing the nav items seem to be darker than usual:

Looking through James' Wātea Plus designs the nav items are white.
Hover: Border should appear with no text changes and should be placed on the nav bar rather than below it. Current page: Text should be bold and border should be present.
See #36 for more details.

See designs here: https://invis.io/AWO7CJSK426#/331473258_Wa-tea_Plus_Content_Page

cc @silverstripeux

The link should take up the full space of the li so that its all clickable and the hover state of the li can’t be seen when the a tag is active.

CWP 2.3.x-dev with Watea 3.0.x-dev

A new feature in Wātea 3.0 (over 2.x) is that breadcrumbs to each page are included in the search results. There are some issues with that:

• BreadcrumbsTemplate.ss in starter theme assumes it will be shown once in a page, and provides an accessibility label "You are here" pointing at the ordered list of breadcrumb items - this isn't true in the case of search results
• As above, the label has an ID attribute (which must be unique in the document)
• I'm not sure it has been considered if items other than pages are in the search results, e.g. files - presumably breadcrumbs wouldn't be relevant for files

cc @silverstripeux @jamessilverstripe

Axe report

IDs used in ARIA and labels must be unique

Issue description: Ensures every id attribute value used in ARIA and in labels is unique

Impact: critical
Element location: article:nth-child(1) > header > nav[role="navigation"] > p
Element source: <p class="sr-only" id="breadcrumbs-label-">You are here</p>
To solve this violation, you need to fix the following:

• Document has multiple elements referenced with ARIA with the same id attribute: breadcrumbs-label

Might just be "what bootstrap says", but we should spell that out for themes - particularly for contributors. /cc @sachajudd