This is no longer happening with the NVDA screen
reader, which had the issue, when testing in
Outlook.
The hack added as a temporary solution has now
been removed. It went live on 19 November 2020 at
2.20pm.
Proof of concept for the GovukRadiosField class.
Includes the removal of the a DataRequired
validator. This doesn't seem to be needed as the
RadioField superclass catches any submissions
without any data from field.choices in its
pre_validate method (which also outputs the
correct error message).
The _Long text messages_ section of the page is probably the most relevant place to talk about this – so users are aware of the double-characters before they see the table of message lengths.
Live services shouldn't be able to request to go live again. Once a
service is live we remove the option to go live from the Settings page,
but we still link to the page to request to go live from other places
e.g. the 'Get started' page. As a result, we've seen some services make
another request to go live when their service has already been live for
months - this change will stop that from happening.
The `.send_from_contact_list` function redirected to `.check_messages`
with `original_file_name` in the query string. Contact lists already
have `original_file_name` as part of their metadata, so we can stop
sending it in the query string and use the metadata instead.
You might alternate between training mode and live mode. It’s not like
normal Notify where you start in one mode and then transition out of it
– which is what ‘still’ implies.
I'm mainly making this change because it's useful
for the CSS that styles the hint text when the
link is focused for the link to have no parent
container.
That being said, there isn't really enough content
underneath these headings to justify them as it is.
I've wrapped them in a list instead because:
- they're structured like a list
- we already called them a `template-list`
This commit also replaces the `message-type` class
on the paragraph below where the headings went,
for consistency. It also removes the CSS for that
class as I couldn't find anywhere else that used
it now.
When the list of areas is restricted to half the width of the page it
starts to look pretty higgledy-piggledy when you have lots of areas or
areas with very long names.
To do this I’ve ripped out the table markup in favour of headings,
paragraphs and lists. Probably pros and cons for each, but it was really
hard to do the layout with the content in a table.
Now that pending alerts aren’t in their own section there’s nothing to
label them as pending. So this commit replaces the extra metadata we
show for a pending alert (the name of the person who created it, which
was only ever a reckon) with an explicit label that says it’s waiting
for approval.
Splitting the dashboard into multiple sections was confusing, and people
sometimes mistook the headings as labels, especially when a section was
empty. It just wasn’t clear what the hierarchy of the page was.
This commit combines the current and pending broadcasts into one list
on the dashboard. Previous broadcasts have already moved to their own
page.
Once a broadcast has been submitted for approval it either lives on the
‘Current alerts’ or ‘Previous alerts’ page, depending on where it is
in its lifecycle.
Therefore when clicking into a broadcast from one of those pages the
same navigation item should remain selected.
Because we select the navigation items based on the request endpoint,
this means we need an endpoint for each navigation page, even if the
content of the pages will be the same in both cases.
This commit adds the two new end points, removes the old, single
endpoint and updates links to point to the new endpoint.
The following issues were raised with the table
that replays CSV data to users:
1. the table could not be located by low vision
users using the reflow technique
2. the content should be presented in a single
column when the reflow technique is used
Number 2. came from the Web Content Accessibility
guidelines (WCAG) success criteria 1.4.10 Reflow.
I wasn't able to reproduce number 1. so asked the
Digital Accessibility Centre (DAC), who tested it
originally, for help. Tom Shaw from DAC kindly
retested it and found the problem was gone so I am
considering it fixed.
I am treating number 2. as a misinterpretation of
the success criteria as it lists data tables as an
exception to the rule:
"Except for parts of the content which require
two-dimensional layout for usage or meaning.
...Examples of content which requires
two-dimensional layout are images, maps, diagrams,
video, games, presentations, data tables, and
interfaces where it is necessary to keep toolbars
in view while manipulating content."
The full page is here:
https://www.w3.org/WAI/WCAG21/Understanding/reflow.html
The accessibility statement was last updated on 9
October 2020 but without the 'last reviewed' date
being updated.
The changes were contained in this pull request
which was merged the same day and reached
production at 2.13pm.
https://github.com/alphagov/notifications-admin/pull/3677
The most important part of the broadcast is what content was sent where
(and when).
This commit reduces the priority of the ‘meta’ information, like who
prepared and approved the broadcast. I also think that the ‘end’ time is
a lot less important than the start time, since most people will receive
the alert at or near to the start time.
This then matches the order in which the message is drafted, first the
content, then the areas. It also matches the order we’re going to have
on the new dashboard.
