Brings in https://github.com/alphagov/notifications-utils/pull/889/files
At the moment, we are not doing any transformation of features before
applying geometric algorithms to them. This is, in effect, assuming that
the earth is flat.
This new version of utils implements the transformation of our polygons
to a Cartesian plane. In other words, it converts them from being
defined in spherical degrees to metres.
For the admin app this means we need to convert places where the code
expects things to be measured in degrees to work in metres instead.
The sentences in the key to the map have 2 forms:
1. the visual form, with an graphic pattern
alongside text saying what the pattern means
in the map
2. the semantic form, with text describing what
the pattern means and how big an area it covers
for this alert
This is achieved by making the graphic
non-semantic and having hidden words in the
sentence for each paragraph.
While the spaces between words are correct for
both forms of these sentences, we observed screen
readers speaking some groups of words as one when
they spoke the sentence. Most noticably, 'the
alert' was spoken as 'thealert'.
Swapping the class used to hide the visually
hidden words from ours to the GOVUK one seemed to
fix this. It's unclear why it does but the
`govuk-visually-hidden` class adds the following
styles to those in ours:
- width: 1px
- height: 1px
- white-space: nowrap
It also has `margin: 0` instead of `margin: -1px`.
At the moment, the icons in the key of the map
showing what each type of area drawn on the map
means change colour in high contrast mode. This
causes a mismatch between the areas on the map and
the key.
These changes remake the images in SVG to prevent
the colours changing in high contrast modes. They
also add a white background to the icons, to make
sure they match the areas they refer to in the
map.
The SVG used for the 'X' in the remove area button
has 2 <g> (group) elements, one wrapping
everything and one wrapping the two lines that
make the cross. The first <g> isn't needed and
means that the SVG ends up with 2 accessible
names:
1. the <svg> element gets named with the text from
the <title> because of it's aria-labelledby
attribute referencing it
2. the first <g> gets named with the text from
the <title> because the algorithm that gets the
name looks for any descendent <title>s
This removes the first <g> so only the accessible
name for the <svg> gets announced.
The size and position of the 'X' has deviated a
bit from the design intentions of the original.
The original shared the x-height of the area text
and has positioned to be vertically and
horizontally centered.
These changes assume an x-height of 11px and use
flexbox to center the new 'X' horizontally and
vertically.
This also tweaks the visual state when focused and
then hovered so matches other buttons without
breaking the design.
The text never had underlines like our other
link-button components so always looked like
buttons. If they look like buttons, they should
act like them too and have those semantics.
This give them a role of button and uses the class
and data attribute for the button component from
GOVUK Frontend to make them work like one.
These changes include a fair amount of styles to
override those the govuk-button class brings in.
I've tried to mark those ones to at least make
that obvious.
The current link button for removing an area is
created using a psuedo element with an 'x' as
content.
The inline box for the 'x' overlapped its parent.
This is visible in high contrast mode, breaking the
parent's border. Despite existing in CSS, the 'x'
is also announced by screen readers, which is not
what we want.
This changes it to be an inline SVG with a role of
image. It doesn't require as large an inline box
so doesn't cause visual issues in high contrast
modes. It also means we can set it's label similar to
how you would an image's alt text, giving us
control over what is announced by screen readers.
This commit also includes some extra CSS,
targeting high contrast modes, giving the
link button the following when viewed in those
modes:
- a complete border so it is
distinguishable from the list item
- a focus style
I recently found that there is a problem with the
overuse of lists online for sequences of content
that don't need to be in a list. I think that's
what we're doing with our map key.
The problem is large enough that browsers include
heuristics to determine if lists should be
presented as such to the accessibility API (and so
to assistive tech' like screen readers). This
thread contains more details:
https://twitter.com/cookiecrook/status/1337226933822603270
Based on the metric described in the thread:
'If all of the styles that make it “list-like”
have been removed, it’s no longer relevant to
convey it as a list.'
...or
'if a sighted user doesn’t need to know it’s a
list, why would a screen reader user need to know
or want to know?'
Based on that, I think the items in our map key
should be paragraphs, not items in a list.
Also, they read really well as sentences when
announced by a screen reader, partly because of
the extra (hidden) info @quis added to them.
This also doesn't change their visual appearance.
They have the service navigation inside the <main>
block. This means you can't bypass it when you use
the skiplink.
This copies other layouts that inherit from
admin_template.html and sets the contents of the
'main' template block so the service navigation is
placed before the <main> tag.
Based on these comments on the associated pull
request:
- add area/areas condition to the array used to
build the label prefix
e2af2f63a4 (r55831534)
- use a for loop instead of while when looping
through nodes
e2af2f63a4 (r55831693)
The map is already in the tabbing order, so can be
moved to by tabbing and by programs like screen
readers or speech recognition, but it doesn't have
an accessible name so when assistive tech' that
requires this for identification gets the contents
read out instead, which is confusing.
This adds an accessible name, via aria-label, made
out of the areas the alert targets.
This also adds some help text, explaining how to
use the map via aria-describedby. This is a pretty
common pattern and is used in native UI like
selectboxes where a range of commands are
available to control the UI 'widget'. Using
aria-describedby means the help text is not used
every time the widget is focused but is available
if the user gets stuck. For example, Voiceover
announces it if the widget is focused but
not interacted with for a period of time, or when
a shortcut key is pressed.
Finally, I also added a role of 'region' because
when I tested with the NVDA screen reader, the
accessible name wasn't announced but this fixed
that. I think it's because the div isn't being
recognised as having a role without it being set
explicitly and is therefore ignored.
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.
The page_header macro includes an optional back link. Since the
page_header is always used inside `<main>`, where the back link should
not be, this stops setting the back link in the page header and instead
sets it in the new `backLink` block.
This moves the back link to be above the `<main>` tag by making use of
the new `backLink` block. This doesn't change the pages which are using
a back link as part of the `page_header` macro yet.
The `send_messages` permission has been deprecated for use with
broadcast services, so we can drop support for it in the code. We
were supporting both the old permissions and new permissions
(`create_broadcasts` and `approve_broadcasts`) while we switched people
over.
This removes `send_messages` from the `user_has_permissions` decorator
around the broadcast routes and from the page to view a broadcast and
broadcast dashboards. We can now git rid of a lot of the parameterization
that was temporarily added to the tests.
At the moment we say that you either ‘add’ an alert or ‘send’ it.
This is confusing because:
- an alert isn’t received on people’s phones until it’s approved, so
this is really when it is ‘sent’ conceptually
- an alert can be rejected before anyone receives it, so the UI can say
an alert that no-one ever received was sent
This commit re-labels things so that the the first part of the process
is ‘creating’ the alert.
This makes all the permissions nice and distinct from each other. Adding
templates and adding alerts feel conceptually quite different things
(what are you adding the alert to?).
The buttons and links on this page now work with the original
permissions and the two new broadcast permissions. Since the new
broadcast permissions have the effect of splitting the `send_messages`
permission this means that additional sections of if/else logic were
required.
The broadcast dashboards contain a button to create a new broadcast.
This adds the new `create_broadcasts` permission as one of the
permissions needed to see the button.
We prefer send now.
I think broadcast as a verb is still good in explaining how it coming
straight from the towers is different to a normal text message.
We give estimates of the area for those who can’t see the map. These
estimates were needlessly precise, gave a false sense of accuracy and
were causing intermittent test failures between different environments.
This commit rounds them in the same way that we round the count of
phones.
This makes the code shareable between:
- the broadcast tour pages
- the broadcast settings platform admin page
- the regular service navigation
On the training mode tour pages we don’t want to confuse people with the
organisation name or _Switch service_ links, so those are omitted and
the code is therefore slightly different.
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.
We want people to be really sure before sending a live broadcast, not
just clicking through the green buttons.
This commit adds a checkbox which explains exactly the consequences of
what they’re about to do, tailored to the channel they’re on, and the
area chosen by the person creating the alert.
Now we’ve split the old alerts onto two pages the verbs (‘Broadcast’ and
‘Rejected’) will always be the same for each alert – so they’re not
adding any differentiation.
The specifics of what the datetime means is available on the page for
each alert.
Removing the verbs makes the page a bit less cluttered and makes it
easier to scan down the right hand column.
The code for this page was making assumptions about properties which
aren’t present on rejected broadcasts.
This commit accounts for those properties and presents the relevant
elements on the page.
Two reasons to not hide rejected broadcasts:
- if a broadcast was rejected by mistake then it’s useful to have an
audit of who did that
- it means you can still see old broadcasts without having to leave
in pending-approval, which is dangerous because they might
accidentally be approved
There are basically two kinds of 4G masts:
Frequency | Range | Bandwidth
----------|-------------|----------------------------------
800MHz | Long (500m) | Low (can handle a bit of traffic)
1800Mhz | Short (5km) | High (can handle lots of traffic)
The 1800Mhz masts are better in terms of how much traffic they can
handle and how fast a connection they provide. But because they have
quite short range, it’s only economical to install them in very built up
areas†.
In more rural areas the 800MHz masts are better because they cover a
wider area, and have enough bandwidth for the lower population density.
The net effect of this is that cell broadcasts in rural areas are likely
to bleed further, because the masts they are being broadcast from are
less precise.
We can use population density as a proxy for how likely it is to be
covered by 1800Mhz masts, and therefore how much bleed we should expect.
So this commit varies the amount of bleed shown based on the population
density.
I came up with the formula based on 3 fixed points:
- The most remote areas (for example the Scottish Highlands) should have
the highest average bleed, estimated at 5km
- An town, like Crewe, should have about the same bleed as we were
estimating before (1.5km) – Pete D thinks this is about right based on
his knowledge of the area around his office in Crewe
- The most built up areas, like London boroughs, could have as little as
500m of bleed
Based on these three figures I came up with the following formula, which
roughly gives the right bleed distance (`b`) for each of their population
densities (`d`):
```
b = 5900 - (log10(d) × 1_250)
```
Plotted on a curve it looks like this:
This is based on averages – remember that the UI shows where is _likely_
to receive the alert, based on bleed, not where it’s _possible_ to
receive the alert.
Here’s what it looks like on the map:
---
†There are some additional subtleties which make this not strictly true:
- The 800Mhz masts are also used in built up areas to fill in the gaps
between the areas covered by the 1800Mhz masts
- Switching between masts is inefficient, so if you’re moving fast
through a built up area (for example on a train) your phone will only
use the 800MHz masts so that you have to handoff from one mast to
another less often
Broadcasts created by the API are different in that:
- they aren’t created by any user, so don’t have a `created_by_id`
- they are created instantly, not in steps, so don’t have an
`updated_at` time
This commit alters the views to account for when these pieces of
information aren’t present.
At the moment the admin app expects all broadcasts to have a template,
and expects the content of the alert to come from the template.
This commit makes it so those pages can still get a `Template` instance,
but populated with content straight from the `content` field in the
database.
