Skip to main content

Web Accessibility Training

Guidelines D: Procuring a third-party application to produce items of web content

Advisory

In this context, 'item of web content' means a self-contained element, such as a document or video, to be uploaded or embedded into a website. It does not refer to content created within a web editing platform, such as page text, tables and links.

These guidelines do not constitute a formal regulatory procedure. They are provided as a framework and broad outline of the steps needed to achieve regulatory compliance for accessibility.

Database-driven applications

These guidelines do not apply if you're procuring a third-party database-driven application to create items of web content, and the application itself is in any way customisable. Customisable, in this context, means that it's possible to do one or more of the following:

  • alter the database structure
  • alter the data-entry interface
  • add or alter the data in the database
  • write custom APIs to extract data from the database and display it on a webpage
  • create bespoke templates to display the data on a webpage.

If any of these apply, then please refer instead to Guidelines C. If, on the other hand, the only customisable element is the code embedded in a webpage to display the application's content (or if there is no customisable element at all) then please continue with the Guidelines on this page.

A note about maps

Maps require special consideration, so if you're working with these please email the Digital Team at digitalteam@exeter.ac.uk for advice.

Basic steps

  1. It's worth checking whether the content to be created is exempt from regulatory compliance with the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 (PSBAR). In practice, new content created in-house is very unlikely to be exempt, unless it constitutes livestreamed media or certain online reproductions of items in heritage collections.
  2. The application should be considered in terms of its ability to produce content that fulfills web accessibility requirements:
    1. It's firstly worth checking whether the University already has access (free or licenced) to an application that can produce the required file type. In some circumstances it may be useful to acquire another application for the same purpose (e.g. for added functionality or preferable licensing arrangements). In this situation, however, the new application should not produce content that is less accessibility-compliant than content produced using the existing application.
    2. If the new application is to replace an existing application, it is a priority that the accessibility features of content created using the old application can still be edited on the new application. Where this is not an option (e.g. the old application has been discontinued), content created using the old application will eventually need to be re-created or deleted, so clearly this situation is to be avoided whenever possible.
    3. Where there is a choice of new application, and all other considerations are equal, select the more accessibility-compliant option. The supplier may have information pertaining to the compliance of their product, which will usually list any known limitations. In some cases it may not currently be possible to find an application which produces the required type of content in a fully compliant form, but the objective is the optimal available solution.
  3. A User Guide should be produced for those using the application to create web content, explaining how to make that content web-accessibility compliant, or as compliant as it can be when using an application with inherent limitations.

    The Guide should include the advisory that, 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.

  4. If the application is used to deliver live-streamed audio or video, the User Guide should include the following information:
    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. if the livestream is uploaded to a third-party site, and the way in which the site displays the livestream reduces its accessibility, then responsibility for resolving this lies with the third-party, not the University. However:
      • third-party sites should be selected on their ability to present content in an accessible way.
      • some websites offer specific tools to make content more accessible on their site, and these should be used where appropriate.
      • the University remains responsible for supplying an accessible alternative on request. In this situation, where the content is not compliant:
        • supplying a compliant alternative is required by law and is therefore automatically a reasonable adjustment in all cases.
        • supplying an alternative version beyond that which is simply compliant (e.g. braille) does still need to constitute a reasonable adjustment.
    5. 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 a new application to create 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 the accessibility statement, but in this situation there may not be a statement (again, the site owner is responsible for determining if a statement is required), and no action is required of the University in this respect.

Additional steps if the application produces content that is not fully compliant (excluding live-streamed audio or video)

These steps:

  • only apply in situations where the application itself is incapable of producing fully compliant content.
  • are not to be used as an alternative to making the content as compliant as it can be, and the User Guide should make this clear.
  1. The User Guide should include the following information:
    1. online publishing of content produced with this application means that:
      • a compliant alternative can be requested by any web visitor
      • this alternative must be either made ready ahead of time, or at the point of the request, which may mean at very short notice. This should be understood before time is spent creating the content, as it may be a better use of resource to create it using another method.
    2. what the compliant alternatives are and, if appropriate, how to create them. It may be the case that the compliant alternative can't deliver all of the features of an original made using the application – the User Guide should advise that this is acceptable, as long as the essential meaning and message of the original content is delivered via the alternative.
    3. all known potential compliance limitations of content produced by the application in the form of failed WCAG criteria (as these will be needed by those needing to complete step iv).
    4. if the content is to be uploaded to a stand-alone website, the limitations in step iii need to be listed, in the form of failed WCAG criteria, on the accessibility statement of the site containing the content. The site owner will be responsible for updating the accessibility statement.

      (For content uploaded to other types of website, see step 2. Those types of sites do not need any action by end users, so that information does not need to be included in the User Guide.)

    5. for content uploaded to a third-party website:
      • the University is not responsible for non-compliant alterations to the content, or the way it is displayed, that are made by the third-party website after the content has been uploaded. For example, on a third-party video site where you have uploaded a video, you may have no control over how the site displays that video, but the video itself should be as compliant as it can be prior to upload.
      • 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.
    6. the webpage containing the non-compliant content (whether it is a University site or a third-party site) should include one of the following:
      • a compliant alternative (often made available via a link)
        or
      • contact details where an accessible alternative can be requested.
    7. as and when the limitations of the application are resolved and as soon as it is practical to do so:
      • the content will need to be re-edited to achieve compliance and then re-uploaded,
      • any accessibility statements for affected stand-alone sites will then need to be amended accordingly.
      There should also be an indication as to how editors will be notified of this change.
  2. If the non-compliant content could be uploaded to websites on a University-supported web-editing platform, then the technical team maintaining that platform will be responsible for the relevant accessibility statement, so no instruction on this is needed in the User Guide. For this reason, however, the relevant technical team must be consulted prior to the procurement of a new application intended to create content for a supported platform, if that content will be in a file type not already listed as approved for that platform.

    Purely for information: if the non-compliant content is to be uploaded to a third-party website the site owner (not the University) is responsible for updating any accessibility statement that may be required.

  3. The non-compliant aspects should be:
    1. raised with the supplier to request a solution, if the limitation is not a commonly known issue.
    2. periodically reviewed until a solution is found.
  4. When a solution is found for non-compliant aspects of the content (e.g. the application receives an upgrade) then:
    1. the User Guide should be updated.
    2. a communication should be issued to web editors, advising that:
      • all non-compliant content that falls within regulatory scope, and which can now be made compliant due to the change to the application, should be edited and re-uploaded as soon as it is practical to do so. This includes content uploaded to third-party sites.
      • relevant accessibility statements will then need to be amended when this has been done. For established University web editing platforms, this will be the responsibility of the technical team managing the platform, and for stand-alone sites it will be the responsibility of the site owner. When a statement covers multiple sites, the team may need to issue a deadline to web editors when this work should be completed by, so that the covering statement can then be amended.