All paragraphs should have class="govuk-body", or be otherwise
custom-styled. This commit adds some extra checks to our test fixture
that looks for paragraphs that don’t have any styling. Our test coverage
is pretty good, so this should check almost all pages, and prevent
regressions.
I’ve done this in such a way that it can be extended for other elements
(e.g. links) in the future.
Errors with messages being too long or empty aren’t specific to a single
cell of the uploaded spreadsheet, they’re the results of combining all
the cells with the template.
Previously we could only show errors against a specific cell. This
commit makes it possible to add a super-row which spans all the cells,
into which we can put errors.
The index (header) column then spans both these rows, to show that they
are both associated with the same row of input.
Depends on:
- [x] https://github.com/alphagov/notifications-utils/pull/719
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` | 😬
The default is 2 seconds and this will mean that we are halving traffic
for these ajax calls which can only be good for trying to limit queries
on the database.
I think the user impact on this will likely not be noticable.
Debatable whether we should up them all even further to 10 seconds but
this is definitely a quick although maybe small win.
Includes:
- make 'remove team member' link, on edit member
permissions page, destructive
- convert missed links on /features pages
- convert missed links on /using-notify/guidance and sub pages
- give links in browse-lists back their size and
weight (needed for lists of live and trial
services on Platform Admin)
- give links on Platform Admin inbound numbers
page back their size and weight
- update links in JS tests
Converts links in the following:
- the page-footer component
- the table component
- the browse-list component
- the notification status, when reporting failures
- validation messaging in the whitelist page
Includes:
- turning off :visited styles to match existing
design
- swapping heading classes used to make links bold
for the GOVUK Frontend bold override class
- adding visually hidden text to some links to
make them work when isolated from their context
We may need to revisit whether some links, such as
those for documentation and features, may benefit
from having some indication that their target has
been visited.
Includes:
- make 'remove team member' link, on edit member
permissions page, destructive
- convert missed links on /features pages
- convert missed links on /using-notify/guidance and sub pages
- give links in browse-lists back their size and
weight (needed for lists of live and trial
services on Platform Admin)
- give links on Platform Admin inbound numbers
page back their size and weight
- update links in JS tests
Converts links in the following:
- the page-footer component
- the table component
- the browse-list component
- the notification status, when reporting failures
- validation messaging in the whitelist page
Includes:
- turning off :visited styles to match existing
design
- swapping heading classes used to make links bold
for the GOVUK Frontend bold override class
- adding visually hidden text to some links to
make them work when isolated from their context
We may need to revisit whether some links, such as
those for documentation and features, may benefit
from having some indication that their target has
been visited.
This is a convenient way of being able to link into pages of the the app
from guidance. It handles the case where the current service is not
known, either because the user hasn’t chosen one, or because they’re not
signed in.
This commit also cleans up some unused Jinja imports.
This makes the template statistics section of the dashboard look less
like its own weird thing and more like:
- the templates page
- the upcoming changes to the styling of the received text messages
banner on the dashboard
It looks like a link so its semantics should
identify it as one.
This can effect users of speech recognition
software, in scenarios where they instruct it to
click an element which looks like one thing but
the software can only identify as something else.
Visual users get the context from the proximity to
the h2 but we need to provide this for others.
I've tried using `aria-describedby` to link them
to the h2 but this ends up making the h2 text the
button's description in the accessibility tree. In
Voiceover this means you only get that information
as extra context, announced a while after the
label if the VO cursor stays on the button.
We want all the information in the accessible
label so chose this approach instead.
Paired with @aliuk2012 on the implementation and
with a view to making the component generic enough
to be used on digital marketplace apps as well.
These changes came from that session.
They include:
- removal of an unused `data-accept-cookies`
attribute
- removal of `govuk-!-padding-top-4` class and
moving of associated styles into component CSS
- swapping out the `aria-label` on the parent
element for an `aria-describedby` linked to the
h2 to have one thing labelling the banner region
- removal of unused CSS and any already provided
by the govuk-button class
- inclusion of @import's for styles attached to
govuk-body and govuk-button classes
Copies HTML and Sass from GOV.UK Pubishing
components cookie-banner with changes to content
and functionality to better suit Notify.
Changes are:
- adds a 'reject' button which the GOV.UK
code doesn't have
- adds Sass from the GOV.UK Frontend button
component which the GOV.UK version used so
is included here
- removed click tracking from cookie banner
It looks like a link so its semantics should
identify it as one.
This can effect users of speech recognition
software, in scenarios where they instruct it to
click an element which looks like one thing but
the software can only identify as something else.
Visual users get the context from the proximity to
the h2 but we need to provide this for others.
I've tried using `aria-describedby` to link them
to the h2 but this ends up making the h2 text the
button's description in the accessibility tree. In
Voiceover this means you only get that information
as extra context, announced a while after the
label if the VO cursor stays on the button.
We want all the information in the accessible
label so chose this approach instead.
