Work prepping the interface that will be used for
emergency alerts for its accessibility audit has
taken priority so the issues in this statement
will need to be worked on later than we expected
when we originally set the dates for them to be
fixed.
This moves the work forward to be started after
the emergency alerts work is complete.
I recently found that there is a problem with the
overuse of lists online for sequences of content
that don't need to be in a list. I think that's
what we're doing with our map key.
The problem is large enough that browsers include
heuristics to determine if lists should be
presented as such to the accessibility API (and so
to assistive tech' like screen readers). This
thread contains more details:
https://twitter.com/cookiecrook/status/1337226933822603270
Based on the metric described in the thread:
'If all of the styles that make it “list-like”
have been removed, it’s no longer relevant to
convey it as a list.'
...or
'if a sighted user doesn’t need to know it’s a
list, why would a screen reader user need to know
or want to know?'
Based on that, I think the items in our map key
should be paragraphs, not items in a list.
Also, they read really well as sentences when
announced by a screen reader, partly because of
the extra (hidden) info @quis added to them.
This also doesn't change their visual appearance.
They have the service navigation inside the <main>
block. This means you can't bypass it when you use
the skiplink.
This copies other layouts that inherit from
admin_template.html and sets the contents of the
'main' template block so the service navigation is
placed before the <main> tag.
The browser uses the `width` and `height` attributes of the image tag to
allocate space on the page for the image.
If these aren’t provided then the browser will assume the image takes up
no space, until it’s downloaded it and had a look at what the file’s
dimensions are. This causes the layout of the page to jump once the
image downloads.
`149 × 150px` is the native size of the image. But we don’t want it to
display at that size, so this commit also adds some extra CSS which
keeps it looking the same, namely:
- the full width of the 1/4 page column on desktop
- the full width of the column minus a `40px` gutter either side on
mobile (by using `box-sizing: border-box` the `40px` of padding is
subtracted from the 100% width, rather than added to it)
turns out that we're only using errorBanner with a static message, and
it's also full of rich html content. This means that it's probably
better to put it in the html templates with other content, rather than
hidden away in js files if we can help it.
Since there are two places, had to dupe the error message but i think
that's fine as i don't anticipate this error message being used in
significantly more places.
making it a string is a bit gross and means we don't get nice syntax
highlighting on it, but as it needs to be passed in to a jinja macro
that's the way it has to go unfortunately.
the banner is a nicer user experience, and consistent with how we
display errors elsewhere in notify. For now pass through the error
message from JS, but we'll probably want to change that since the erorr
messages themselves are often a bit cryptic and unhelpful
Add additional instructions for the service name - this is more consistent with the local government version of this page
Also update tests to use the new content.
name is designed for a human readable description of what the thing
you're copying belongs to. (while thing is supposed to describe what the
value represents.
For example on the reply-to email address page, thing="ID" because
you're copying a uuid, and name is the actual name of the email address.
So the talkback speech will read out "copy ID to clipboard for
my@email.com, button".
However, in our case, there's no need to add what the context is for
since each copyable item on the page is something different (a sort
code, a VAT number, etc).
Removing the name makes the talkback just read "Copy sort code to
clipboard", which is what we want. However the macro also only shows a
header if the name is present, so we have to add the header manually.
lets us keep cabinet office financials safe in the credentials repo
the dict in the creds repo will either be an empty dict or a full dict,
so the env var on paas will always contain some parseable json. But
locally it might not, so if it's not set at all then default to the
string `null` so the json parsing doesn't throw a wobbly.
Based on these comments on the associated pull
request:
- add area/areas condition to the array used to
build the label prefix
e2af2f63a4 (r55831534)
- use a for loop instead of while when looping
through nodes
e2af2f63a4 (r55831693)
The map is already in the tabbing order, so can be
moved to by tabbing and by programs like screen
readers or speech recognition, but it doesn't have
an accessible name so when assistive tech' that
requires this for identification gets the contents
read out instead, which is confusing.
This adds an accessible name, via aria-label, made
out of the areas the alert targets.
This also adds some help text, explaining how to
use the map via aria-describedby. This is a pretty
common pattern and is used in native UI like
selectboxes where a range of commands are
available to control the UI 'widget'. Using
aria-describedby means the help text is not used
every time the widget is focused but is available
if the user gets stuck. For example, Voiceover
announces it if the widget is focused but
not interacted with for a period of time, or when
a shortcut key is pressed.
Finally, I also added a role of 'region' because
when I tested with the NVDA screen reader, the
accessible name wasn't announced but this fixed
that. I think it's because the div isn't being
recognised as having a role without it being set
explicitly and is therefore ignored.
Makes the controls and links inside it match GOVUK
Frontend styles and:
- gives the map container a focus style matching
that for GOVUK Frontend text inputs
- makes it all work in high contrast modes (on
Windows and Firefox)
Note: the focus style for the container is applied
with :focus-visible so only appears when it gets
focus directly, not when it does due to child
elements (like the controls or links) getting
focused. Browsers without support for
:focus-visible get the same styling for all forms
of focus.
We had an audit in February of this year but did
not update the accessibility statement to reflect
the issues identified as fixed or to include new
issues it produced.
Some of the dates for fixed have also not been
updated for a long time.
This adds those changes, with placeholders for
dates assigned to each issue.
This content is now ready for review. The dates
will be assigned when that is complete.
