The CSS that cancelled outline on focus events not
fired by the :focus-visible heuristic is being
overridden by the higher precedence of the outline
style for :focus, due to its use of !important.
This adds !important to the cancelling CSS. This
brings that block up to the same level as that for
:focus, meaning the :focus-visible styles will win
because they sit lower in the stylesheet.
There is a slight variance in how the line between
the map buttons is rendered when in forced-colors
mode and when not. This is not helped by it
alternately being rendered as either:
- a gap between buttons, showing the container
colour
- a border-bottom on the first button
This attempts to flatten these styles so it is
only styled as a gap between the buttons so
changes to how its colour renders in different
modes can just be dealt with on the container.
@benthorner pointed out a few things about these
styles that could do with changes:
- the outline-offset will only appear when the
outline does, which is in forced-color mode when
the browser assigns a colour to it, so it
doesn't need to be assigned in a media query
targeting forced-color mode
- the `&:focus:not(:focus-visible)` selector
stops the focus styles showing in scenarios
where:
1. the browser supports :focus-visible
2. focus comes from something other than tabbing
to the map
...so we don't need to target :focus-visible
specifically.
This applies changes to these styles to remove
those not needed and move some to a better place.
Related to this comment on the associated pull
request:
https://github.com/alphagov/notifications-admin/pull/3996#discussion_r699246969
The content of the map buttons jumped on Chrome
and Safari when focused.
It turns out this was because I was testing in
Firefox which Leaflet had identified as having
touch capability (and so added the .leaflet-touch
class). Leaflet makes the buttons 30px rather than
26px for touch-capable devices/browsers so the
jumping was down to the line-height being set for
the wrong container height.
This adds styles to give a different line-height
when touch is available, to match the Leaflet
styles.
Leaflet does this anyway when they're focused
(through JS) but we found holding shift when on a
focused button, which you do when tabbing
backwards, turns this off for some reason so you
see the outline the browser applies by default.
This turns all outlines off to stop that
happening.
Worth nothing that focus is indicated by:
- a change of background colour instead when
tabbing
- a border in forced-color mode
...so the outline is not needed.
Users on devices/browsers that support touch have
the rounded corners styles applied by this
selector:
.leaflet-touch .leaflet-bar a:first-child,
.leaflet-touch .leaflet-bar a:last-child
It has a higher precedence than the existing
selector we use to override it so our overrides
are ignored:
.leaflet-bar a:first-child,
.leaflet-bar a:last-child
This changes the selector for our block of styles
to include one matching the existing styles above
so devices/browsers also get our styles.
Note 1: this actually means some styles were no
longer needed so this also removes them.
Note 2: oddly, this was spotted in Firefox when
displaying high contrast mode on desktop. So not a
touch device but leaflet's JS is marking it as
such.
Also includes a quick fix for high contrast mode.
The buttons are separated by a horizontal line by
default, styled as a border above the 2nd button.
Both buttons use the border when focused in high
contrast mode to provide a form of outline.
This takes away the line dividing them, because
you can only have one border.
The buttons are still separated by a 1px margin so
this just sets a background colour on the
container to simulate the divider.
Makes the controls and links inside it match GOVUK
Frontend styles and:
- gives the map container a focus style matching
that for GOVUK Frontend text inputs
- makes it all work in high contrast modes (on
Windows and Firefox)
Note: the focus style for the container is applied
with :focus-visible so only appears when it gets
focus directly, not when it does due to child
elements (like the controls or links) getting
focused. Browsers without support for
:focus-visible get the same styling for all forms
of focus.
Was just in one of those meetings where it felt like writing this would
take less time than I’d already spent talking about its relative
priority…
---
In the admin app you can already set the broadcast channel as 'test', 'severe' or 'government'.
Aim:
- Add the 'operator' channel to the list of channels you can pick for the admin app broadcast services
Note:
- The API already supports this - https://github.com/alphagov/notifications-api/pull/3262
- The CBC proxy does not yet support the operator channel and this will need a separate card. That card has not yet been written because the interface has not been agreed between us and the MNOs yet.
- Will need to have the ability to select the operator channel for just a single MNO like we do for the other channels
- If we add this, we shouldn't actually start using it until the MNO in question gives us the go ahead.
---
https://www.pivotaltracker.com/story/show/178485177
Previously we could only select a provider when using the test
channel, but this is also required for others channels when we
do tests on the production network with individual MNOs.
In order to reduce duplication and improve consistency, I've reused
the new broadcast_service_name_tag macro to show the setting.
At the moment if you’re invited to a live broadcast service you get the
training mode tour. This is misleading, and could make people think they
weren’t in danger of sending a real alert.
This commit adds a short, 2 step tour for users invited to a live
broadcast service.
This hides the "Register" button and shows an error that's specific
to one of two ways a browser may not support WebAuthn:
- JavaScript is disabled (there's no possible fallback for this).
- WebAuthn API is not supported (e.g. on Internet Explorer).
We could add a similar check for the API in the JS code to handle
the button click, but hiding it seems like enough protection.
In order to avoid elements flashing when the page loads, this uses
a view macro to embed a script at the start of the body element,
which is the same approach used for the "js-enabled" class flag [1].
Tested with Chrome and IE 11.
[1]: https://github.com/alphagov/govuk-frontend/blob/main/src/govuk/template.njk#L31
Previously there was no indication that a service was suspended.
While this could also be shown for archived/deleted services, the
meaning is similar enough that it makes sense there too - the name
of the archived service should distinguish it as being archived.
The content length message was making the page jumpy and causing reflows
in three ways. This commit addresses each of those ways:
As the user scrolled
---
The footer went from fixed to sticky and the spacing around the message
changed. This change in spacing was needed so that the message looked
right in both contexts.
I think the best way to resolve this is to not use the sticky footer
when editing text message or broadcast templates.
On my 1440×900 screen I can fit a 5 fragment text message, plus the
‘will be charged as 5 text messages’ message, plus the save button.
Our top 10 screen resolutions according to our analytics are:
Position | Resolution | Percentage of users
---------|------------|--------------------
1 | 1920x1080 | 27.37%
2 | 1280×720 | 11.07%
3 | 1366×768 | 8.88%
4 | 1536×864 | 5.79%
5 | 1440×900 | 4.52%
6 | 1600×900 | 3.71%
7 | 1280×1024 | 3.10%
8 | 1680×1050 | 2.42%
9 | 1920×1200 | 2.33%
10 | 2560×1440 | 1.99%
When the page first loaded
---
The message is empty so takes up no space, then the javascript fires
and inserts the message, taking up a line of space.
This is resolved by making the empty message take up space with a
non-breaking space character.
When the user first typed
---
We previously didn’t show any message until the user started typing.
This meant that, with the above fix, there was a larger than normal
empty space between the textarea and the save button.
This is resolved by always showing the message, even when the user
hasn’t typed anything yet.
***
These are design decisions which made sense when the message was
displayed along side the button, but we’ve had to change now that the
message is above the button.
We feel that this is more appropriate because it’s part of the
information you’re agreeing to before you hit submit.
Sometimes users can missing information that doesn’t start left-aligned
to the column they’re interacting with.
It also makes it closer to the Design System component.
We’re keeping it in the sticky footer, so that it’s always visible no
matter where in the message you’re scrolled to (this means you won’t
have to edited to content then scroll down to check whether you’ve
made it fit).
This looks tidy, and because of the sticky footer it means the message
is always visible, even if your template is quite long. So no matter
where you’re scrolled to in the template you don’t have to scroll to the
bottom to see the count update.
An accessiblity audit done as part of Notify's
service assessment raised the following problem
with our big_number component.
When you turn CSS off, the sentence in the
component is split onto separate lines.
This was because the number part is wrapped in a
<div> which browsers were interpreting as being a
separate sentence to the label.
So "1 letter", where "letter" is the label, was
seen as:
"1"
"letter"
The accessibility expert consulted on this pointed
out that this would sound confusing for users of
screen readers when moving through the document
sentence by sentence.
These changes:
- make the <div>s into <span>s which are 'phrasing
content' and so are interpreted as part of the
same sentence
- change the CSS so the number will still sit
on top of its label text
The HTML5 spec has a section on how browsers
should arrange text into paragraphs that explains
what was happening in more detail:
https://www.w3.org/TR/html52/dom.html#paragraphs
In very old browsers it used to be that you could only make 2 concurrent
requests from the same origin.
So base64 encoding of images into CSS was an optimisation that became
popular because it reduced the number of separate requests.
However base64 encoding images has a few disadvantages:
- it increases the size of the image by about 30%
- it increases the size of the CSS file, which is a
[render blocking resource](https://web.dev/render-blocking-resources/)
so makes the page appear to load more slowly for the sake of some
images which, on most pages, never get used
- GZipping things that are already compressed (for example PNG data) is
very CPU intensive, and might be why Cloudfront sometimes gives up
Removing the inlining of images reduces the size of the CSS we’re
sending to the browser considerably:
–| Before | After | Saving
---|---|---|---
Uncompressed | 198kb | 164kb | 17%
Compressed | 38kb | 23kb | 39%
Raised by the service assessment accessibility
review as a problem for the footer due to it
having a mix of text and links.
This also makes it match the latest GOVUK Frontend
style.
Since the focus background colour is now Design System yellow, the text
should be black for sufficent contrast.
This wasn’t happening because the `:link` selector’s definition had
greater specificity.
We use a hack to extend the focus style of single
links in template list items (those not part of a
path of links).
This extended the 'focus box' downwards so it
covered the hint text below the link by the height
of the link (which is block-level).
Problems happen if the link wraps to multiple
lines. The hint is always on one line so the focus
looks over-extended.
These changes guard against those problems by
using the line-height instead of the block-height.
They include adding a Sass function to reference
the line-heights in GOVUK Frontend's Sass API:
https://frontend.design-system.service.gov.uk/sass-api-reference/#govuk-typography-scale
These make space for the folder icon using
padding-left when they have ancestors as they are
inline so it only effects the line the first link
is on. Without ancestors they are block-level so
padding-left pads the whole block.
We had a block of CSS that fixed this, by using
text-indent for those without ancestors but the
selector was broken by changes to the HTML (it was
no longer the :first-child).
This uses the :first-of-type pseudo-class instead
to ignore preceding elements of different types.
Also includes changes that move styles for links
out from under elements with a class of
.message-name, which was removed in the previous
commit.
I'm mainly making this change because it's useful
for the CSS that styles the hint text when the
link is focused for the link to have no parent
container.
That being said, there isn't really enough content
underneath these headings to justify them as it is.
I've wrapped them in a list instead because:
- they're structured like a list
- we already called them a `template-list`
This commit also replaces the `message-type` class
on the paragraph below where the headings went,
for consistency. It also removes the CSS for that
class as I couldn't find anywhere else that used
it now.
Template list items without checkboxes use the
`.message-name` and `.message-type` classes for
their links and hints.
This means styles used to expand the focus area
previously are clashing with the new approach.
This removes the old ones and gives
`.message-type` paragraphs a non-static position
to give them a z-position and so raise them above
the expanded link area.
