Suggested by the Digital Accessibility Centre in
their report. Giving these buttons
aria-expanded=false indicates:
- they control a section on the page
- that section is collapsed (and so clicking the
button will open it)
Screenreaders announce the title of the page when
it loads and their users are used to it signifying
a new page.
By focusing a form control when the page loads,
this announcement is replaced with that of the
control label.
This commit prefixes the label with the page title so it
gets announced when the page loads, notifying
screenreader users that they are on a new page.
The page title prefix is removed once focus shifts
from the form control as its presence in any
further announcements could be confusing.
During the move to GOV.UK Frontend checkboxes our template list has
started to be wrapped in a `<div>` with the `govuk-form-group` class.
This adds extra spacing, like you’d want in a regular transaction
service which might have multiple sets of form controls on a single
page.
It isn’t appropriate on our templates page, because there should be a
consistent rhythm where the space between each checkboxes is the same as
the space between the search box and the first checkbox, to the last
checkbox and the buttons. Not having this space is also consistent with
other pages with sticky grey buttons, eg the team members page.
This commit also fixes a typo in the name of one of the classes used to
control spacing between the checkboxes and search bar.
I emailed the Geography team at the ONS:
> Hi geography team,
>
> I work on GOV.UK Notify, which is a service run by Government Digital Service (part of the Cabinet Office). I was given your email address by [redacted] who’s been helping answer some of my questions on the cross-government Slack.
>
> We’re using some of the boundary datasets from the Open Geography Portal, and mostly they’ve been excellent.
>
> In the abstract, the problem we’re trying to solve is, given a point outside an area, what is the minimum distance to a point within that area. So, for example, if a crow was somewhere in Cardiff, what’s the shortest distance it would have to fly to reach somewhere in the Bristol local authority district?
>
> We’ve noticed some problems with the data that means our calculations would be wrong. We’ve noticed this around Torquay, Norwich and Bristol. Here are some screenshots of Bristol, from the generalised and full resolution boundaries:
>
> The artefacts I’ve highlighted are closer to Cardiff than any actual part of the land area of Bristol. They are either:
> - in the sea
> - land that’s part of North Somerset
>
> I suspect that this is being caused by the process of clipping the actual region of Bristol (which, unusually, extends into the water) to the mean high water line.
>
> I’ve worked around this by filtering out any polygons that are smaller than ~7,500m². It’s a bit hacky because parts of the Scilly Isles start disappearing. That’s not a problem for what I’m working on, but it would be nice to not need the hack.
>
> So my questions would be:
>
> - Is there a better way to remove these artefacts than filtering by area?
> - Is there a plan to remove these artefacts from the data in future releases?
>
> Thanks in advance,
> Chris
They emailed back to say:
> Hi Chris
>
> Thank you for your enquiry.
>
> We have completed the amendments to the LAD MAY 2020 BFC and BGC boundaries as mentioned so you should be able to download them from the portal now.
>
> Hope this helps.
>
> Kind regards
> [redacted]
This commit brings in the files they’ve updated. We still have to do
some filtering (but now at a higher resolution) because they haven’t
fixed Norwich yet. I’ll email them separately about that.
We’ve had some feedback that the map key icons look a bit like
checkboxes, and that this might have confused a user during the
research.
So we need a way of making them look different to checkboxes. We don’t
want to change the border thickness because it matches what’s on the
map. A different approach is changing the shape.
Shapes that might still be confusing:
- circles (look like radio buttons)
- triangles (look like a warning)
So this commit changes the shape to a diamond, which is easy to acheive
by rotating the square 45 degrees.
We’ve had some feedback that relying only on luminosity and position to
differentiate between the ‘will get alert’ and ‘likely to get alert’
areas on the map might not be enough.
We don’t want to introduce another colour because:
- it will make the map look very busy
- not many other colours contrast with the map tiles as well as blue
- relying on colour only to communicate information is also bad for
accessibility
Instead we can make one of the lines a different style. I’ve gone for
dashed on the ‘likely’ line because it looks nice, and gives some
suggestion of a porous boundary.
Implementing this means using CSS border image, because a `dashed`
border (which we still have as a fallback) doesn’t render with
consistent dash sizes from browser to browser. We need consistency to
match the dashes that the map will be drawing (which use SVG not CSS
so don’t have the same problem).
We’ve had some feedback from user research that difference between
‘will get alert’ and ‘likely to get alert’ is not clear, and it’s hard
to tell if the latter is inclusive of the former. This leads people to
question the validity of these numbers, which is important, because an
the estimate should give you some idea of the impact of what you’re
about to do.
This commit reformats the number as a range, for example 1,000 to 2,000
phones.
If the range is small, eg 40,000,000 to 40,800,000 then this suggests
a false level of accuracy. So instead we just give one number and say
it’s an estimate, eg ‘40,000,000 phones estimated’
Accessibility audit uncovered issues screen-reader users would
have with autofocus on Notify pages. Autofocus can lead to
confusion for those types of users and make them miss parts
of the page.
Hence, we decided that autofocus will be turned off by default
for live-search component.
We decided to keep the autofocus on for live-search text box when:
1. the page is a task page - as opposed to browsing pages, where
user wonders freely, task pages have more established flow, so
page focusing on textbox can actually be helpful.
2. page does not have actionable elements above the autofocus.
Accessibility audit uncovered issues screen-reader users would
have with autofocus on Notify pages. Autofocus can lead to
confusion for those types of users and make them miss parts
of the page.
Hence, we decided that autofocus will be turned off by default
for live-search component.
We decided to keep the autofocus on for live-search text box when:
1. the page is a task page - as opposed to browsing pages, where
user wonders freely, task pages have more established flow, so
page focusing on textbox can actually be helpful.
2. page does not have actionable elements above the autofocus.
Accessibility audit uncovered issues screen-reader users would
have with autofocus on Notify pages. Autofocus can lead to
confusion for those types of users and make them miss parts
of the page.
Hence, we decided that autofocus will be turned off by default
for live-search component.
We decided to keep the autofocus on for live-search text box when:
1. the page is a task page - as opposed to browsing pages, where
user wonders freely, task pages have more established flow, so
page focusing on textbox can actually be helpful.
2. page does not have actionable elements above the autofocus.
Accessibility audit uncovered issues screen-reader users would
have with autofocus on Notify pages. Autofocus can lead to
confusion for those types of users and make them miss parts
of the page.
Hence, we decided that autofocus will be turned off by default
for live-search component.
We decided to keep the autofocus on for live-search text box when:
1. the page is a task page - as opposed to browsing pages, where
user wonders freely, task pages have more established flow, so
page focusing on textbox can actually be helpful.
2. page does not have actionable elements above the autofocus.
Accessibility audit uncovered issues screen-reader users would
have with autofocus on Notify pages. Autofocus can lead to
confusion for those types of users and make them miss parts
of the page.
Hence, we decided that autofocus will be turned off by default
for live-search component.
We decided to keep the autofocus on for live-search text box when:
1. the page is a task page - as opposed to browsing pages, where
user wonders freely, task pages have more established flow, so
page focusing on textbox can actually be helpful.
2. page does not have actionable elements above the autofocus.
Accessibility audit uncovered issues screen-reader users would
have with autofocus on Notify pages. Autofocus can lead to
confusion for those types of users and make them miss parts
of the page.
Hence, we decided that autofocus will be turned off by default
for live-search component.
We decided to keep the autofocus on for live-search text box when:
1. the page is a task page - as opposed to browsing pages, where
user wonders freely, task pages have more established flow, so
page focusing on textbox can actually be helpful.
2. page does not have actionable elements above the autofocus.
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.
It was missing the base class so didn’t get all the styling (like the
spacing and uppercase text).
Already fixed this for step 6, but less haste, more speed.
We want it to be very clear whether you’re in live or training mode
because:
- you may be switching back and forth between them
- doing something in live mode when you think you’re in training mode
would have… consequences
By adding a label next to the service name you’ll will have some
indication, on every page, which mode you are in.
Style of the label is based on the ‘Tag’ component from the Design
System:
https://design-system.service.gov.uk/components/tag/#showing-multiple-statuses
