Editor's publishing checklist

Last updated: 2 October 2024

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

When to use 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 share this Quality Control checklist with other publishing teams and editors to use.

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:

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

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

You must keep up to date and regularly return to this checklist.

List of checks for new and amended pages

1. Run the accessibility tools

  • Silktide Accessibility Checker, WAVE and NVDA.
  • Plus others, as appropriate.

2. Is the navigation to the page clear?

  • How does the user get to the page?
  • Check breadcrumb.
  • Go to the level above - is there a clear link to the page?
  • Direct knowledge of the URL, or only through search engines, isn’t good – ideally there should be a navigation route.
  • 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:
    • consult with the content owner for an appropriate title before you change
    • make the title change and let the content owner know when you return the ticket

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. Chang or update of 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.

7. 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.
  • 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.

8. 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.

9. Introductory paragraphs

Only those paragraphs that have a larger font.

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

10. 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 say the format and file size included in the link. 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 (use the name or team name in the URL).
  • Make sure that links do not include the space before or after the link text.
  • Ensure no hidden links are 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.

11. 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.

12. 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.

13. Links that open in a new tab or window

  • Do not open links in a new tab or window. This is disorientating, 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”.

14. 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 commonly used 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

  • No sentences and paragraphs in block caps.

Colour

  • Not used for meaning or emphasis.

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 ‘Links’ and ‘Links that open in a new window or tab’.

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

  • Only hyperlinks should be underlined.

15. 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. 
  • Twitter – when linking to an X account, use the phrase ‘X (previously known as Twitter), not just ‘X’ on its own, because this is not accessible.

16. Images

  • Right sizes for desktop and mobile?
  • Use an alt tag only if:
    • the image has contextual meaning
    • description is not in body text

17. 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.

18. 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 header row with capitalised headings
    • its width set to 100% (not pixels) – this allows the table to adjust and fit in the screen width of the device it is being viewed on
    • a descriptive table summary in the properties
    • more rows than columns
    • the most important information first – users will tire of scrolling through a long list to find what they want
    • concise and clear information in the cells
    • not too many rows – if the table is so large that the column headings are scrolling off the screen, then consider if the table is the right format
    • a brief description immediately before or after the table in the body text

19. 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, where appropriate, front-loaded.

20. 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.
  • Key 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.

21. 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.

22. 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.

23. 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.

24. 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
  • that the page or component is unlocked in Sitecore
  • review the page on the live website and revisit any issues still in place

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 the edited link will alter 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.

Log of updates