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
It clashes with the new `$govuk-focus-colour` now. This commit changes
it to half way between `govuk-colour("dark-grey")` (`#505a5f`) and
`govuk-colour("mid-grey")` (`#b1b4b6`) from the Design System. Dark was
too dark and mid was too light.
It also adds a line of JS to let us easily switch the header to blue by
clicking on it, which is useful for taking screenshots etc.
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.
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
We want to change cache keys for templates and broadcasts to include
their service ID. So cache keys should change from
`template-{template_id}-versions` to
`service-{service_id}-template-{template_id}-versions`.
The first step of this which needs to be deployed as a change first is
to delete both keys when updating service templates (even if they key is
not yet set). This means that when we release code in the next PR to
start setting the new key, we won't run into a case where either the old
or the new key can remain set with stale data.
