Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Current »

Component type

Atom

Component possible inclusions

n/a

Design source (in Figma)

Heading block

Component status

DSD-54 - Getting issue details... STATUS

Introduction

The heading block allows creation of both simple headings and more complex heading systems that balance overline headings, standard headings and subheadings. 


Anatomy

Related/Similar Components 

  • Page Headers, Teaser/Promos, various list items and other elements include headings plus other sibling elements. The heading block supports headings only. 

  • Rich text TBC 

Key Content  

Item 

Type 

Notes 

Heading 

Basic Text 

Description 

Simple RTE 

 

Visual Style 

A fully realized heading block will deliver support for different heading layouts.

Support for ‘edge-aligned’ vs ‘centre-aligned’ can be programmatically pre-set rather than needing to introduce style controls into the CMS. 

Behavior 

  • Headings must support the ability to be linked. If linked, they will take the ‘linked heading’ style variant and will behave as a link. 


Usage

Use When 

  • You are starting a new content section on the page. 

  • TBC balancing as a standalone component vs Rich Text. Solutions need to deliver semantic, ideally programmatic, heading control. 


Editorial

  • Keep headings short, direct and attention-grabbing. 

  • Avoid using an overline heading, heading and subheading within the same element (nb: we might be able to govern this within the CMS). 


Accessibility 

  • It is required to be sure that headings are delivered on the page are in a logical order and that we aren’t tying content and code together (e.g. the same heading might be used in two places, but due to its context in the page, it might be an H2 in one place and an H3 in another)

  • Headings represent the start of a new explicit or implicit section. When constructing a page, no related content should come before the heading. There are some use cases where this is possible (e.g. the image appearing to come visually before the heading in product and page cards) but these have been specifically created to combine these elements in a way that manages them accessibly. There is (or was) an example of paragraphs coming before headings on the W3C website, but they need to be located to be assessed before changing the semantic understanding as a base assumption. 

  • Heading semantics (e.g. heading 1, heading 2) and heading styles (e.g. size) must be disconnected. Whilst the typography system suggests a default size for each semantic heading level, they can be overridden to achieve style outcomes (e.g. in cards, etc). 


Analytics & Data 

  • If any analytics is required, it would simply be tracking of a linked heading or element visibility of the heading. This would only require that the heading be able to be individually isolated. 

  • No labels