When we changed the layout for each alert on the
current/past/rejected alerts pages to use flexbox,
we added a fallback for older browsers that set
text-align: justify on the container:
https://github.com/alphagov/notifications-admin/pull/4171
This has led to items in the list of areas an
alert will be sent to being laid out as justified
content when they were left-aligned.
These changes set the correct alignment.
We fixed a problem with the focus styles of list
items in this pull request:
https://github.com/alphagov/notifications-admin/pull/4141
This missed out pages for areas with counties in
them. This adds the fix to those pages.
These changes also include some extra spacing
between the end of the list and the button which
is lost by the new styles we're giving the list
items.
Our CSS for links in the navigation, which makes
the underline appear on hover is overriding the
GOVUK focus styles, making it look like there are
2 underlines. This adds some extra CSS to reset
it.
The new CSS is further down the stylesheet to the
hover styles. This gives them a higher specificity
meaning they override them when these links are
hovered over while in focus.
Based on comments on the associated pull request,
(and my realisation that I was using flexbox
wrong):
https://github.com/alphagov/notifications-admin/pull/4171
Removal of flex-grow
I added `flex-grow: 1` to make the description and
status flex items grow to fill the container, at
least until they hit their `max-width`. They
already have `width: 100%` which achieves the same
thing so this removes it.
Using `width` doesn't work for flex-items with
flex-grow set above 0 because they will expand to
fill the space, whatever its value.
The intention for this line was always to
constrain how much these ones can grow to half the
space minus the gap between. `max-width`, which is
still honored by flex-items with `flex-grow` above
0, meaning they will expand up to that size.
Having a grid in the click target stops the hint
and status text being clickable. This removes it
in favour using flexbox to position the elements
in a similar way.
Includes fallback styles for browsers that don't
support flexbox that positions the child elements
inline, laid out justified, to mimic the flexbox
positioning of justify-content: space-between.
Note: display is overriden on child items under
flexbox so setting display: inline-block is
ignored.
In previous iterations of the classPersister, we
found issues with the implementation meant classes
it should have added back to elements were also
added to other elements. This adds tests for this
scenario to ensure it doesn't happen again.
Also includes changes to fix a linting error with
the JS which complained about a function being
defined in a loop while referencing variables in
the outer scope.
The assumption that the classes you want to
persist will always have parity with the elements
that have those classes, at that point, won't
always be true.
Because of that, this changes the way elements
with those classes are stored, to be in a map
between classes and the elements with them (at
that point).
Also includes an extra test for a scenario where
more than one updating component is in the page
with classes that need to persist through updates.
File-list items contained by div.keyline-block's
are pushed down 3px more than elsewhere which
creates a gap between the top of the focus style
and the keyline above. This extends the part of
the focus style made up by a box-shadow by 3px so
it covers the gap.
If the :has pseudo-class becomes available in the
browsers we support in future, the code this
branch/pull request adds will be redundant as its
behaviour will be possible only using CSS.
This adds comments to note this to the parts of
the code you'd need to remove.
Includes the following:
Guard for adding duplicate classNames
Stops the code that allows classNames to persist
across updates to the component HTML from adding a
className multiple times to the list of those to
persist. From this comment on the associated pull
request:
https://github.com/alphagov/notifications-admin/pull/4155#discussion_r804639058
Add comment explaining guard for operations on
elements no longer in the DOM
The value of this guard can be unclear and why it
is needed so we add a comment to explain this.
From this comment on the associated pull request:
https://github.com/alphagov/notifications-admin/pull/4155#discussion_r804697189
We can't guarantee that elements we stored a
reference to with `classesToPersist.remove` will
still exist so we need to guard against this.
Note: it checks for whether the node is still
attached to the DOM rather than whether it exists
because the standard way to delete a node just
detaches it from the DOM and relies on garbage
collection to delete it from memory.
The current updateContent JS replaces the in-page
HTML with the HTML from the server the first time
an AJAX request is fired, even if the HTML from
the server has no changes. This is because the
code that compares the two operates on two
different things:
The HTML in the page is the component HTML, with
all the data attributes and the partial HTML
(marked with the 'ajax-block-container' class) as
its first child:
```
<div data-module="update-content" data-url="...">
<div class="ajax-block-container">
...
</div>
</div>
```
The HTML from the server only contains the
partial:
```
<div class="ajax-block-container">
...
</div>
```
The diffing code just sees them as different at
the top level so replaces the page HTML with the
partial from the server. This means all subsequent
diffs are between partial HTML and partial HTML so
only update on actual changes.
These replace the component with the partial, as
part of the component initialising. This means all
code that runs on an AJAX response will only
compare like-for-like so will result in actual
changes (or none at all), not just swapping one
element out for another.
Note: this commit also removes the
aria-live="polite" from the ajax_block component.
It has always been overwritten by the first
response so never announces anything to assistive
technologies. Removing it makes this more clear.
Includes:
- JS to add a class to the heading when the link
is focused
- CSS to apply the enlarged focus style via a
selector which uses that class
- changes to the partial to hook in the JS to
track focus on links and to tell the
updateContent JS to persist the classes added
between updates to the HTML
Wrap the code that updates the HTML with changes
from the server with code that stores and
re-applies specified classes.
This is to allow other JS to add classes which
change the visual state of the HTML without them
being considered by the code that diffs our
in-page HTML against that from the server.
They are called classesToPersist because this
should make the visual state they create persist
between updates.
Includes the addition of tests for updateContent
that cover the addition/deletion of elements so we
can write a test for classNames persisting through
updates. The existing tests only cover updates
that change the content of elements. Just adding
the test for these changes to those would simulate
a scenario that doesn't exist in the app. Writing
extra tests for the kind of updates these changes
act on keeps them in line with the app code.
Most browsers apply the focus style when a link is
clicked but Safari just applies the active style.
This meant our large links, with expanded click
areas, didn't get the focus style themselves but
their psuedo-elements (which create the expanded
click area) did.
This adds the focus styles to the active state of
links with the expanded click area, to ensure all
of their click area gets the focus style.
At present the file-list pattern assumes each
item has hint text below the link and so increases
the hit area to overlap the hint. This adds a
variant for items without one and uses it on the
page for choosing an alert sub-area.
We added domdiff to replace the DiffDOM library
here:
https://github.com/alphagov/notifications-admin/commit/87f54d1e886f5c45ef7f12d88ef988c3f9343641
DiffDOM had updated its code to be written to the
ECMAScript 6 (ES6) standard and so needed extra
work to work with the older browsers in our
support matrix. This was recorded as an issue
here:
https://www.pivotaltracker.com/n/projects/1443052/stories/165380360
Domdiff didn't work (see below for more details)
so this replaces it with the morphdom library.
Morphdom supports the same browsers as us and is
relied on by a range of large open source
projects:
https://github.com/patrick-steele-idem/morphdom#what-projects-are-using-morphdom
It was tricky to find alternatives to DiffDOM so
if we have to source alternatives in future, other
options could be:
- https://github.com/choojs/nanomorph
- https://diffhtml.org/index.html (using its
outerHTML method)
Why domdiff didn't work
Turns out that domdiff was replacing the page HTML
with the HTML from the AJAX response every time,
not just when they differed. This isn't a bug.
Domdiff is bare bones enough that it compares old
DOM nodes to new DOM nodes with ===. With our
code, this always results to false because our new
nodes are made from HTML strings from AJAX
response so are never the same node as the old
one.
As with the last update, the work prepping the
interface that will be used for emergency alerts
for its accessibility audit took priority and has
taken longer than expected. Because of this, we
haven't had time to work on the issues listed
here.
This updates the planned timings to reflect what
we now believe will be possible with the work left
on emergency alerts and amount of work required to
fix them.
Makes the mock up of an alert we show use an
inline SVG instead of it as a background image.
This means it can use the colour of the heading
text next to it in a way that adapts when high
contrast mode is on.
https://github.com/alphagov/notifications-utils/pull/922
Making the icon an inline SVG lets it inherit
colours from the page styles. This helps in forced
colour modes, like Windows high contrast mode,
where it will match the colour of the text next to
it, whatever it is set to.
Making it inline requires some changes to the CSS
to allow its position to match that of the current
background image.
This also sets `forced-color-adjust` to `auto` on
the `<svg>` element, which tells the browser it
can control its colours in forced colour modes.
This is required because the browsers that support
forced colour mode set it to `none` for the
`<svg>` element by default.
The sentences in the key to the map have 2 forms:
1. the visual form, with an graphic pattern
alongside text saying what the pattern means
in the map
2. the semantic form, with text describing what
the pattern means and how big an area it covers
for this alert
This is achieved by making the graphic
non-semantic and having hidden words in the
sentence for each paragraph.
While the spaces between words are correct for
both forms of these sentences, we observed screen
readers speaking some groups of words as one when
they spoke the sentence. Most noticably, 'the
alert' was spoken as 'thealert'.
Swapping the class used to hide the visually
hidden words from ours to the GOVUK one seemed to
fix this. It's unclear why it does but the
`govuk-visually-hidden` class adds the following
styles to those in ours:
- width: 1px
- height: 1px
- white-space: nowrap
It also has `margin: 0` instead of `margin: -1px`.
At the moment, the icons in the key of the map
showing what each type of area drawn on the map
means change colour in high contrast mode. This
causes a mismatch between the areas on the map and
the key.
These changes remake the images in SVG to prevent
the colours changing in high contrast modes. They
also add a white background to the icons, to make
sure they match the areas they refer to in the
map.
The enhancedTextbox component has an element that
sits in front of the textbox and draws the
highlights over the text. This element has a 2px
border so it's dimensions match those of the
textbox. This border has a colour of 'transparent'
by default, to hide it from view but this is
overridden in high contrast modes to match the
text colour.
This adds some CSS targeting high contrast modes
which sets it to match the colour of the
background, making it invisible again.
The link-buttons we use in our pill component
have a blue background which shows the area they
occupy by default. In high contrast mode,
backgrounds are hidden so the link-button text
looks like it is floating because you can't see
the edge of their area.
These changes use the trick of adding a
transparent border. This is hidden by default but
displays in high contrast mode to show the edges
of the link-button. I've reduced the padding to
accommodate the extra space it takes up.
The mock up component, shown in all
current/past/rejected alert pages, doesn't show
fully in high contrast modes because it uses its
background colour to show its shape and
backgrounds are hidden in high contrast modes.
This uses a technique from design system which
adds a transparent border to these elements to
show their shapes. This works because borders of
any colour (even transparent) are rendered as the
foreground colour.
The SVG used for the 'X' in the remove area button
has 2 <g> (group) elements, one wrapping
everything and one wrapping the two lines that
make the cross. The first <g> isn't needed and
means that the SVG ends up with 2 accessible
names:
1. the <svg> element gets named with the text from
the <title> because of it's aria-labelledby
attribute referencing it
2. the first <g> gets named with the text from
the <title> because the algorithm that gets the
name looks for any descendent <title>s
This removes the first <g> so only the accessible
name for the <svg> gets announced.
The size and position of the 'X' has deviated a
bit from the design intentions of the original.
The original shared the x-height of the area text
and has positioned to be vertically and
horizontally centered.
These changes assume an x-height of 11px and use
flexbox to center the new 'X' horizontally and
vertically.
This also tweaks the visual state when focused and
then hovered so matches other buttons without
breaking the design.
The text never had underlines like our other
link-button components so always looked like
buttons. If they look like buttons, they should
act like them too and have those semantics.
This give them a role of button and uses the class
and data attribute for the button component from
GOVUK Frontend to make them work like one.
These changes include a fair amount of styles to
override those the govuk-button class brings in.
I've tried to mark those ones to at least make
that obvious.
The current link button for removing an area is
created using a psuedo element with an 'x' as
content.
The inline box for the 'x' overlapped its parent.
This is visible in high contrast mode, breaking the
parent's border. Despite existing in CSS, the 'x'
is also announced by screen readers, which is not
what we want.
This changes it to be an inline SVG with a role of
image. It doesn't require as large an inline box
so doesn't cause visual issues in high contrast
modes. It also means we can set it's label similar to
how you would an image's alt text, giving us
control over what is announced by screen readers.
This commit also includes some extra CSS,
targeting high contrast modes, giving the
link button the following when viewed in those
modes:
- a complete border so it is
distinguishable from the list item
- a focus style
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.
The Siteimprove accessibility testing tool raised
an issue with our having a div with role=region in
the page that was:
- empty
- with no label
The status has a role of 'region' which makes it a
generic landmark. This means that, unlike <nav>
or <footer>, users don't get any hint of its
purpose from its HTML tag. If we did want this,
we'd have to give it a label to explain that.
I don't think we do want those things. I think
it's more of a sentence that sits between the
searchbox and the results, just saying how many
are there.
That being the case, we should just remove the
role. It's also what design system do with their
character count, which is similar:
https://design-system.service.gov.uk/components/character-count/
Unlike that component, I don't think we need to
use aria-describedby to set the status as the
description of the searchbox because it describes
the results, not the search term.
This is currently spelt incorrectly though it
seemed to work nonetheless. Can only assume this
is a common error, for this attribute or all
attribute names, so browsers work it out.
This makes the spelling match the spec:
https://www.w3.org/TR/wai-aria/#aria-describedby
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.
We now use `sass`, a JavaScript version of Sass,
compiled from dart-sass*, so shouldn't need to
rebuild it to solve issues with C libraries.
*https://github.com/sass/dart-sass
The intention behind the version of node in the
engines property was for that version to be the
minimum required so it was always missing the `>=`
prefix.
This adds that prefix and also adds a setting for
npm, to prevent use of insecure versions. See this
article for details:
https://github.blog/2021-09-08-github-security-update-vulnerabilities-tar-npmcli-arborist/
The way we're using the updateContent.js code is
slightly different to expected and to the
scenarios in our tests. This changes the
tests to match that use.
The expected behaviour was for updates to a
module's HTML to happen to the HTML inside of the
div[data-module=update-content] element.
So with initial HTML of:
<div data-module="update-content" data-key="one">
<div class="ajax-block-container">
Existing content
</div>
</div>
...should be updated to be:
<div data-module="update-content" data-key="one">
<div class="ajax-block-container">
New content
</div>
</div>
Instead the HTML returned by the AJAX requests
replaced the div[data-module=update-content]
element.
So with initial HTML of:
<div data-module="update-content" ..>
<div class="ajax-block-container">
Existing content
</div>
</div>
...will be updated to be:
<div class="ajax-block-container">
New content
</div>
This doesn't seem to create any noticable changes
to the visual interface so, I think, went
unnoticed. The assumption I am making, of this
being unintended, is based on the fact that the
div[data-module=update-content] element has an
aria-live attribute, which authors would normally
want to stay in the page when updates happen.
Note: This commit doesn't try and fix the problem,
as the behaviour still largely works and the lack
of aria-live actually seems to be a positive
thing, meaning non-visual users aren't told of
every update but can discover it themselves if
needed.
A while ago diffDOM moved its code to use ES6
modules and started using various language
features specific to ES6. These two things
happened independently btw.
The result of this is that the version of diffDOM
suitable for our build pipeline, structured as an
immediately invoked function evocation (IIFE),
now requires polyfills of some ES6 features to
work in the older browsers we support, like IE11.
It's also worth noting that in the move to ES6
the maintainers of diffDOM have adopted a process
whereby users who need to support older browsers
now have to add polyfill code for any ES6 features
they choose to use.
This commmit proposes a move to the domdiff
library instead because:
- it runs on all javascript runtimes with no
polyfills
- it is 2KB instead of diffDOM's 25KB
Domdiff takes a different approach to diffDOM, in
that it compares existing nodes and new nodes and
replaces the existing ones with the new ones if
there are differences. By contrast, diffDOM will
make in-place changes to nodes if there are enough
similarities. In other words, in most situations,
diffDOM won't change the node in $component
whereas domdiff will.
Because of this, I've had to change the
updateContent.js code to cache the data-key
attribute's value so we don't lose access to it by
overwrite the $component variable with a different
jQuery selection.
The CSS that cancelled outline on focus events not
fired by the :focus-visible heuristic is being
overridden by the higher precedence of the outline
style for :focus, due to its use of !important.
This adds !important to the cancelling CSS. This
brings that block up to the same level as that for
:focus, meaning the :focus-visible styles will win
because they sit lower in the stylesheet.
There is a slight variance in how the line between
the map buttons is rendered when in forced-colors
mode and when not. This is not helped by it
alternately being rendered as either:
- a gap between buttons, showing the container
colour
- a border-bottom on the first button
This attempts to flatten these styles so it is
only styled as a gap between the buttons so
changes to how its colour renders in different
modes can just be dealt with on the container.
@benthorner pointed out a few things about these
styles that could do with changes:
- the outline-offset will only appear when the
outline does, which is in forced-color mode when
the browser assigns a colour to it, so it
doesn't need to be assigned in a media query
targeting forced-color mode
- the `&:focus:not(:focus-visible)` selector
stops the focus styles showing in scenarios
where:
1. the browser supports :focus-visible
2. focus comes from something other than tabbing
to the map
...so we don't need to target :focus-visible
specifically.
This applies changes to these styles to remove
those not needed and move some to a better place.
Related to this comment on the associated pull
request:
https://github.com/alphagov/notifications-admin/pull/3996#discussion_r699246969
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.
The content of the map buttons jumped on Chrome
and Safari when focused.
It turns out this was because I was testing in
Firefox which Leaflet had identified as having
touch capability (and so added the .leaflet-touch
class). Leaflet makes the buttons 30px rather than
26px for touch-capable devices/browsers so the
jumping was down to the line-height being set for
the wrong container height.
This adds styles to give a different line-height
when touch is available, to match the Leaflet
styles.
Leaflet does this anyway when they're focused
(through JS) but we found holding shift when on a
focused button, which you do when tabbing
backwards, turns this off for some reason so you
see the outline the browser applies by default.
This turns all outlines off to stop that
happening.
Worth nothing that focus is indicated by:
- a change of background colour instead when
tabbing
- a border in forced-color mode
...so the outline is not needed.
Users on devices/browsers that support touch have
the rounded corners styles applied by this
selector:
.leaflet-touch .leaflet-bar a:first-child,
.leaflet-touch .leaflet-bar a:last-child
It has a higher precedence than the existing
selector we use to override it so our overrides
are ignored:
.leaflet-bar a:first-child,
.leaflet-bar a:last-child
This changes the selector for our block of styles
to include one matching the existing styles above
so devices/browsers also get our styles.
Note 1: this actually means some styles were no
longer needed so this also removes them.
Note 2: oddly, this was spotted in Firefox when
displaying high contrast mode on desktop. So not a
touch device but leaflet's JS is marking it as
such.
Also includes a quick fix for high contrast mode.
The buttons are separated by a horizontal line by
default, styled as a border above the 2nd button.
Both buttons use the border when focused in high
contrast mode to provide a form of outline.
This takes away the line dividing them, because
you can only have one border.
The buttons are still separated by a 1px margin so
this just sets a background colour on the
container to simulate the divider.
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.
They all currently say 'Change' which makes it
confusing when they are viewed out of their
context (ie. when all the links in the page are
listed out by a screen reader).
This gives them a suffix relating to the thing
they will change, like the links on the service
settings page.
The fieldset that wraps the collapsible checkboxes
has an aria-describedby to make the summary its
accessible description.
This needs to point to the id of the summary but
the summary didn't have one.
These changes add the id and fix a fixture in the
tests for this module.
The fullscreenTable component has 2 layers to the
table you see onscreen:
1. the actual data table
2. a clone, with only the first column showing,
that sits on top so the row numbers stay in
place while you scroll
Table 1. has an id attribute on its caption. The
region wrapping it has an aria-describedby
attribute with the id as its value. This makes the
caption the description for the region.
This isn't needed for the clone and
makes the HTML invalid because ids should be
unique.
This removes the id from the cloned table.
Tom Byers