This hides the "Register" button and shows an error that's specific
to one of two ways a browser may not support WebAuthn:
- JavaScript is disabled (there's no possible fallback for this).
- WebAuthn API is not supported (e.g. on Internet Explorer).
We could add a similar check for the API in the JS code to handle
the button click, but hiding it seems like enough protection.
In order to avoid elements flashing when the page loads, this uses
a view macro to embed a script at the start of the body element,
which is the same approach used for the "js-enabled" class flag [1].
Tested with Chrome and IE 11.
[1]: https://github.com/alphagov/govuk-frontend/blob/main/src/govuk/template.njk#L31
The links in the blue boxes on the job page needed hidden text so that
they work out of context. This changes the text from "10 sending" to "10
sending text messages" (with the message type hidden text).
We feel that this is more appropriate because it’s part of the
information you’re agreeing to before you hit submit.
Sometimes users can missing information that doesn’t start left-aligned
to the column they’re interacting with.
It also makes it closer to the Design System component.
We’re keeping it in the sticky footer, so that it’s always visible no
matter where in the message you’re scrolled to (this means you won’t
have to edited to content then scroll down to check whether you’ve
made it fit).
This looks tidy, and because of the sticky footer it means the message
is always visible, even if your template is quite long. So no matter
where you’re scrolled to in the template you don’t have to scroll to the
bottom to see the count update.
As formatters we can use them in Jinja or Python code.
It also means we don’t need to import them every time we want to use
them – they’re always available in the template context.
For now this doesn’t remove the macros, it just aliases them to the
formatters. This gives us confidence that the formatters are working the
same way the old macros did, and reduces the diff size of each commit.
Looks like this was added in:
4a226a7a29
...and used in the spark_bar_field macro. That
macro was removed in:
89b88ee4cb
..but the import was missed out.
An accessiblity audit done as part of Notify's
service assessment raised the following problem
with our big_number component.
When you turn CSS off, the sentence in the
component is split onto separate lines.
This was because the number part is wrapped in a
<div> which browsers were interpreting as being a
separate sentence to the label.
So "1 letter", where "letter" is the label, was
seen as:
"1"
"letter"
The accessibility expert consulted on this pointed
out that this would sound confusing for users of
screen readers when moving through the document
sentence by sentence.
These changes:
- make the <div>s into <span>s which are 'phrasing
content' and so are interpreted as part of the
same sentence
- change the CSS so the number will still sit
on top of its label text
The HTML5 spec has a section on how browsers
should arrange text into paragraphs that explains
what was happening in more detail:
https://www.w3.org/TR/html52/dom.html#paragraphs
Safari has a bug where it stops input[type=file]
elements working if they don't specify the types
of file to accept (via the `accept` attribute).
It seems to just effect certain versions of Mojave
but completely blocks this action so worth fixing.
This adds a 'allowed_file_extensions' keyword
argument to the file_upload component to let you
specify a value to be passed to `accept`.
This was spotted on x-gov Slack:
https://ukgovernmentdigital.slack.com/archives/C06GCJW7R/p1607952390112800
...and StackOverflow:
https://stackoverflow.com/q/64843459/679924
Our cookie banner has an accessible description
but no accessible name. It needs to have an
accessible name to distinguish it from other
elements on the page with role=region.
There's some advice in the WCAG guidance that
explains this more:
https://www.w3.org/TR/WCAG20-TECHS/ARIA11.html
This issue was raised in the accessibility review
done as part of our service assessment.
These changes borrow the approach from www.gov.uk of
moving to a label and losing the accessible
description. It also uses the 'cookie banner'
label for consistency with www.gov.uk.
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.
If there is a search term when the page loads, a
statement about the results is added to the
searchbox label.
All subsequent searches are announced via an aria
live-region.
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.
Pill pages are:
- /notifications
- /template-usage
- /monthly
- /organisations/<organisation_id>
- /templates
Includes changes to:
- the folder-path component
- the page-header component
...all their h1s have the same id.
Changes the HTML to do the following:
- remove all tabs semantics
- give the list a role of navigation
- label the navigation with the h1
- mark the selected item with aria-current
Changes the interface so:
- `name` is a required argument
- the heading is only shown if `name` and `thing`
match
These changes reflect a pattern observed in how
the component is used in pages.
It's first worth stating what the `thing` and
`name` arguments are.
`thing` is the type of thing the id is, for
example an reply-to email address.
`name` is which one of that type in the page, for
example the reply-to email address for user 1.
In pages where the id is the only one of its type,
these will have the same value.
When it is the only one of its type in a page, it
always has a heading so this makes the heading
appear based on `name` matching `thing`.
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.
ListEntry component uses FieldList field to group
textboxes. Textboxes can be text inputs, email fields
or international phone number fields. This converts
all field-lists to use:
- GovukTextInputField
- GovukEmailField
- InternationalPhoneNumber
Affects these forms:
- OrganisationDomainsForm
- GuestList
Also changes to related Javascript:
Update list-entry JS tests to match new HTML
Updates the HTML the JS operates on in the test
(a fixture representing the HTML in the page on
load) to match the new GOVUK Frontend we are
generating.
Make list-entry JS work with GOVUK Frontend HTML
The existing list-entry JS did a few things that
clashed with how the new HTML works:
- added a 'input-' prefix to the id attributes
of all text-inputs
- did not make its name and id attributes values
match
The new HTML has id and name attributes that
match so these changes remove the prefix for id
attributes and makes them match the name
attribute.
To understand these changes, it is useful to
know how the values for id and name attributes are
generated:
1. the id attribute for the component element is
stored
2. the 'list-entry-' prefix is removed and the
remainder is used to generate ids
For example, if the component's id is
'list-entry-domains', the id will be 'domains-1',
where the text-input is the first one.
This also adds some logic to the HoganJS template
to make the value attribute optional, so it is
only added if it has a non-null value. This
matches the behaviour of the text-input component
used in the new list-entry component.
Also change whitelist references to guestlist in tests
- we forgot to do it earlier, when we moved from calling this
feature whitelist to calling it guestlist.
Changes those fields in the following forms:
- SearchByNameForm
- SearchUsersByEmailForm
- SearchUsersForm
- SearchNotificationsForm
Includes changes to templates that use this form
and associated tests.
We recently introduced a form control that lets user choose when a
broadcast ends.
Based on the most recent research participant, we think:
- there is a specific misunderstanding of what this control does
- there is a general low level of understanding of what a ‘broadcast’
means
People will try to understand what a ‘broadcast’ is by using mental
models they have for other kinds of messaging, for example text
messages.
Other kinds of messaging are one-to-one, i.e. they go from a sender to a
recipient. They are not ongoing in any way.
Emails and texts are sent at a time (and for all practicable purposes
are received at that same time). So, when we present the user with
a form that controls time, they might well assume it controls the time
when the message will be sent.
This is a feature we offer for sending messages using a spreadsheet, and
that’s where we’ve borrowed this pattern from.
We reinforce this assumption with the labelling of the form control. By
front-loading it with the word ‘When’ we are playing to the users
confirmation bias, i.e. they are interpreting the meaning of the control
in a way that confirms their prior beliefs about how messaging works.
So this commit does two things:
- re-labels the form to front-load the word ‘End’ not ‘When’
- adds text to the page explaining when the broadcast will start, so
there’s a chance of overriding that confirmation bias
If we can get users to go through this before sending a broadcast for
real, it could help them learn what a broadcast is, and how it differs
from sending text messages.
Different emergencies will need broadcasts to last for a variable amount
of time. We give users some control over this by letting them stop a
broadcast early. But we should also let them set a maximum broadcast
time, for:
- when the duration of the danger is known
- when the broadcast has been live long enough to alert everyone who
needs to know about it
This code re-uses the pattern for scheduling jobs, which has some
constraints that are probably OK for now:
- end time is limited to an hour
- longest duration is 3 whole days (eg if you start broadcasting Friday
you have the choice of Saturday, Sunday and all of Monday, up to
midnight)
At the moment the page is the same as for text message templates,
except:
- different H1
- no guidance about personalisation, links, etc (until we decide how
these should work)
For now you won’t be able to really create a broadcast template, because
the API doesn’t support it (the API will respond with a 400). But that’s
OK because no real services have the broadcast permission yet.
This required a bit of refactoring of how we check which template types
a service can use, because there were some hard-coded assumptions about
emails and text messages.
