In August 2018, a new law was passed that means that public sector websites will need to meet accessibility standards so that people who use assistive technology or have additional needs can easily access services and information.

It is extremely important to ensure that your website is as accessible as possible for all users of your website.

With this in mind, we have reviewed the guidelines that have been produced to work towards to ensure that all Haiku sites are compliant with the guidelines, giving the best user experience for all visitors to the sites.

The web team in the Medical Sciences Division at Oxford have also carried out a lot of analysis work and information gathering and dissemination for website editors. The information that they have collated can be found from the links below:

The web team have set up an Accessibility channel on the Haiku Editors Nexus 365 Teams site.

The wiki in the accessibility channel aims to:

  • Share resources on accessibility.

  • Provide information about the new regulations for public sector websites.

  • Link to the WCAG 2.1.

  • Provide an area for the Haiku Community to share experiences and know-how about accessibility and carrying out accessibility audits.

Please note:

  • The information on these pages are suggestions, ideas and links to resources and guidance.

  • The WCAG success criteria are open to interpretation.

  • This is a work in progress.

We have carried out an extensive investigation into the ways that Haiku currently supports the accessibility guidelines, and we have identified some areas where there is either a change in the guidance, or there is new guidance. We have laid out the areas where we need to carry out some changes to Haiku, in order to meet the guidelines. We have noted the action that we will take, and we will update the status of each of these actions using this table. We aim to complete all the improvements by the deadline in September 2020. If you have any questions about the accessibility of your Haiku website, please get in touch with the team through the helpdesk.


Current - CMS related only





Current - CMS related only




Page: Perceivable





1.1.1 Provide a text description for images, and make sure the description serves the same purpose as the image.

Banner images on cover pages take the image title even if the summary has been completed – this is not in line with other images

Check banner images on cover pages, and make sure that they are utilising the ‘alt’ text as they should.


1.3.1 Use elements like headings, lists and tables to properly convey the structure of content.

  1. H2 heading missing on most pages

  2. Some cover page tiles e.g. News and Events have an H3 heading for the title and the items have an H2 heading.

  3. Tables don’t have the table header row.

  1. Check all headings on all pages, tiles and portlets to make sure that they are used appropriately, and in the correct order on the page.

  2. Provide header and footer row for tables.


1.4.3 Make sure that the colour of text contrasts clearly against its background colour.

  1. Text overlay in certain locations lets the editor choose an image and text colour without any warnings for accessibility.

  2. Advanced design option on cover pages allows editors to make displays with bad colour contrast.

  1. Build a tool that will provide all accessibility information required in relation to colours and fonts.

  2. Link to the tool:


1.4.4 Make sure it is possible to complete all tasks when text is resized up to 200% in the browser.

All pages other than cover pages have this layout defined in the system, all pages work well as the content is all built with responsiveness at the forefront.

Ensure that all cover pages can be used and viewed at 200% Zoom. Provide documentation on the use of cover pages.



1.4.11 [NEW] Make sure sight impaired users can see important controls and understand graphics.

Editors need to ensure that the controls on embedded services are compliant.

Provide documentation/information to editors that show the third party supplier information about the accessibility of their product.



1.4.12 [NEW] Make sure users can modify text line height, letter or word spacing.

This is currently done by the user by using browser plugins

Ensure that Haiku sites provide all the information and parameters that the third party software requires to make the site workable.



1.4.13 [NEW] Provide a way to control how people can interact with or dismiss any ‘extra’ content that becomes visible.

Currently, this ‘Extra’ content is limited to pop-ups in editing, as well as image pop-ups, and publication information pop-ups.

Ensure that users can easily dismiss and interact with ‘extra’ content in a manageable way. Ensure that the correct information is in the system to let software identify what the content is and how to deal with it.



Page: Operable





2.1.1 Make sure every task can be completed without a mouse.

Basic tasks are already able to be carried out whilst only using a keyboard.

Ensure that all tasks can be carried out using a keyboard to navigate.



2.1.2 Make sure that keyboard users don’t get stuck when navigating through content.

Basic tasks are already able to be carried out whilst only using a keyboard.

Ensure that all tasks can be carried out using a keyboard to navigate.



2.1.4 [NEW] Provide a way to switch off or remap keyboard shortcuts.

We do not use any specific keyboard shortcuts on the site that would require remapping or turn off.

Ensure that if in the future, any keyboard shortcuts are implemented, that they can be remapped or turned off.



2.2.2 Give people a way to stop content that updates frequently, blinks or scrolls automatically.

Currently only applicable to the carousel functionality. The carousel pauses if you hover your mouse over it.

Add information in the code for a screen reader to be aware that to stop the carousel from moving, the user will need to move their mouse over it. Consider providing additional control for visually impaired users, to stop the carousel from updating.




2.4.1 Give people who do not use a mouse a way to move to the start of the main content.

This is available, partially implemented.

Add ‘Skip to main content’ to the screen so that users are aware of the functionality is working.




2.4.3 Make sure that things receive focus in an order that makes sense.

This currently relates to when content is viewed on anything other than a full-size browser window. The page templates reorder the content for restricted views e.g. mobile.

Review how the templates order the content. e.g. where does the navigation appear when you view a page on a mobile device.



2.4.4 Make sure the purpose of a link is obvious from its link text, or its link text in association with nearby content.

If there are any buttons etc. where there is Read more type of link text that can’t be edited this should be reported to Fry via the helpdesk.  

Locate and review all hardcoded button names, make sure they are done so for a reason, that would not renaming. Need button/icon labels for screen readers with this added functionality. Look into providing context for visually impaired users on all buttons/controls.



2.4.7 Make sure that people using a keyboard to navigate can always see where they are on a page.

Haiku is compliant with this.

Review and change the way that people using a keyboard to navigate the page can always see where they are. Currently quite subtle.



Making users aware that links for external websites that are going to open in a new tab.

Haiku doesn't do this.

Investigate and make an improvement to visually show users if a link will open in a new tab.

In Progress

Page: Understandable





3.2.3 Make sure that ways to find and navigate content (like search) look and behave the same way when they are used in multiple places.

Editors have the ability to place the navigation in multiple locations, dependant on the type of content and or listing.

The look and behaviour of the navigation is always the same if using the system tools. Editors should be careful when manually compiling navigation, to ensure they function in the same way as the automated options available in the system



3.4.4 Give people a way to review and check the information they have entered, and to correct any mistakes they have made.

When a user has filled a form, they are able to review it on the screen, until they select to submit or reset the form. This is much more applicable to shops etc. where further confirmation is required

Investigate the possibility of providing a page where users can double-check the information that they have entered before submitting the form.

This functionality is not required. It can be provided with development work.



Page: Robust





4.1.1 Make sure the code of each page does not contain errors that will have a negative impact on the way browsers and assistive technologies work together.

There should not be any areas that have errors on them that will cause issues.

Check all code to ensure that there are no errors causing negative impacts on the way that browsers and assistive technologies work together.



4.1.2 Make sure the code of each page enables assistive technologies to discover the purpose of every feature, the way that feature is identified, and the state it is currently in.


Check the code of each page enables assistive technologies to discover the purpose of every feature, the way that feature is identified, and the state it is currently in.



4.1.3 [NEW] Make sure status messages are shown in a way that assistive technologies understand without receiving focus.

Currently compliant in all locations except for file and image uploads.

Check on the accessibility of uploading images and files to Haiku sites, to ensure that status messages are shown in a way that assistive technologies understand without receiving focus.


In Progress