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.
Since moving textboxes to GOV.UK Frontend we’ve started putting the
data attribute on the `input` element itself, not a wrapper around it.
This commit updates the Javascript accordingly.
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.
Allows checkboxes to be collapsed so they take up
less space in the page. The collapsed state
includes a live summary tracking which of them are
selected.
Includes changes to the JS for collapsible
checkboxes to make it work with the GOVUK
Checkboxes component HTML.
When an element is obscured by the sticky nav,
this method allows you to scroll the page until it
is revealled.
The bulk of this code was added in: https://github.com/alphagov/notifications-admin/pull/2843
to ensure elements with focus were in view. This
moves that into a public method so, as well as
being called by the focus event handler, it can be
called directly by other code.
These changes include code that adds a
'sticky-scroll-area' class to scroll areas not
explicitly marked as such in the base HTML but
made to be a scroll area by the sticky JS.
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)
Allows checkboxes to be collapsed so they take up
less space in the page. The collapsed state
includes a live summary tracking which of them are
selected.
Includes changes to the JS for collapsible
checkboxes to make it work with the GOVUK
Checkboxes component HTML.
Allows checkboxes to be collapsed so they take up
less space in the page. The collapsed state
includes a live summary tracking which of them are
selected.
Includes changes to the JS for collapsible
checkboxes to make it work with the GOVUK
Checkboxes component HTML.
At the moment the first AJAX call is triggered as soon as the page
loads. We then look at its response time to work out how long to wait
until making the next call.
This isn’t great because:
- stuff is unlikely to have changed straight away, so it’s a waste of a
call
- while the DOM is being updated it seems to introduce a delay in
clicks on links, which is either more pronounced or more noticeable
when it’s happening straight away, making the UI feel less snappy
I chose a value of 2 seconds as a rough proxy for the minimum time we’d
expect to see a notification go from created to delivered. Median
time-to-delivered was 2.9 seconds when we analysed it for
https://github.com/alphagov/notifications-admin/pull/2974#discussion_r286101286
By default our AJAX calls were 2 seconds. Then they were 5 seconds
because someone reckoned 2 seconds was putting too much load on the
system. Then we made them 10 seconds while we were having an incident.
Then we made them 20 seconds for the heaviest pages, but back to 5
seconds or 2 seconds for the rest of the pages.
This is not a good situation because:
- it slows all services down equally, no matter how much traffic they
have, or which features they have switched on
- it slows everything down by the same amount, no matter how much load
the platform is under
- the values are set based on our worst performance, until we manually
remember to switch them back
- we spend time during incidents deploying changes to slow down the
dashboard refresh time because it’s a nothing-to-lose change that
might relieve some symptoms, when we could be spending time digging
into the underlying cause
This pull request makes the Javascript smarter about how long it waits
until it makes another AJAX call. It bases the delay on how long the
server takes to respond (as a proxy for how much load the server is
under).
It’s based on the square root of the response time, so is more sensitive
to slow downs early on, and less sensitive to slow downs later on. This
helps us give a more pronounced difference in delay between an AJAX call
that is fast (for example the page for a single notification) and one
that is slow (for example a dashboard for a service with lots of
traffic).
*Some examples of what this would mean for various pages*
Page | Response time | Wait until next AJAX call
---|---|---
Check a reply to address | 130ms | 1,850ms
Brand new service dashboard | 229ms | 2,783ms
HM Passport Office dashboard | 634ms | 5,294ms
NHS Coronavirus Service dashboard | 779ms | 5,977ms
_Example of the kind of slowness we’ve seen during an incident_ | 6,000ms | 18,364ms
GOV.UK email dashboard | `HTTP 504` | 😬
As part of updating the stylesheet, moved `.button-secondary` to the
global stylesheet, since this is not related to list entries but instead
affects all buttons with that class (this class wlil be removed once all
the buttons are using the new macro).
Cookies using the hostname as a domain will be set
with a prefix of `.` by browsers, it seems to
ensure all subdomains are included in the scope.
When deleting the `seen_cookie_message` cookie we
want to set its domain without a `.` prefix, to
match the domain set by the original code.
Leaving the `domain` attribute out from the cookie
string will ensure the `.` prefix is not set.
We have been clearing all the Google Analytics
cookies on each page request.
It is now possible for a user to consent to having
Google Analytics cookies so this should have been
checking for that before deleting them.
This makes that change, with tests for those
scenarios.
Removes the following fields from the tracker
config:
- `name`, which was erroring due to it
including a `.`
- `displayFeaturesTask` which seems to be
deprecated
Also refactors the `create` command to put all
fields into the options parameter, as shown in the
developer docs:
https://developers.google.com/analytics/devguides/collection/analyticsjs/creating-trackers
