Brief: Heading block v. 0.1 [Component]

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

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. 

Don’t Use When 

• X 

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  

 *Text flexibility and control needs to be discussed more broadly. 

Visual Style 

A fully realised heading block will deliver support for different heading layouts. MVP can get by with a ‘standard’ heading only and we can build complexity from there. It is important though to understand how these components can grow, so that we can pre-empt potential issues. 

Support for ‘edge-aligned’ vs ‘centre-aligned’ is currently being looked at to see if it can be programmatically pre-set rather than needing to introduce style controls into the CMS. 

There is also a use case for requiring a ‘visually-hidden’ utility class for headings. 

Open

 Note: There is a design error here were description text is being used instead of subheading text styles. This will be updated within design files. 

Behaviour 

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

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 

• Whilst not impacting the visual style, but rather the underlying HTML, a significant top level discussion is needed to understand how we can best ensure that headings are delivered on the page 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). Either we need to solve programmatically (ideal) or we risk needing to duplicate content. 

• 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 

• None of note. 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. 

Future Expansion 

• Beyond just a basic ‘heading’, the concept of the heading block is anticipated to extend to support overline headings and subheadings. Subheadings are a reasonably simple concept. In HTML they are just a paragraph styled as a ‘subheading’. Overline headings are a little more complex as in some use cases the two elements may need to be stitched together with a <span> and in others, the overline heading may represent a categorisation which needs to be delivered after the heading and with accessible context and then adjusted visually to sit above the heading. For these reasons, this has been descoped from the MVP.Page Break 

Wider Conversations that may impact this 

• Heading control: Configurable (ideally not) vs programmatically determined (preferred) 

• Style control: Considering a headless CMS ‘technically’ offers no front end control. Unless we significantly lock down style flexibility (possibly an option), how do we intend to allow for style configuration? If needed, can we tokenise layout? (e.g. left/right) or adjust style based on semantics (e.g. product teaser vs content teaser). 

Heading Block Examples 

Most Reckitt websites have managed to exist by supporting ‘standard’ headings only. However there are some examples of a more complex ‘heading block’ approach – just that they haven’t been delivered to semantic best-practice. 

http://d-conproducts.com   

Open

Is this example the overline heading “Solution Center” is probably a better, more accessible heading than “The D-Con Academy” which would act better as a subheading. Alternatively, the heading could be a spanned combination of “Solution Center: The D-Con Academy”. As noted, this complexity is why overline heading support can be descoped from MVP.