During the move to GOV.UK Frontend checkboxes our template list has
started to be wrapped in a `<div>` with the `govuk-form-group` class.
This adds extra spacing, like you’d want in a regular transaction
service which might have multiple sets of form controls on a single
page.
It isn’t appropriate on our templates page, because there should be a
consistent rhythm where the space between each checkboxes is the same as
the space between the search box and the first checkbox, to the last
checkbox and the buttons. Not having this space is also consistent with
other pages with sticky grey buttons, eg the team members page.
This commit also fixes a typo in the name of one of the classes used to
control spacing between the checkboxes and search bar.
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’ve had some feedback from user research that difference between
‘will get alert’ and ‘likely to get alert’ is not clear, and it’s hard
to tell if the latter is inclusive of the former. This leads people to
question the validity of these numbers, which is important, because an
the estimate should give you some idea of the impact of what you’re
about to do.
This commit reformats the number as a range, for example 1,000 to 2,000
phones.
If the range is small, eg 40,000,000 to 40,800,000 then this suggests
a false level of accuracy. So instead we just give one number and say
it’s an estimate, eg ‘40,000,000 phones estimated’
Accessibility audit uncovered issues screen-reader users would
have with autofocus on Notify pages. Autofocus can lead to
confusion for those types of users and make them miss parts
of the page.
Hence, we decided that autofocus will be turned off by default
for live-search component.
We decided to keep the autofocus on for live-search text box when:
1. the page is a task page - as opposed to browsing pages, where
user wonders freely, task pages have more established flow, so
page focusing on textbox can actually be helpful.
2. page does not have actionable elements above the autofocus.
Accessibility audit uncovered issues screen-reader users would
have with autofocus on Notify pages. Autofocus can lead to
confusion for those types of users and make them miss parts
of the page.
Hence, we decided that autofocus will be turned off by default
for live-search component.
We decided to keep the autofocus on for live-search text box when:
1. the page is a task page - as opposed to browsing pages, where
user wonders freely, task pages have more established flow, so
page focusing on textbox can actually be helpful.
2. page does not have actionable elements above the autofocus.
Accessibility audit uncovered issues screen-reader users would
have with autofocus on Notify pages. Autofocus can lead to
confusion for those types of users and make them miss parts
of the page.
Hence, we decided that autofocus will be turned off by default
for live-search component.
We decided to keep the autofocus on for live-search text box when:
1. the page is a task page - as opposed to browsing pages, where
user wonders freely, task pages have more established flow, so
page focusing on textbox can actually be helpful.
2. page does not have actionable elements above the autofocus.
Accessibility audit uncovered issues screen-reader users would
have with autofocus on Notify pages. Autofocus can lead to
confusion for those types of users and make them miss parts
of the page.
Hence, we decided that autofocus will be turned off by default
for live-search component.
We decided to keep the autofocus on for live-search text box when:
1. the page is a task page - as opposed to browsing pages, where
user wonders freely, task pages have more established flow, so
page focusing on textbox can actually be helpful.
2. page does not have actionable elements above the autofocus.
Accessibility audit uncovered issues screen-reader users would
have with autofocus on Notify pages. Autofocus can lead to
confusion for those types of users and make them miss parts
of the page.
Hence, we decided that autofocus will be turned off by default
for live-search component.
We decided to keep the autofocus on for live-search text box when:
1. the page is a task page - as opposed to browsing pages, where
user wonders freely, task pages have more established flow, so
page focusing on textbox can actually be helpful.
2. page does not have actionable elements above the autofocus.
Accessibility audit uncovered issues screen-reader users would
have with autofocus on Notify pages. Autofocus can lead to
confusion for those types of users and make them miss parts
of the page.
Hence, we decided that autofocus will be turned off by default
for live-search component.
We decided to keep the autofocus on for live-search text box when:
1. the page is a task page - as opposed to browsing pages, where
user wonders freely, task pages have more established flow, so
page focusing on textbox can actually be helpful.
2. page does not have actionable elements above the autofocus.
It was missing the base class so didn’t get all the styling (like the
spacing and uppercase text).
Already fixed this for step 6, but less haste, more speed.
If you’re adding another area to your broadcast it’s likely to be close
to one of the areas you’ve already added.
But we make you start by choosing a library, then you have to find the
local authority again from the long list. This is clunky, and it
interrupts the task the user is trying to complete.
We thought about redirecting you somewhere deep into the hierarchy,
perhaps by sending you to either:
- the parent of the last area you’d chosen
- the common ancestor of all the areas you’d chosen
This approach would however mean you’d need a way to navigate back up
the hierarchy if we’d dropped you in the wrong place. And we don’t have
a pattern for that at the moment.
So instead this commit adds some ‘shortcuts’ to the chose library page,
giving you a choice of all the parents of the areas you’ve currently
selected. In most cases this will be one (unitary authority) or two
(county and district) choices, but it will scale to adding areas from
multiple different authorities.
It does mean an extra click compared to the redirect approach, but this
is still fewer, easier clicks compared to now.
This meant a couple of under-the-hood changes:
- making `BroadcastArea`s hashable so it’s possible to do
`set([BroadcastArea(…), BroadcastArea(…), BroadcastArea(…)])`
- making `BroadcastArea`s aware of which library they live in, so we can
link to the correct _Choose area_ page
previously the back link went to choosing a library.
Now, if you view a district from a county, go back to the county page.
Otherwise, go back to the top level of the library.
I’ve swapped the order of the first paragraph so it joins into one
sentence, and leads with ‘Notify has not broadcast your alert’ which
is the response to what the user has just done. I don’t think we need
to say ‘still’ because the idea is users will swap back and forth
between training and real depending on the situation.
For a training broadcast the user doesn’t get that immediate feedback
that something has happened, like they would with a real alert, or even
sending themselves a text message.
This commit adds another tour-style page which will interrupt their
journey and hopefully reinforce the message we’ve given them earlier in
the tour.
We’re adding this because we’ve found in research that users don’t have
a good grasp of the consequences and severity of emergency alerts,
versus regular text messages.
