• Web accessibility training
• Guidelines framework
• Guidelines C: Working with databases and database-driven content

Guidelines C: Databases and database-driven web content

Are you on the right page?

These guidelines do not apply to personal offline database projects that will only be used by the person creating them – you don't need to consider accessibility in that context.

Likewise, if your task is simply:

• entering data into a database using a data entry screen (not importing data)
  or
• adding a line of code to a webpage to display data from a database,

then there should be a User Guide specifically for that purpose and in these cases you should refer to that Guide – the guidelines here do not apply to your situation. If you don't have a User Guide, please contact the team who gave you editing access to the database or, for web editing, please contact the team responsible for your web editing platform.

Apart from the exceptions above, these guidelines cover the following scenarios:

• Creating a database (online or offline).
• Designing or altering a data-entry interface (online or offline) for a database.
• Overseeing staff entering data into a database if that data will later be extracted to be displayed on a webpage.
• Importing data into a database if that data will later be extracted to be displayed on a webpage, or aquiring a data set for that purpose.
• Writing or amending an API to extract data from a database to display as a feed on a webpage.
• Creating or amending a template that displays data, extracted from a database, on a webpage.
• Commissioning third parties to undertake any of the above.
• Procuring a third-party database-driven application to create items of web content, if 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 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 refer to Guidelines D.

The other scenarios have been amalgamated here, because there's a lot of potential overlap between them, depending on the project. This means that even though the guidelines below are extensive, they will not all apply to every situation, so you'll only need to follow the instructions appropriate to your particular task.

Getting started: an overview of the elements to consider

An application of this kind has five elements where web accessibility is relevant:

1. the database structure
2. the data-entry interface
3. the data
4. any api that extracts the data
5. the way that the data is displayed on webpages

Your task may only involve one of these, but if you're working with two or more (such as when creating or procuring a new system), then you should consider each one separately. This is because the display location, design, code, staffing – and potentially even applicable legislation and regulatory requirements – will be different for each one, even though they're all part of the same overall system.

That being said, the elements are not mutually exclusive, in that the standard of execution for each one will have a consequential, cascading impact on the others:

• element 1 has an impact on the achievable quality of elements 2, 3 and 4.
• element 2 is largely independent, but can affect the quality of element 3.
• elements 3 and 4 have an impact on the achievable quality of element 5.

So even if you're only working on one element, it's still important to be aware of the implications of your decisions for subsequent elements, as well as the restrictions on what will be achievable, depending on the quality of the pre-existing material you're working with. This is something to particularly bear in mind if you're working on a partnership project with another organisation, where each of you is responsible for a different aspect.

The fact that there are five separate areas also highlights why it's important to be clear which aspect you're referring to in discussions about database-related web accessibility, as otherwise it's very easy to communicate at cross-purposes.

Element 1: Structuring a database with accessibility in mind

When designing the database structure, there's only one factor to consider as far as accessibility is concerned: it's important to follow good design principles when normalising the data. The reasons for this are explained, as follows.

Accessible data entry

Even if your database and its data will only ever be used offline, normalised data enables the design of an accessible data-entry user interface. Normalisation makes it easier to design data-entry forms that are logical, consistent, streamlined and error-resistant, and to write clear instructions for them, all of which facilitates accessibility and improves the quality of the data.

Databases holding data to be presented online

If the data in your database will later be used in online web feeds of any kind, whether embedded in a webpage or utlised by an online application, good normalisation will make it easier for web designers to create data-feed web templates that are accessibility compliant.

It may be difficult or impossible for a web designer to do this if elements of data, that should be separate, have been amalgamated into a single field. In such cases, the failure will need to be listed on the published accessibility statement for that website until it can be remedied. This can be for some considerable time, if the underlying problem is a data structure that's difficult to alter.

Working with stakeholders

In general, if good standard design principles are being followed, there's nothing additional or out of the ordinary that a database designer needs to consider for accessibility in the structure of the database. This point is emphasised here, though, because it adds a layer of importance in keeping to these principles.

There should be robust discussions around where data may need to be split, especially if those creating the database are not familiar with using the data as end users.

Database designers will know that it can be very challenging and prohibitively costly to retrospectively address, or create workarounds for, problems caused by data that hasn't been sufficiently normalised.

Stakeholders without technical database backgrounds, howevever, may need to be made sufficiently aware of this, before they can understand and support the decisions made about the data structure, and the potential data management protocols and processes that the structure will require.

Working with third parties

If you're procuring a third-party database or database-driven system, or commissioning a third-party to create a database, there should be discussion of the points above, as relevant.

In the case of commissioned databases, a third-party's understanding of and ability to implement data normalisation should be taken into account when determining their suitability for the project.

In the case of procured databases and database systems, the system may have inherent non-negotiable limitations with regard to data normalisation. Where this is the case, these details should be documented, so that this information can be shared, if applicable, with those designing data-entry interfaces, writing associated api and/or creating web templates to display the data.

The purpose of this documentation is to enable those colleagues to understand what is achievable. In the case of web templates, it also means that the web designer will be able to advise others if certain aspects can't be made accessibility compliant due to database limitations outside our control, as this information will need to be included on the accessibility statement of any affected website.

Element 2: The accessibility of the data-entry interface

Achieving compliance

Designing an online data-entry interface

If data is entered using an online interface, then that interface must be compliant with the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 (also known as PSBAR), even if that interface is only used by staff who access it via a login, and possibly only on campus.

Designing an offline data-entry interface

If data is entered using an interface that is never online, and only accessible via a closed offline network, then it doesn't fall under the remit of PSBAR. However, it will still be covered by the Equality Act 2010.

The Equality Act requires institutions to make reasonable adjustments to ensure that systems are accessible to people with disabilities. If the data-entry interface operates solely via an offline network, it's recommended that compliance with WCAG 2.2 to level AA, or an approximation of it (depending on the code of the system), is implemented as far as possible. This is because:

1. many challenges that disabled people may experience when using the data-entry interface can be reasonably foreseen (by referencing WCAG 2.2).
2. there is inherent difficulty in retrospectively addressing these issues, should they be raised after the system has been built and is in active use. A defence that those issues couldn't have been foreseen may not be valid, because of point i.

This is so that these aspects are not inadvertently overwritten by later updates to the system, especially if this happens some considerable time later, or after staff changes.

Working with third parties

If you're procuring a third-party data-entry interface, or commissioning a third-party to create one, there should be discussion of the points above, as relevant.

Commissioned interfaces

In the case of a commissioned interface, the third-party's understanding of and ability to create a compliant product should be taken into account when determining their suitability for the project. For online interfaces, the level to which they can assist with its intial accessibility statement is also relevant.

Procured interfaces

In the case of procured interfaces, the product may have inherent non-negotiable aspects which are not compliant with accessibility regulations, but the objective is the optimum available product. If the interface is to be used online, these limitations will need to be included in the product's accessibility statement until they can be remedied.

It's worth checking whether the supplier already has an accessibility statement for the product which can be linked to, obviating the need to create a new one. This is less likely to be possible, however, for interfaces that can be customised, as alterations may affect compliance.

Maintaining compliance

If the interface is altered, it will need to be reassessed for compliance at that point.

It should also be recognised that when regulations are updated (for PSBAR, this is around once every 5 years), the interface will need to be reviewed. At this point it may require amendments, and for online interfaces it's likely that the accessibility statement will need to be revised. Provision should be made for monitoring for regulatory change, as well as implementing those changes.

Element 3: Entering data with web accessibility in mind

Training for data entry

A User Guide should be created for those entering data, to ensure that the data is entered in a format that will be accessibility compliant when it's later passed to a feed and displayed by web templates. For example, there may need to be care over copying and pasting pre-formatted text into a content editing window, so as not to inadvertently embed underlying code from the program the text was copied from.

Acquiring a set of data to import into a database

As with data entry, it's important that the imported data is suitable for displaying on a webpage, if it will later be extracted for that purpose. This means the data must not have any formatting code that isn't web compatible.

Quality control

A member of staff or team should be given the role of overseeing quality control of the data in this respect. They will be the primary contact for colleagues in the event of an accessibility-related data-entry error, and on receiving such a notification, will then either correct the data or delegate the task as appropriate. They may also follow up with data-entry colleagues or update the User Guide if necessary, to help prevent future errors.

Element 4: Writing a database API for a web feed, with accessibility in mind

When writing an API for a web feed, it's helpful to maintain the option of granular access to database fields. It can be difficult or impossible for a web designer to create a web template that's accessibility compliant if certain fields can only be returned in an amalgamated format.

That being said, it may still be useful to provide some amalgamated options, as long as the granular alternative is also available.

For this reason, the API documentation should list all the fields and their function, providing the web designer with the flexibilty they need to create templates that meet regulatory requirements.

Working with third parties on database APIs for web feeds

If you're procuring a third-party web feed API or commissioning a third-party to create one, there should be discussion of the points above, as relevant.

In the case of commissioned APIs, the third-party's understanding of and ability to deliver the requirements should be taken into account when determining their suitability for the project. It should be borne in mind, however, that the ideal outcome may not be possible due to the structure of the database they're working with.

APIs with compliance limitations

Documentation

An API may have a limited level of granularity if:

• it's created for a database with insufficient data normalisation, and the structure of that database is either outside our control or, for in-house databases, can't be altered in the short term.
• it's a third-party API with inherent uncustomizable limitations.

In either of these cases, these limitations should be documented, so that this information can be shared with those referencing the API to create data display web templates.

The purpose of this documentation is to enable web designers to understand what's achievable. It will also enable them to advise others if certain aspects can't be made accessibility compliant due to issues outside our control, as this information will need to be included on the accessibility statement of any affected website.

Resolving limitations

In all cases, even though the limitation may be noted on the relevant accessibility statements, this doesn't mean that the issue can then be forgotten:

• for in-house databases, a plan should be developed to resolve the issue. The timeline of this plan will depend on the degree to which it's affecting current websites and/or the practicality of any workarounds in place to deal with it. The role with responsibility for this is the owner of the database, not the API designer, although as a stakeholder the designer should be kept informed of progress.
• for third-party limitations, there should be communication with the supplier to see if anything can be done, followed by checks at periodic intervals, to see if the issue has been resolved (as might be the case with a system upgrade, for example). The API designer is best placed to carry out these checks, as they will fully understand the issues involved.

When the issue is resolved, the API designer can then amend their templates, and notify their own stakeholders that the compliance failure can be removed from relevant accessibility statements.

Element 5: Creating an embeddable, accessibility-compliant template to display a data feed

Any feed of data extracted from a database and displayed on a webpage, must be compliant with PSBAR, whether those pages are public or part of an intranet behind a login. This means the feed must be compliant with WCAG 2.2 to level AA.

Basic steps

1. Consider how the template will be used within the page(s) that will embed it. If the template's position within the destination page structure may vary from page to page, it may not be a good idea to include headings within the template. The correct level for any headings will depend on their position on the destination page, and the web designer won't be able to alter these unless you make special arrangements.

   So if your template does include headings, the template will need to be used in one of the following ways:

   • in a fixed position on the page every time. This will not be feasible in some contexts, but if it is a workable solution, the accompanying User Guide should make clear how it should be used.
   • in a feed that occupies the entire page content.
   • delivered with query code that includes a mechanism for altering the heading level.

   If headings are needed between dynamic elements of a template, and that template is to be embedded in a page among other content, it may be more appropriate to split the template into two or more feeds without headings, so that the web designer can then add the correct level headings as needed. Please note that changing heading tags to paragraph tags (whether the text is styled as a heading or not) is not a compliant solution to this issue.

2. A User Guide should be created for those embedding the feed into webpages using query code. This User Guide may be as simple as a single paragraph, especially in cases where the query only has one parameter.

   It should state:

   • what information is retrieved by each parameter.
   • which parameters are compulsory.
   • in the case of multiple parameters, which combination(s) of these can be used together.

   It may also be useful to include:

   • an explanation of any messages that the query returns in place of data. For example, in cases of:
     • no data found
     • a confirmation message
     • an error-catching message
   • common query typos and mistakes (e.g. missing compulsory parameter) with their resulting errors, so that editors can troubleshoot their own failed queries.

   It should also explain how to embed the feed in an accessible way (e.g. if it needs to be given a heading, to ensure that it's at an appropriate level in the page structure).

3. If the template will be used to deliver live-streamed audio or video, the User Guide should include the following information:

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

     (Please note that, in this scenario, the audio or video is – effectively – the 'data'. While here the data itself doesn't need to be compliant at the point of streaming, the template containing it does need to be compliant. It is only the audio or video itself that is exempt, so you will still need to proceed with the later steps in these Guidelines for your template.)

   • if the audio/video 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.
   • 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 the request constitutes a reasonable adjustment.
   • where there is intention to broadcast live-streamed content from a website, the accessibility statement of that site needs to state that the website contains, or may contain, live-streamed content, and that this type of content is exempt from accessibility compliance. The responsibility for this is as follows:
     • for the website of a University-supported web-editing platform, the technical team that maintain the platform will be responsible for the relevant statement. If the existing statement doesn't already include reference to livestreamed content, the relevant team should be notified of this intention prior to broadcast, so that they can update the statement accordingly.
     • If the content is to be uploaded to a stand-alone website, the site owner will be responsible for updating the accessibility statement.

4. The template must be assessed for compliance with WCAG 2.2 to level AA, using a rendered instance of the data feed(s) as would be displayed on a live page. This will require web accessibility scanning software and manual checks.

   As displayed feed results can vary depending on the database query, a fully comprehensive review would involve one test for each possible permitted combination of query parameters (as defined in the User Guide). For example, if the query has 3 possible parameters: a, b and c – but b is not permitted to be used alone – then the combinations to test would be:

   • a
   • c
   • a + b
   • b + c
   • a + c
   • a + b + c

   Each parameter test value should be selected to return a complete set of data for that parameter. If this is not possible, then the test for that parameter should be conducted with different values until all data fields have been checked when populated with data.

   In cases where the rendered view template is correct but there is a fault in the displayed data due to non-compliance in the data source, then this test will still pass because here it is the view template that's being tested, not the data it contains. The incorrect data, however, should still be flagged to the appropriate contact, unless:

   • it takes the form of audio or video streamed within the previous 14 days (as this is covered in the previous step)
     or
   • it is an exempt online reproduction of an item in a heritage collection.
5. Under certain circumstances the feed may return messages in place of data, such as in cases of no data found, a confirmation message or an error message. A compliance test of each of these messages should be conducted.
6. Whenever possible, non-compliant aspects should be made compliant before the feed goes live. This is not only best practice, but will make feed management more straightforward, because additional steps will be needed for non-compliant view templates once they are live.
7. A plan should be put in place to periodically re-assess for compliance if edits are to be made to any of the following:

   • the data structure or database field names
   • the data
   • the API
   • the query code
   • the view template (in terms of structure, static content or styling)

   A point of contact should be established for each of these, so that they can be notified of any errors found, and it's uncommon for all five aspects to be maintained by one person or team. Typically, the data structure and api are handled by a database developer, the data is handled by data entry staff, the view template by a web developer, and the query code by a web editor.

8. Provision should be made for monitoring for regulatory change, as well as re-assessment and potential edits, if needed, as a result of those changes.

Additional steps if the rendered view template is not fully compliant

1. When the template is added to a University website, it must be considered as part of the accessibility statement for that site, and any non-compliant aspects must be listed on the statement in the form of failed WCAG criteria.
2. If the content is uploaded to multiple sites, and those sites are covered by different statements, then step 1 must be repeated for each statement.
3. There should be a plan in place to work towards resolving the non-compliant aspects. Where the issue is due to a third-party aspect, there should be communication with the supplier to see if a solution can be found; where this is not possible, the matter should be revisted at periodic intervals to see if the situation has changed (as may be the case with a system upgrade, for example).
4. While the template is non-compliant, all pages hosting it 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.
5. The applicable accessibility statement(s) should also include contact details where accessible alternatives of non-compliant content can be requested.
6. Once the non-compliant aspects have been resolved, the applicable accessibility statement(s) should be updated. At that point, these additional steps will no longer be necessary.

Commissioned templates

When commissioning a third-party to create a template, they should be made aware of the points above. Their ability to deliver a template in accordance with these points should be considered when determining their suitability for the task.

In the case of a short-term appointment simply to create a template, consideration should be given as to the resource required subsequent to this, to maintain and edit the template, as outlined.