In a lot of browsers, the static position is 0px
anyway so there's no problem.
In IE11, the button sits to the left of the
paragraph above by default. Setting it in the CSS
fixes the issue.
We’ve had some feedback that the map key icons look a bit like
checkboxes, and that this might have confused a user during the
research.
So we need a way of making them look different to checkboxes. We don’t
want to change the border thickness because it matches what’s on the
map. A different approach is changing the shape.
Shapes that might still be confusing:
- circles (look like radio buttons)
- triangles (look like a warning)
So this commit changes the shape to a diamond, which is easy to acheive
by rotating the square 45 degrees.
We’ve had some feedback that relying only on luminosity and position to
differentiate between the ‘will get alert’ and ‘likely to get alert’
areas on the map might not be enough.
We don’t want to introduce another colour because:
- it will make the map look very busy
- not many other colours contrast with the map tiles as well as blue
- relying on colour only to communicate information is also bad for
accessibility
Instead we can make one of the lines a different style. I’ve gone for
dashed on the ‘likely’ line because it looks nice, and gives some
suggestion of a porous boundary.
Implementing this means using CSS border image, because a `dashed`
border (which we still have as a fallback) doesn’t render with
consistent dash sizes from browser to browser. We need consistency to
match the dashes that the map will be drawing (which use SVG not CSS
so don’t have the same problem).
We want it to be very clear whether you’re in live or training mode
because:
- you may be switching back and forth between them
- doing something in live mode when you think you’re in training mode
would have… consequences
By adding a label next to the service name you’ll will have some
indication, on every page, which mode you are in.
Style of the label is based on the ‘Tag’ component from the Design
System:
https://design-system.service.gov.uk/components/tag/#showing-multiple-statuses
There are a few places where we missed updating to the new focus styles
because they were using the `$yellow` SASS variable and not the
`$focus-colour` variable.
This commit updates them to the new colour, and where needed adds the
black lower border to match.
Includes:
- fixes for the cancel button, when selecting a
template type (after clicking 'New template')
- making the folder icon black, to match the text,
on template list items
We have some radios using the GOVUK Frontend
radios component in this app. They are version
2.x.x though so this bumps their styles to version
3.x.x to get the new focus style.
It has a hover colour so needs the focus colour
re-defined.
The `overflow: hidden` was clipping the black
underline of the focus style on the prev/next
links. This assumes it was only there to contain
the 2 floating links so replaces it with a
clearfix, which does the same without clipping the
underline.
Swaps out the old one (solid colour with lighter
grey) for one with the same colour as the text,
but no fill.
Also swaps out for an SVG for better scaling.
To help people understand that broadcasting is not a precise technology,
we have shown the estimate bleed area on the map.
Because people aren’t familiar with the technology a visual only clue is
not enough. So this commit adds a key to the map, which explains what
the different outlines mean.
It also removes the sticky footer from this page to:
- make the key visible on the page
- make people scroll and review the map before they get to the big green
button
- not reduce the size of the map any further
All other navigations have their selected item as
a link so we should match this.
Includes changes to the pill CSS so:
1. it doesn't use elements in the selectors
2. all the selectors use BEM
I did 2. because I had to change the
classes/selectors anyway, they might as well match
the style GOVUK Design System uses.
Make heading break on whitespace - it means if the combination
of name and email address is too long for the line, email address
will go underneath and be more visible.
If email address too big for the allotted space, it will break onto
the next line and all of it will be visible.
Change the HTML & CSS for user-list-item's to
support their content being split into 2 columns
of a grid instead of the edit link being
positioned absolutely.
Also includes:
1. removes `<div>`s from `<ul>` (non-valid HTML)
2. split action link out from permissions list
3. split summary of folder permissions out from
permissions list
4. introduces a class for blocks of text that
appear when there are no items.
5. fixes tests broken by changes to HTML
We write our Sass to be mobile-first, meaning we
declare the value for a property (for mobile) and
then add all other variations (for other
viewports) afterwards.
Because of this, we need mixins that produce media
queries to be able to follow declarations.
This extension to the rule is also hinted at as
good practice in the docs:
7847511b61/docs/rules/mixins-before-declarations.md
For some reason Chrome decides that using its own font declaration is
preferable to keeping the input looking as it would without autofill.
This overrides that with our bigger, better font.
At maximum zoom, the text in the items gets
cropped horizontally.
This removes the padding on their containers to
give them more space and, instead, puts it on the
content items instead.
Left-aligned content still needs some padding on
the left-hand side but centrally-aligned can grow
into the whole space.
This also reduces the padding applied below 420px
width or when the screen is zoomed below 300%.
Above that, our content needs more space between
items but below that, the space allocated to the
content is more important.
Includes implementation of new code on Reply-to
email addresses page.
The existing code put the live region on the
module element so the id and button were
read out when the state changed.
The report from the Digital Accessibility Centre
(DAC) said screenreader users were confused by the
content changing because it wasn't announced.
These changes attempt to make the state changes
clearer by:
1. moving the live region out into a separate
element so we can better control what is
announced
2. adding hidden text around to the button and text
above (sometimes the id, sometimes the 'Copied
to clipboard' text) to give more context
When the id is copied to clipboard, the button
changes but this is not announced as the
live-region text takes precedence (due to being
set to 'assertive'). Because of this, hidden text
has been added in change 2 to explain what the new
button does.
We’ve shown the broadcast tour to a few users now. We’ve learned what
concepts about broadcasting are and aren’t getting through.
So what we’re emphasising here is:
- the thing that appears on the phone (the ‘emergency alert’) not the
technology (a ‘broadcast’)
- how it’s different to other channels of messaging, eg text
We’ve generally spent a lot more time on the content and illustrations
this time around, so overall it’s should be clearer and shorter.
This also expands the communication of training mode into the header,
so it’s visible on every page (we can add another one for ‘live’
services later on).
