Typography

[govuk-design-system]

Use this issue to discuss typography in the GOV.UK Design System, including links and lists.

[edwardhorsford]

@Tosin-Balogun no specific research, but the main places I've used before have been service homepage / landing pages / interstitial pages.

Some examples of usage:

Intro paragraph for start page:

Description paragraph:

[Tosin-Balogun]

Thank you for sharing these @edwardhorsford. I think we in the NHS have also used them on hub pages, but we wanted to know if they were suitable for introductions on content pages as well and there's not enough evidence on how they have performed there.

This is in relation to what the guidance says in both the GOV and NHS design system documentation.

• https://service-manual.nhs.uk/design-system/styles/typography
• https://design-system.service.gov.uk/styles/typography/#paragraphs

I'm wondering if you have observed any user behaviour when used on start pages

[calvin-lau-sig7]

In 2023, the GOV.UK Design System team will be reviewing and improving our typography standards to make sure they’re up-to-date and as accessible as possible for users and service teams.

Read a blog post about our plans.

[samantharsaw]

When dropping the H1 size down to govuk-heading-l class on content pages with lots of nested content, it becomes difficult to differentiate between H3 and H4 in the hierarchy as there isn't a class smaller than govuk-heading-s. Could an xs size be introduced? Or has anyone else discovered a need for this too?

[joelanman]

@samantharsaw is the solution here to use heading-xl for the h1? That's the standard guidance for content pages

[samantharsaw]

Hi @joelanman this was specifically for content pages where there is quite a long heading. We've dropped the size down to -l from -xl as advised for long headings

[stevenjmesser]

Have any other services found issues with purple visited links in their testing? See https://github.com/alphagov/govuk-frontend/issues/3242 for a description of the issue.

[selfthinker]

Last week we had a meeting with a GOV.UK publishing department and learned that they mistook the lead paragraph to be a heading, specifically a level 2 heading. That prompted them to (wrongly) only use level 3 headings in their content. Although the guidance says to start with an H2 in the main content section, they assumed there already is an H2. Following that logic, using an H3 would be the right thing. I have seen lots of content on GOV.UK only using H3s, so I assume that this wasn't the only department misunderstanding that.

It is usually an accessibility issue if something looks like a heading when it isn't a heading. I personally don't think the lead paragraph looks like a heading (because I know the context of how all the other headings look like) but I can easily see how someone else might think it is one.

Has anyone come across this before? Has anyone ever thought of "fixing" it?

I suspect even if citizens confused the lead paragraph with a heading, it will very rarely have any consequence for them. The only type of users I can think of who might be affected are screen reader users who can see how the paragraph looks like. They might be confused why the screen reader doesn't register the paragraph as a heading.

[querkmachine]

At the end of last year we added box-decoration-break: clone to the link focus styles in order to resolve an inconsistency in Chromium-based browsers. https://github.com/alphagov/govuk-frontend/pull/3087

This may present an issue if a link has been customised with paddings or margins.

In this hypothetical example, here the link has been given some margin-left to separate it from the associated heading:

However, when the link becomes focused, the start of the next line becomes indented as the margin is cloned on focus.

This is probably not a significant issue at this time, but something to note down for future reference.

[DWPenjamin]

We recently tested our service with additional captions above our h1s which indicated which section they are currently on, and I thought it would be worth sharing the feedback we received on them.

Most users did not notice them

• "No I didn't, that could have been highlighted"
• "I knew it was there but didn't notice it"
• "I didn't read it. I read the huge, bold [title]."
• "This bit at the top? No I think you go straight to the big black writing."

Users felt the design / spacing (next to h1) wasn't right

• "The size. Or making the title smaller.  that would make it stand out more"
• Q. "Do you think it's useful?" A: "Yes I think it should actually be dark black as well"
• Q: "helpful?" A: "No, you need to separate them."
• Q. "why didn't you notice it?" A. "It's grey and smaller? it s quite close to the next line [title]"
• Participants took wild guesses about what the grey text meant and some thought it was the page title (because of its position), but couldn't then understand why the text that came next was so much bigger.

Some users got that it's not essential information and is there if you need it

• "Yeah I think it's clear, summarises the page. Probably not overly necessary with the big text what the page is about - don't need it but nice to have"

I realise that the intention is likely it doesn't want to draw attention from the h1 and if users don't necessarily notice it, it's not a bad thing. But I wanted to share those findings as I felt general feedback on specific designs will likely be helpful.

We significant improved comprehension by adding "This section: in front". This didn't make the grey captions more noticeable, but ensured that participants did understand the captions - and their relationship to the page titles - when they did notice, or when the captions were pointed out to them.

Example of one iteration of the captions we tested

[selfthinker]

In the latest accessibility audit of www.gov.uk DAC raised an issue with the blue link colour (#1d70b8) on white. It fails WCAG 1.4.6 Contrast (Enhanced) (Level AAA). Although we don't necessarily aim to meet AAA criteria and especially the contrast criterion can be difficult to meet without making things worse for other users, I thought I'd share it here anyway.

One of their low vision users commented:

The low contrast and lightly rendered links on GOV.UK pages create a challenging experience. The links’ lack of visibility against background glare, particularly when grouped together, leads to reading fatigue and difficulty in discerning the text. The contrast between the main text and the link text within larger bodies of text poses additional challenges. The stark difference makes it hard to switch focus between the two, often leading to misreading or inability to correctly identify the links. Using higher contrast for links may enhance their visibility and readability. It's important that the links are distinguishable while maintaining the overall visibility of the content.

The same low vision user also mentioned how the hover state of links is very difficult to see for them and therefore makes it difficult to understand where the pointer is. They were very happy with the focus state, but because they are someone who predominantly uses a mouse to navigate, the focus state doesn't help them to find where they are on the page. This didn't end up in the report but was mentioned during a demo.

It would be interesting to know if other services had similar feedback for either of those two issues.

[sbasile-ch]

Regarding the "Links to change a language" and the 3rd guideline: "[...] make sure: ...

• _the link element includes an hreflang attribute ..._

I've spent some time reading about that attribute (mainly, but not only, here) and I'm not fully convinced about that given guideline. That's not where & how, I'm undertanding, that hreflang attribute is supposed to be used. Might you please add more info regarding that requirement ?

Also, minor point probably but anyhow the link might better point to the standard RFC8288, rather than to w3schools which in some places (here or here) is not considered the best source

[owenatgov]

Hi @sbasile-ch 👋🏻

Could you please expand on what you expect the hreflang attribute to do? To me it feels like we're in line with browser recommendations. A page has a link with an hreflang, a link to that page includes a matching hreflang. I wonder if there's soemthing I'm missing in how that line is perceived on the links page.

Re: your second point, I think it's reasonable to swap out w3schools for MDN as we reach for MDN more commonly in guidance. I've raised a PR to this effect for the rest of the team to assess.

[sbasile-ch]

Hi @owenatgov thanks. I just find some different interpretations of what hreflang is there for. The main usage (pretty much everywhere wiki included) being of it as a Meta element, so staying in the <head> section and relevant to SEO only), while at the link level I cannot see that used other than for "documentation" purposes.

EDIT: I think I went to the bottom of this. Most of what is detailed out there refers to hreflang of the <link> element rather than <a>, as they both have it and they address different use cases. All the info at that "Link" specs seem to address just the <a> anchor tag. To prove that the confusion is easy, I'd say that in theory the last PR is addressing the <link> one , while, replacing the previous <a> w3schools case it should probably point to this one

[obrunt90]

Hey gang - new designer here for HMRC - does anyone know how we handle orphan/widow copy. In previous roles (external companies) we've always hunted them down and coded in so they shouldn't happen. Just wondering what the system is here (a quick glance says that we don't force them).