We added an extra, hidden, <input> to our /sign-in
and /register forms to stop Chrome's form
heuristics filling the fields in wrong.
See the commit that added it:
33b15cdec6
This removes it after testing with the following
Chrome/OS combinations and all working without the
hack:
- Chrome 87, Windows 7
- Chrome 86, Windows 7
- Chrome 86, Windows 10
- Chrome 85, Windows 7
- Chrome 80, Windows 10
- Chrome 81, Windows 7
- Chrome 52, Windows 7
- Chrome 68, Windows 7
- Chrome 78, Windows 8.1
- Chrome 86, Windows 8.1
These combinations were based on the most-used
versions recorded in our analytics for the last 3
months.
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
When looking at Google’s PageSpeed Insights tool as part of the
compression work I noticed a suggestion that we preload our font files.
The tool suggests this should save about 300ms on first page load time.
***
Our font files are referenced from our CSS. This means that the browser
has to download and parse the CSS before it knows where to find the font
files. This means the requests happen in sequence.
We can make the requests happen in parallel by using a `<link>` tag with
`rel=preload`. This tells the browser to start downloading the fonts
before it’s even started downloading the CSS (the CSS will be the next
thing to start downloading, since it’s the next `<link>` element in the
head of the HTML).
Downloading fonts before things like images is important because once
the font is downloaded it causes the layout to repaint, and shift
everything around. So the page doesn’t feel stable until after the fonts
have loaded.
Google call this [cumulative layout shift](https://web.dev/cls/) which
is a score for how much the page moves around. A lower score means a
better experience (and, less importantly for us, means the page might
rank higher in search results)
We’re only preloading the WOFF2 fonts because only modern browsers
support preload, and these browsers also all support WOFF2.
We set an empty `crossorigin` attribute (which means anonymous-mode)
because the preload request needs to match the origin’s CORS mode. See
https://developer.mozilla.org/en-US/docs/Web/HTML/Preloading_content#CORS-enabled_fetches
for more details.
We set `as=font` because this helps the browser use the correct content
security policy, and prioritise which requests to make first.
It’s fiddly having to scroll within a small textbox to see all the
content. Let’s make the box expand to fit the contents like we do
elsewhere. This was removed by accident when we stopped highlighting
placeholders in broadcast templates in
https://github.com/alphagov/notifications-admin/pull/3672/files
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
Changes the selector the live search in the set
email and letter branding pages in service
settings and organisation settings. The current
one targeted the old radios HTML whereas this
version targets the same for the GOVUK Frontend
radios.
Changes OrganisationCrownStatusForm.crown_status.
This also effects NewOrganisationForm, which
inherits from OrganisationCrownStatusForm.
Because of that this commit also updates the
template used for the edit org crown status page,
which uses NewOrganisationForm for its form.
Changes the OrganisationTypeField class used by
OrganisationOrganisationTypeForm.organisation_type
OrganisationTypeField is also used by the forms in
/add-service:
- CreateServiceForm
- CreateNhsServiceForm
Because of that, this commit also includes changes
to the template for that route.
Note: this also moves where OrganisationTypeField
appears in app/main/forms.py so it can use
GovukRadiosField.
Includes changing form.enabled to use
OnOffField, for consistency with other on/off
fields.
OnOffField's data is a boolean, not a string, so
some of the logic using it needed to be changed.
Uses the ServiceOnOffSettingForm.enabled.
Effects the following routes:
- /services/<service_id>/service-settings/switch-live
- /services/<service_id>/service-settings/switch-count-as-live
- /services/<service_id>/service-settings/permissions/<permission>
- /services/<service_id>/service-settings/permissions/broadcast
Includes changes to make the GOVUK radios
component render the h1 in the page. This is done
so the legend doesn't just duplicate the h1 and
is recommended in the design system guidance for
the radios component for pages that just ask you
for one piece of information.
https://design-system.service.gov.uk/components/radios/#how-it-works
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.
