Here’s what you need to include in order to submit a content request:

1. A list of every URL affected. 

Anything that isn’t included in the original request will be counted as a new request and scheduled in for a future sprint.

2. An explanation of how the information has changed, or why a new piece of content is required.

Include background information, links to source material, evidence of need, and anything else that will help the content designer make a decision on your request. 

You can make suggestions for draft content. Please consider Education Scotland styles when drafting any new text. We will edit content to ensure style and tone match the user need.

3. Dates (where appropriate).

We need to know when things need to be live and why so we can schedule the work.

4. URLs of anything you want us to link to.

Check that links work and plan to review these regularly. Content with broken links shouldn’t make it through our review process. However when time is tight and the workload is heavy, this occasionally happens. You can help us by being clear when links aren’t working.

5. Details of the main stakeholders involved

Digital Scotland Service Manual - Service Manual

There are three things to remember when making a content request in order to make sure it’s completed when you need it, and to the standard you expect.

1. Make your request clear

The quality of a request is important. If it isn’t clear, is long and difficult to understand, or doesn’t state all the changes you require:

• we can’t estimate its size properly, so other work planned in for the sprint doesn’t get done (this leads to disappointment and frustration)
• we may miss something important that you’ve assumed we’ll know about (this leads to disappointment and frustration)
• you may not get the work completed when you need it - we may need to plan the work you haven’t mentioned in for a future sprint (this leads to disappointment and frustration)

What to include in your content request

Here’s what you need to include in order to submit a content request that GDS content designers can act upon:

1. A list of every URL affected. Anything that isn’t included in the original request will be counted as a new request and scheduled in for a future sprint.

2. An explanation of how the facts have changed, or why a new piece of content is required. Include background information, links to source material, evidence of need, and anything else that will help the content designer make a decision on your request. Don’t re-write the text thats currently live on GOV.UK. If it makes it easier for you to explain, you can make suggestions, but don’t expect that we’ll simply paste your suggestion onto the page. We always re-write content in GOV.UK style and tone according to user need.

3. Dates (where appropriate). We need to know when things need to be live and why so we can schedule the work effectively.

4. URLs of anything you want us to link to. And if an external URL (ie not on GOV.UK) isn’t live yet, tell us when it will be. Content with broken links in it shouldn’t make it through our review process to the point that it gets published, but when time is tight and the workload is heavy, this occasionally happens. You can help us by being clear when links aren’t working yet.

2. Use the relevant GOV.UK Support form

This comes into us through Zendesk and allows us to keep a log of all the work that’s been requested, all the communication relating to it, and what state it’s in.

Once the form has been submitted and you have a ticket number, use Zendesk for all communication except fact check comments - fact check has its own process and is logged separately.

3. Submit your content request at the right time

At any one time, we have a great deal of work to complete. This is generated from the various government departments and agencies, the general public, and internally. Our work is organised in order of priority, and the priority shifts from sprint to sprint based on a number of factors.

To make sure your content request is completed when you need it, as a rule of thumb it’s best to give us:

• 1 month’s notice for a quick change on a standard piece of content (a quick answer or a guide)
• 2 months’ notice where the change is more complicated, or involves a calculator or other item requiring input from a developer

We don’t always need this amount of time and will work within your timescales whenever possible. But if you can give us this amount of notice, it makes it easier for us to get the content live when you need it live.

There is no benefit in making the request more than 2 months in advance

Sometimes we get requests for changes that won’t happen for several months.

When we receive content change requests a long way in advance, they’re reviewed and placed in the icebox. They then sit in the icebox and receive no attention until it becomes time to deal with them.

In order to manage our workload, we won’t engage with the requester, have meetings or plan anything to do with the content request before it becomes necessary.

When we receive last-minute content requests we try to accommodate them. The problem is, we receive a lot of content requests, and the items we’re working on in any one sprint need to be delivered in that sprint. If we receive a last-minute content request it places an extra burden on the team - and the team are already working to capacity. This means that, even though a request is urgent, if we receive it last minute, it may have to wait until the following sprint before it gets actioned.

Format for content requests

Please submit your work to the web content team as an accessible Word document. Other documents intended for download, such as PowerPoint presentations, should also be accessible.

Guidance for PowerPoint documents is different to Word and PDF documents. Please review the guidance for creating accessible PowerPoint documents to check your work.

Sprints

The web team work in agile sprints that last one calendar month. This means that we will meet at the start of every month to consider the work that has been requested the month before.

Working in sprints means we can respond quickly to changing priorities. It also means that there’s no need for departments to send through content requests months in advance.

There are 3 things to remember when making a content request in order to make sure it’s completed when you need it, and to the standard you expect.

Make your request clear

The quality of a request is important. If requests are long and difficult to understand it can take us longer to do the work. If your request doesn’t include all the content and changes you need:

• we can’t estimate its size, which puts huge amounts of pressure on the team
• we may miss something important that you think we know about
• you may not get the work completed when you need it
• we may need to plan the work you haven’t mentioned in for a future sprint 

2. Use the web content team request form

This comes into us through 'House on the Hill' and allows us to keep a log of all the work that’s been requested. This helps us to track all the communication relating to it, and what state it’s in. It also means that if a team member is unexpectantly off work, someone else can pick up any urgent actions.

3. Submit your content request at the right time

We have a great deal of work to complete. This is generated from the various government departments and agencies, the general public, and internally. Our work is organised in order of priority, and the priority shifts from sprint to sprint based on a number of factors.

To make sure your content request is completed when you need it, as a rule of thumb it’s best to give us:

• 1 month’s notice for a quick change on a standard piece of content (a quick answer or a guide)
• 2 months’ notice where the change is more complicated, or involves a calculator or other item requiring input from a developer

We don’t always need this amount of time and will work within your timescales whenever possible. But if you can give us this amount of notice, it makes it easier for us to get the content live when you need it live.

There is no benefit in making the request more than 2 months in advance

Sometimes we get requests for changes that won’t happen for several months.

When we receive content change requests a long way in advance, they’re reviewed and placed in the icebox. They then sit in the icebox and receive no attention until it becomes time to deal with them.

In order to manage our workload, we won’t engage with the requester, have meetings or plan anything to do with the content request before it becomes necessary.

When we receive last-minute content requests we try to accommodate them. The problem is, we receive a lot of content requests, and the items we’re working on in any one sprint need to be delivered in that sprint. If we receive a last-minute content request it places an extra burden on the team - and the team are already working to capacity. This means that, even though a request is urgent, if we receive it last minute, it may have to wait until the following sprint before it gets actioned.

How to create accessible content for websites 

Making your website content accessible goes beyond just the words on the page. It also includes things like images, videos, charts, tables or banners, and even the links and buttons people use to take action on the page. 

In this section, we explore how to improve the accessibility of the core aspects of your on-page content. 

Accessible language 

Research suggests that people read between 20 to 28% of the text on a page, so making your content concise and easily “scannable” is important. Here are some tips to bear in mind:

• free online readability testing tools allow you to test the readability of your content and make sure it is accessible to those with lower levels of literacy
• use plain English and refer to the GOV.UK Style Guide for advice on complex words or phrases to avoid
• keep sentences short (25 words or less) 
• free tools like the Google Search Console can identify relevant keywords and genuine queries that are driving the type of traffic you’re trying to attract

Accessible page structure 

Avoid long, complex paragraphs which create intimidating “walls of text” that are challenging for people consuming your content on smartphones and people with cognitive disabilities.

You should also not use bold, italicised or capitalised text to “break up” your content, and instead use proper document structure as explained below to help people easily navigate your page:

• make sure your website has a unique page title that explains clearly what the page is about 
• use headings to create a logical page structure and assist people who use screen readers to navigate content in a consistent, linear way: Heading 1 (or H1) should introduce the content, then use Heading 2 (H2) as headings for a specific section and Heading 3 (H3) as a subsection within a section.
  • The order should be sequential, for example, H1, H2, H3 and not H1, H3, H2.
• do not justify text – it should be left aligned

Accessible links

Any links or URLs you feature on your website need to make sense without the context of surrounding content, such as the rest of the sentence in which the link appears.

A page that features several different links which each say “click here” will be useless to a screen reader user because it gives no indication of what link goes where. Link text should tell users where they’re going and why. 

Good practice to follow to meet legal accessibility standards includes:

• making links stand out from other text by underlining them and using a different colour to other page content (using a 3:1 colour contrast ratio)
• starting with a verb if you’re telling people to do something. For example apply for a passport
• linking directly over the text if you’re linking to information. For example, find out about types of election 

To learn more about formatting link texts, read the GOV.UK content design guidelines. 

Accessible document formats

As a general rule, content being published to websites should be published in HTML by default. It’s important to think about accessibility across the whole of your user journey including any documents you link off to or ask people to download. 

Following this guidance on publishing accessible document formats is a positive step to ensuring your whole user journey is accessible.

PDFs are a format designed to be printed – not to be read on screens – which means they are not responsive and are difficult to open or navigate on mobile devices or using assistive technology. It can be challenging to make them accessible. This blog explains more about why content should be published in HTML, not PDF. 

The use of colour and colour contrast

Colour can be used to add emphasis and to engage, but should not be used in isolation to convey a key message. Relying on colour to convey a message makes the content inaccessible to people who are colour blind.

This example is accessible because it does not rely on colour to convey a key message.