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.
This change has been made because autofocus has been confusing
to users of screenreaders because they orient themselves by
what is in focus. Moving it when the page loads without warning
can cause confusion and mean they miss parts of the page
before the point focus has moved to.
So now we will only turn on autofocus if there are no other
elements in the page that need attention than the search box.
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.
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
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
