Visual users get the context from the proximity to
the h2 but we need to provide this for others.
I've tried using `aria-describedby` to link them
to the h2 but this ends up making the h2 text the
button's description in the accessibility tree. In
Voiceover this means you only get that information
as extra context, announced a while after the
label if the VO cursor stays on the button.
We want all the information in the accessible
label so chose this approach instead.
Paired with @aliuk2012 on the implementation and
with a view to making the component generic enough
to be used on digital marketplace apps as well.
These changes came from that session.
They include:
- removal of an unused `data-accept-cookies`
attribute
- removal of `govuk-!-padding-top-4` class and
moving of associated styles into component CSS
- swapping out the `aria-label` on the parent
element for an `aria-describedby` linked to the
h2 to have one thing labelling the banner region
- removal of unused CSS and any already provided
by the govuk-button class
- inclusion of @import's for styles attached to
govuk-body and govuk-button classes
Copies HTML and Sass from GOV.UK Pubishing
components cookie-banner with changes to content
and functionality to better suit Notify.
Changes are:
- adds a 'reject' button which the GOV.UK
code doesn't have
- adds Sass from the GOV.UK Frontend button
component which the GOV.UK version used so
is included here
- removed click tracking from cookie banner
It looks like a link so its semantics should
identify it as one.
This can effect users of speech recognition
software, in scenarios where they instruct it to
click an element which looks like one thing but
the software can only identify as something else.
Visual users get the context from the proximity to
the h2 but we need to provide this for others.
I've tried using `aria-describedby` to link them
to the h2 but this ends up making the h2 text the
button's description in the accessibility tree. In
Voiceover this means you only get that information
as extra context, announced a while after the
label if the VO cursor stays on the button.
We want all the information in the accessible
label so chose this approach instead.
Paired with @aliuk2012 on the implementation and
with a view to making the component generic enough
to be used on digital marketplace apps as well.
These changes came from that session.
They include:
- removal of an unused `data-accept-cookies`
attribute
- removal of `govuk-!-padding-top-4` class and
moving of associated styles into component CSS
- swapping out the `aria-label` on the parent
element for an `aria-describedby` linked to the
h2 to have one thing labelling the banner region
- removal of unused CSS and any already provided
by the govuk-button class
- inclusion of @import's for styles attached to
govuk-body and govuk-button classes
Copies HTML and Sass from GOV.UK Pubishing
components cookie-banner with changes to content
and functionality to better suit Notify.
Changes are:
- adds a 'reject' button which the GOV.UK
code doesn't have
- adds Sass from the GOV.UK Frontend button
component which the GOV.UK version used so
is included here
- removed click tracking from cookie banner
Their priority should always add up to 100%. Currently we have to ensure
this by hand. Adding this form means there’s no way to not set their
combined priorities to 100%. And it’s a bit more of an intuitive UI than
two textboxes on separate pages.
Replaces the following blocks/variables with the
`footer` block filled by the `notify_footer`
macro:
- footer_top
- footer_support_links
Our current footer has a few differences
with the GOVUK Frontend one:
1. the columns of links and the meta links have no
headings, visible or structural
2. the line of text saying GDS built this prefixes
the meta links whereas theirs sits on a new
link, after them
Replaces the following blocks/variables with the
`footer` block filled by the `notify_footer`
macro:
- footer_top
- footer_support_links
Our current footer has a few differences
with the GOVUK Frontend one:
1. the columns of links and the meta links have no
headings, visible or structural
2. the line of text saying GDS built this prefixes
the meta links whereas theirs sits on a new
link, after them
Replaces the following blocks/variables with the
`footer` block filled by the `notify_footer`
macro:
- footer_top
- footer_support_links
Our current footer has a few differences
with the GOVUK Frontend one:
1. the columns of links and the meta links have no
headings, visible or structural
2. the line of text saying GDS built this prefixes
the meta links whereas theirs sits on a new
link, after them
Adds ability to have inline radio buttons using the fieldset.inline
functionality from gov.uk elements.
Then implements this for the radio buttons for choosing postage
class.
Also overrides the gov uk elements styling for the inline radio
buttons to place them slightly closer together as this looks
better.
HighlightTags was bad because:
- we haven’t called placeholders ‘tags’ for a long time
- it also does resizing of the `<textarea>`, not just highlighting the
placeholders
Scrolling within textareas on the page is a bit grim. Which is why we
don’t do it for the textboxes that people use to edit templates.
This commit will allow us to extend the auto-resizing of `<textarea>`s
to those which don’t need the highlighting of placeholders.
The code is still quite coupled to the placeholder highlighting code,
because both work by copying the content of the `<textarea>` into a
`<div>` that underlaps the textbox. This `<div>` is used for both
rendering the placeholder highlights, and calculating the natural height
of the content. So it would be hard/confusing to split the two bits of
code into separate modules.
We now use the pattern of showing a box at the top of the page with the
error. The error message has a heading and can have additional details.
Error messages and the invalid pages get stored in the S3 metadata.
Most GP practice services are named after the practice, which is the
organisation.
So rather than make people re-type the name of their organisation (and
potentially make a typo) let’s just let them say ‘yes, that’s the name
of my organisation’.
It looks weird to have two different visual treatments for showing a
navigable hierarchy.
I reckon losing the slash won’t make things less folder like – Windows
for example uses chevrons as foler separators.
If it’s something weird like an instance of a Python object let’s ignore
it (else we get invalid HTML like
`id='<notifications_utils.columns.Cell object at 0x1126f4e80>'`).
For accessibility reasons a page should have one (and only one) H1. This
commit fixes an instance where the H1 was duplicated as a result of the
work done to componentize our page headings.
It also adds an extra check to `client_request` so that we don’t
introduce pages with multiple or no H1s in the future.
Live regions need to be in the original HTML of
the page to work. We were generating the summary
in JS.
This changes the JS to only generate the contents
of the summary so changes to its contents are
announces by the existing live-region.
Expands the API of the macro to allow nested
checkboxes to have a summary tracking the current
selection, the fieldset to expand/collapse and
buttons to be added to allow jumping between
states.
Includes making 'Done' button inline on mobile.
Helps differentiate it form the form submit.
Since we added template folders the templates page has had a ‘medium’
sized heading, where other pages have stuck with a ‘large’ size.
This commit rationalises the decision around which pages have which
heading size:
- ‘navigation’ pages (eg templates, team members, email reply to
addresses) have medium sized headings
- transactional pages (ie ones which have a green button) keep the
larger heading size
We’ve stopped using them in favour of putting any ‘back’ link at the top
of the page. This commit removes them from the macro to make sure we
don’t accidentally reintroduce them.
The Design System has standardised on back links being at the top of the
page, decorated with a small text-coloured arrow.
I think this makes more sense than having them at the bottom, because it
suggests, in some way, being able to go back before commiting to any of
the forms on the page. Whereas the things at the bottom of the page
should be performing actions on what’s in the page.
The reason for making this change now is that it de-clutters the area
around the green buttons. This was presenting a design challenge where
multiple levels of interaction were happening in the same form. Moving
these back links to the top of the page should mean that, in these
complicated forms, there’s one fewer thing to compete for the user’s
attention.
I’ve componentised this into a `page_header` macro so that the change is
easier to roll out and maintain.
