Editor's publishing checklist

Last updated: 21 March 2025

This page is regularly updated – see the log at the bottom of the page for details of what is new or amended.

Why we have this checklist

The Web Content Team uses this publishing checklist to quality control the pages that they publish and unpublish. The checklist follows WCAG 2.2 accessibility criteria and promotes the best user experience.

We expect other publishing teams and editors to also use this Quality Control checklist.

Users do not want to have to stop and think to work out how to get around, use or understand a website. We use something called ‘content patterns’ in the design and structure of our website to help our users perceive, understand and use it.

A content pattern goes beyond the realms of a traditional style guide. It ranges from reusing specific words for the same things, through navigational structure, to determining where we place help buttons on a template.

We also provide a set of guides to help people write and create accessible and user-friendly content.

This checklist has been created to ensure that key patterns and accessibility criteria are met.

When to use this checklist

Not all the elements on this checklist are relevant to every published page. But you must use the checklist as a reference point to ensure that your publishing is compliant.

The checklist is regularly updated for many reasons. It can happen as:

  • WCAG changes
  • ITS create new developments and functionalities
  • we recognise content patterns in the website and need to apply consistency

It is important that you keep up to date and regularly return to this checklist.

List of checks for new and amended pages

1. Run the accessibility tools

  • Chrome extensions:
    • Silktide Accessibility Checker
    • WAVE
  • NVDA
  • Plus others, as appropriate.

If you are unsure, please check with the Web Content Team.

2. Is the navigation to the page clear?

  • How does the user get to the page?
  • Go to the level above - is there a clear link to the page?
  • Can the user navigate across all pages within the associated subsite from the side menu?
  • Check breadcrumb.
  • Direct knowledge of the URL, or only through search engines, isn’t good – ideally there should be a navigation route for users.
  • If this isn't a clear navigation to the page, raise this with the content owner and negotiate a path.

3. Is the H1 page title duplicated elsewhere?

  • The H1 heading is the page title and must only be used once. Do not mark up any other headings as a H1.
  • If a generic or familiar sounding title is presented, check to see if it is already used.
  • If it is used elsewhere, change the title to a unique title descriptive of the page content, and either:

4. Browser tab title

  • Make sure the browser title matches the page’s title. The tab title is always followed with ‘| Liverpool John Moores University’.

5. Breadcrumb text

Make sure the title displayed in the breadcrumb text matches the page title.

6. Side navigation menu

Make sure it is clear where the link is going and what the content is going to be. Avoid generic terms in the  link text.

For example, ‘About us’ is too vague – it could be contact details, or it could be detailing the team’s services and biographies.

The word ‘us’ is too generic – change this to the team’s name.

If the side menu has a link offering help to the user, it must be placed consistently across the website. This is so the user knows where to look when they want help.

For example, ‘Contact the Finance team’ is a link offering help.

Always place this ‘help’ type of link as the last link in the side menu.

If the link is directly opening an email, then the link text should say ‘Email the xxx team.’

7. Updating or changing a H1 page title

  • If the updated page title is generic or familiar sounding, follow step 3.
  • Check and change the browser title to match the updated page title.
  • Check and change the breadcrumb title to match the updated page title.

8. Headings

  • Check and make sure that the headings and subheadings are correctly marked up in a logical sequence.
  • Make sure there is a H1 page title.
  • Page content that starts with a H2 (no introductory text first) should use the ‘Heading’ field in Sitecore – this supports the search engine better.
  • A page that starts with text first, must use the Rich Text Editor to markup any following headings within the text.
  • Remove punctuation from the end of a heading. For example, headings do not end on full stops or colons.
  • Headings cannot be a link.
  • If you are editing and removing headings, make sure the Headings tags are also removed from the HTML. Empty headings will trigger accessibility errors.

9. Check for misspellings

Misspellings may present users from finding the content via search engines. Misspellings risk the reputation of LJMU.

  • Check for spelling errors and correct all that are found.

10. Introductory paragraphs

Historically, some introductory paragraphs used H3 heading mark up to look larger. This is inaccessible and must be changed. The following advice is only for introductory paragraphs that need to appear with a larger font.

  • Always check the markup and change from a <h3> to a <p><span class="large"> style.

11. Links

  • Do the links work?
  • Are the links descriptive, and correct?
  • Are the links using too many or too few words?
  • Are there two individual links side-by-side and hard to distinguish as separate links? Separate these by rejigging the sentence. If it is a complex text, explain the problem to the content owner and ask for clearer text.
  • Do not use the same link text for different destinations. This includes making sure your link text does not repeat link text already used in the main website header, megamenu, footer and side menus.
  • If the link opens an attachment, it must include the format and file size in the link text. Example = video production guidance (PDF, 880KB).
  • Avoid anchor links where possible.
  • Change naked URLs to descriptive link text.
  • Change naked email links to descriptive link text. You must:
  • Make sure that links do not include the space before or after the link text.
  • Ensure there are no hidden links on the page. For example, this is often a link on a random space character.
  • Using the keyboard tab, do all the links on the page tab in the right sequential order?
  • You can also use the Taba11y Chrome extension to check.

12. Linking to an internal site

  • All internal links must be created through the Rich Text Editor’s ‘Insert Sitecore links’ tool. This prevents future broken links.
  • Do not open in a new tab.

13. Linking to an external site

  • Do not open in a new tab - this sends our users away from our site and we lose engagement. 
  • Use the link text to tell the user where they are going. (When the link text does this, it will not need to open in a new window.) Example = Find a postcode on the Royal Mail's postcode finder.
    If the link does not make it clear that the user is going to an external site, then add the destination to the link text.

14. Links that open in a new tab or window

  • Do not open links in a new tab or window. This is disorientating and not an accessible practice, and the user cannot easily return to the previous pages.
  • If you cannot avoid opening a link in a new tab, the link text will automatically add ‘(opens in a new tab)’ to the link text. Example = Barclays IT Unix Division (opens in a new tab). This is programmatically set to happen when a link includes target=“_blank”.

15. Formatting

Ideally, appropriate formatting will already have been indicated by our content authors. You need to check and correct the following elements.

Arrows

  • Do not use the greater than (>) and lesser than (<) symbols for arrows.

Asterisks

  • If asterisks are used to create footnotes, or to lead the user to content elsewhere on the page – they will have to be removed.
  • You will need to negotiate with the content owner for new content to bring the annotations into context.

Bold

  • Remove excessive bold - keep to significant text only.
  • If the text is bold for an important and complete message, consider using the ‘important’ style – see the formatting information below.

Bullet list 1

This bullet list is the most common format.
It is a list with a lead in line. These lists look like this, and they:

  • always have a lead in line ending with a colon
  • do not start list items with a capital letter
  • do not have punctuation at the end of the item
  • do not have 'and' or 'or' between items
  • make grammatical and contextual sense when each item is read on from the lead in line

Bullets list 2

Only use this format for a pure list that does not have a lead in line, or a for a set of steps and instructions.

  • Always start each item with a capital letter.
  • Always use punctuation.

Bullet lists – links in a bullet list

  • Check to see if hyperlinks in the bullet list have unnecessary tags in the HTML and remove.

Capitalisation

  • Dot not capitalise complete sentences or paragraphs.

Colour

  • Do not use colour for adding meaning or emphasis to text.
  • Do not use colour for adding meaning or emphasis to other items.

Dates and times

  • Check dates and times are formatted properly.

FAQ accordions

  • Is it necessary?

If you must have an accordion component:

  • All headings within a FAQ accordion must follow the correct heading formatting. The FAQ component title is a H2 heading, so headings within an accordion must start with a H3 heading, and sub-headings as a H4, and so on.

Footnotes

  • If content contains footnotes - they will have to be removed.
  • You will need to negotiate with the content owner for new content that brings the footnote content into context.

Important info

  • Use the ‘important’ CSS style.
  • Make the first couple of words bold (usually ‘Please note’, or ‘Important Info’ or something similar) and then wrap to the next line with a soft return (shift+Enter).
  • You will need to apply your discretion to ensure that the content follows the recognised content pattern. For example, if you spot a paragraph of bold, it is probably intended to make important information stand out, so apply the ‘important info’ style. If the paragraph does not start with ‘Please note’ or something similar, add this or another appropriate phrase, or make the first 2-3 words bold.
  • Use sparingly.

Font size and style

  • Check consistency and remove all spurious formatting.

Important
In September 2023, the website CSS was updated to remove Helvetica font and replace it with Roboto. This was because the Helvetica licence expired. When viewing your page, if you see a Serif or odd font, then the text is likely to be hand-formatted with Helvetica or another font that we don't use. You must remove the formatting and use the standard styles in the Rich Text Editor.

Links formatting

  • See:

Non-breaking spaces

This interrupt reflows.

  • &nbsp; - check and remove from the HTML, unless it is a set of words that cannot be broken apart.
  • Do this as your last check in the Rich Text Editor because other changes can bring in unnecessary non-breaking spaces.

Spacing

  • No double spacing.

Telephone numbers

  • Make telephone numbers an active phone link. This will support mobile users.
    For example: <a href="tel:01512314166">0151 231 4166</a>

Underline

  • Never use underline. Only hyperlinks should be underlined.

16. Language

Ideally, this will already have been captured by our content authors.

  • Always explain acronyms when they are used for the first time on a page. After this is OK to only use the acronym.
  • Change & for 'and'.
  • Change slash (/) for 'or' or ‘and’.
  • Change contractions to complete words. For example, change can't for cannot, don't for do not, shouldn't for should not.
  • Change e.g. for 'For example' or 'such as', or similar.
  • Change i.e. to ‘that is’ or ‘meaning’, or similar.
  • Do not use the greater than (>) and lesser than (<) symbols for arrows.
  • Remove full stops from abbreviations, example = B.B.C. for BBC.
  • LJMU, Liverpool John Moores University, the university = only acceptable formats.
  • Check numerical formatting.
  • Use the correct mathematical symbols.
    Because screen readers are not reliable with symbols, there are two options – HTML entity codes or Alt codes. You will need to listen to how they are read out loud in your context.
  • Symbols – for all kinds of grammatical, typographical, numerical, foreign language with accents etc, follow this link to the WC3 School lists of entity codes.
  • Amend typos. 

17. Images

  • Right sizes for desktop and mobile?
  • Use an alt tag only if:

18. Download documents (attachments)

  • Query whether the content should be a HTML page? Advise author or owner.
  • Links to downloads must be followed by the file type and file size, example = Download document (PDF, 61KB).
  • Download document must be accessible – the content owners are responsible for their own content.
  • The Web Content Team will not upload a document that is not accessible.

19. Tables

  • Recommend to not use them.
  • Never use them to lay out the structure of the page.
  • Use for basic data only.
  • When creating a data table, use the Table Wizard. The table must have:
  • A table that needs 2D scrolling (both sideways and up and down) to read the content is not accessible. Discuss changing this format with the content author.

20. Call to actions (CTAs)

  • Only use buttons for an action (not for a link, because section links are used to link to other pages).
  • Do not overuse on a single page.
  • Do not repeat on a page to the same link.
  • The CTA’s text must be descriptive, concise and, preferably, front-loaded.

21. Summary or synopsis

  • Has it been supplied?
  • Check that the existing is up-to-date and accurate – if at all unsure, check with the author.
  • Are the fields on the template empty? If so, you must add up-to-date and accurate data.
  • Keep synopsis to between 60 and 160 characters. This supports search engines and helps the users to find the page. Less than 60 characters is not useful for search engines. Sentences more than 160 characters will be truncated with an ellipsis.

22. Keywords and metadata

  • Have they been supplied?
  • Check that the existing is up-to-date and accurate – if at all unsure, check with the author.
  • Are the fields on the template empty? If so, you must add up-to-date and accurate data.

23. Navigating away from a page

For links that appear on the page content and intend to send the user onto another page, site or action, please follow any of the following rules.

  • Links within text - use an inline link.
    See the ‘Links’ item for further details.
  • Links to another page or site – use a section link.
    See the ‘Section links’ item for further details.
  • Links to an action or asking the user to do something such as completing a form – use the CTA button. A link to go to another page is not an action.
    See the ‘Call to actions (CTAs)’ item for further details.
  • The text used for the links must not be generic.
    See the ‘Links’ item for further details.
  • The text used for the links must not repeat other links that go to different destinations.
    See the ‘Links’ item for further details.

24. Section links

  • Check how the sections links display in different responsive views and adjust the properties of the numbers of columns to provide the best display of the section links for each individual page.
  • Use the appropriate design for the level of content. If unsure, check with the Web Content Team.
  • A section link that is offering ‘help’, such as a ‘Contact us’ link must be the last link of the set. The text link must not be generic and must describe the link destination clearly. For example, ‘Contact us’ should be ‘Contact the xxx team’.

25. Listen to screen reader

For example, NVDA or Edge ‘Read Aloud’.

  • If all other points in this list are correct, then the screen reader should be OK.
  • NVDA gives the most comprehensive experience of a screen reader and is the recommended tool.
  • Browser screen readers such as ‘Read Aloud’ are fairly superficial but could catch any content that is being read in the wrong order, for example.

26. Finishing the publishing process

When finishing the publishing process, and before you sign the task off, you must check:

  • the page in preview and in different device sizes for a final sense check
  • review the page on the live website and revisit any issues still in place
  • that the page or component is unlocked in Sitecore

Unpublishing a page

When a page is unpublished, you must:

  1. check for pages and other components that link to the page
  2. replace, fix, or remove links to the unpublished page
  3. contact the content owner for updated text if a removed page link alters the context of the page

For further support and information, see the Web Content style guide and our other guidance.

For Web Content Team only

Although only the Web Content Team can action new and unpublished pages, all editors and authors should be aware of the following process.

New pages

When you create a new page, including blank pages created for other publishing teams, you must:

  1. add the page title and URL to the master content map in the appropriate structural place

This is so we can maintain an accurate view of all the content within the LJMU website.

Failure to do so, means that pages may be missed in any website-wide reviews, audits and updates.

Unpublishing pages

When you unpublish a page, including pages for other publishing teams, you must:

  1. remove the page title and URL from the master content map
  2. not delete the page from Sitecore

New content authors and contributors

If you are dealing with a task from an author or contributor that you don’t recognise, please:

  1. add them to the ‘Sitecore Web Authors Master List including pages owned’ document with 'tbc' under the email list entry.

These people will then be added to the Web Content Community Hub group.