• Web accessibility training
• Guidelines framework
• Guidelines B: Creating an item of web content using a third-party application

Guidelines B: Creating an item of web content using a third-party application

Content to be uploaded to a University-supported web editing platform

If your website is on a University-supported web editing platform such as T4 or ELE, you should only use applications that are approved for use on that platform. This is to save you doing a lot of work, only to find that the material you've created can't be used.

Each application should have a User Guide to show you how to creat content that is as accessible as possible. It may not be achievable to make it fully accessible, but the guide should advise what needs to be done in those circumstances.

It may also be possible to use a new application or to create bespoke content in code, as long as the relevant technical team has approved this, and the instructions below are followed.

Content to be uploaded to a stand-alone or third-party website

This includes situations where you may be creating content to be uploaded to a partner's site (i.e. a site maintained by another organisation) in a working collaboration.

In all situations involving uploading to stand-alone or third-party sites, there are three aspects to consider:

1. It's recommended that when creating your content you don't use an application unless it's been approved for the creation of University web content, as it may be very difficult to make that content accessibility-compliant.
2. If you're quite new to web editing, you also need to be aware that not all file types can be viewed online.
3. There may also be limitations on the types of file that can be uploaded to the site where you intend to publish your content so, if you're unsure, it's worth checking with them before you spend time creating it.
4. It's worth checking whether some or all of the content to be developed falls under regulatory exemptions.

Special arrangements for live-streamed content

If the content being delivered is live-streamed audio or video, there are potential implications for the site owner after the third-party is no longer involved, as follows:

1. Live-streamed audio and video is exempt from web accessibility compliance at the point at which it is streamed, but it should then be made accessible within 14 days of broadcast or, if this can't be done within 14 days, removed from the website until it is compliant.
2. If it is to remain on the website prior to the 14 day limit, during this time it should be accompanied by a simple notice stating:
   • that work to make the content accessibility-compliant is in progress
   • the date by which this work should be completed
   • who to contact if a transcript is needed before that date.
3. The Equality Act 2010 applies to recently broadcast live-streamed content. This means that an alternative version of a recently broadcast livestream may be requested in formats other than a straightforward transcript (e.g. braille). This alternative version should be supplied if the recording of the livestream remains online and complying with the request constitutes a reasonable adjustment.
4. Where there is intention to broadcast live-streamed content from a website, the accessibility statement of that site needs to state that it contains, or may contain, live-streamed content, and that this type of content is exempt from accessibility compliance. The responsibility for amending the statement depends on the location of the website:
   • for the website of a University-supported web-editing platform, the technical team that maintain the platform will be responsible for the relevant statement. For this reason, if the statement doesn't already have this information, the relevant technical team should be consulted prior to the introduction of livestreamed content on their platform.
   • for a stand-alone website, the site owner will be responsible for updating the accessibility statement.
   • for a third-party website, the site owner will be responsible for updating any accessibility statement which may exist, and no action is required of the University in this respect.

Assessing your content (excluding live-streaming)

1. With the exception of exempt content, the accessibility of the finished product must be assessed for compliance with WCAG 2.2 to level AA. Some apps have accessibility checkers within them, and although attending to these is usually recommended and useful, passing those checks does not necessarily mean that the product is fully compliant with the required regulatory standard (an app may have documentation detailing the limitations of its checks in this respect). Scanning software designed for regulatory requirements should be used, in addition to manual checks.

   Many applications can't produce fully compliant content. If you're using an application with a User Guide, it should advise you if this is the case for that application.

2. With the exception of live-streamed audio and video, non-compliant aspects should be remedied before the content is published. Where this is technologically impossible (perhaps due to app or coding limitations) a plan should be put in place to periodically review the content to see if these obstacles have been resolved by new developments (e.g. an upgrade to the application used to create the content). In this situation, further steps for non-compliant content will also need to be followed.
3. Edits to self-contained content effectively mean producing a new version of that content. When a new version is produced, it should be re-assessed for compliance.
4. There should be a plan in place for potential edits as and when accessibility regulations change. The website owner (or designated person) will need to monitor for these changes, and arrange for edits as required.
5. For content uploaded to a third-party website:
   • if the way in which the site displays the content reduces its accessibility, then responsibility for resolving this lies with the third-party, not the University. However, in this situation the page hosting the content should offer one of the following:
     • a compliant alternative (often made available via a link)
       or
     • contact details where an accessible alternative can be requested.
   • some websites offer specific tools to make content more accessible on their site, and these should be used where appropriate.
   • third-party websites should have their accessibility compliance taken into account when they are selected to host University-created content.
   • the University is not responsible for the accessibility statements of third-party websites.
6. Even where content is fully compliant, an alternative version (e.g. braille) can still be requested under the Equality Act, and this alternative must be supplied, even if the content is hosted on a third-party website, if doing so constitutes a reasonable adjustment. Staff handling requests for alternative versions should be made aware of this.

Further steps for non-compliant content

In all cases

1. The page hosting the content should offer one of the following:
   
   • an accessibility-compliant alternative, which is usually accessed via a link on the page
     or
   • contact details where an accessibility-compliant alternative can be requested.
2. You should also periodically review to see if the issue preventing the content from compliance has been resolved (e.g. with an upgrade of the application used to create it) and, when this is the case:
   • the content will need to be re-edited to achieve compliance and then re-uploaded,
   • any accessibility statements for affected sites will then need to be amended accordingly.

If publishing on a University-supported web-editing platform

The accessibility statement of the site will need to include:

• A list of all non-compliant aspects, in the form of failed WCAG criteria. It's not necessary to detail the specific locations of failed content on the site, only to list all criteria that the site does not fully meet.
• Contact details where an accessibility-compliant alternative can be requested.

The technical team maintaining the platform will be responsible for the relevant accessibility statement. For this reason, they must be consulted prior to the production of content in bespoke code, or in an application or file type not listed as approved for that platform.

If publishing on a stand-alone website

A stand-alone website is a University site which was created by a third-party without the oversight of one of the University's technical teams.

Standard procedure

1. The accessibility statement for the site must list any non-compliant aspects of that type of content. So, it should name the type of content and then simply list the WCAG criteria that have been failed within your website for that type. It does not need to detail every specific webpage where that failure occurs.
2. Some applications have their own accessibility statement or information, which will list the accessibility limitations of that application. If so, you should link from the accessibility statement for your website to the app's accessibility information to verify that this is the cause of your content's non-compliance – i.e. that it is a third-party issue beyond your control.
3. If the content is uploaded to multiple sites, and those sites are covered by different statements, steps 2 and 3 must be repeated for each statement.
4. The applicable accessibility statements should also include contact details where accessible alternatives of non-compliant content can be requested.