We use strictly necessary cookies to make our site work. We would also like to set optional cookies (analytical, functional and YouTube) to enhance and improve our service. You can opt-out of these cookies. By clicking “Accept All Cookies” you can agree to the use of all cookies.

Cookies Statement and Privacy Statement

Accessibility Guidelines - Digital Content

Our content must be accessible to everyone who needs it. This means we need to make sure it can be used by as many people as possible.

This includes people with:

  • impaired vision
  • motor difficulties
  • cognitive impairments or learning disabilities
  • deafness or impaired hearing

Web accessibility and the law

Public sector bodies must ensure their websites and apps are accessible to people with disabilities. This is enforceable in Ireland, by law, through the European Union (Accessibility of Websites and Mobile Applications of Public Sector Bodies) Regulations 2020. Under this law, all content published on our websites has to meet the Web Content Accessibility Guidelines version 2.1 AA standard as a minimum.

Our accessibility guidelines for digital content are based on these standards.

This means the content we publish will meet:

  • the needs of our users
  • accessibility standards
  • our legal obligations

Accessible PDFs

Content on HSE websites must be published as HTML web pages and not in PDF format, where possible. This will mean our content can be used by as many people as possible, including people with disabilities. 

Publishing PDFs on HSE websites

Images

Do not embed text in an image. Screen readers cannot read it.

Use alt text for images

Images can create major barriers when they are not accessible. To be accessible, they must have alt text (text alternative) that describes the information or function represented by them.

Alt text gives people who don’t see an image the same information as if they had. It should not be a literal description of the image. It should explain what point the image is making.

Alt text ensures that images can be used by people with various disabilities, including people:

  • using screen readers - the text alternative can be read aloud or rendered as Braille
  • using speech input software - users can put the focus onto a button or linked image with a single voice command
  • browsing speech-enabled websites - the text alternative can be read aloud

For all alt text, follow the rules for language in this style manual. Be concise, clear and straightforward. Alt text should describe the image and be specific. Use the image's subject and context to guide you.

Do not include 'image of' in your alt text of images as screen readers already identify and communicate this to the user. If the image is of a nurse giving a man the flu jab, a bad example of ALT text would be ‘man getting an injection’. A good example would be ‘Nurse with a syringe giving the flu jab to a man sitting in a chair. The injection is going into his upper arm’.

Groups of images

A group of images may represent a collection of related images. For example, showing a series of exercise positions. In this case, each image needs alt text that describes it individually, as well as its relationship within the group.

Graphs and diagrams

Complex images such as graphs and diagrams convey data or detailed information. For these, provide a full-text equivalent of the data or information provided in the image as the text alternative.

Functional images

We do not include images as buttons as these are not accessible to all users. The only exceptions to this are a logo in a header that brings you back to the home page, for example, the HSE site logo.

Decorative images

We do not publish images for decorative purposes. Images are only added to content pages when a visual presentation of the text is essential to the information being conveyed. For example, a photograph of a particular type of rash or a particular physiotherapy exercise position.

Publishing images

Video and audio

All video and audio controls should be accessible with the keyboard.

Pre-recorded video and audio

All pre-recorded video and audio content must have:

  • captions (subtitles)
  • an audio description - if the audio does not present the necessary visual content

Captions are often called subtitles. They are text versions of speech and other important audio content.

Audio descriptions describe content that is presented only visually, for example, diagrams without a verbal description. They can be included in the main audio track, in another audio track or as a text transcript.

Creating captions for pre-recorded video content

Live video

Captions must be provided for all live audio content in videos. For a speech, they must include dialogue, identify who is speaking and notate sound effects and other significant audio.

Text

Plain language benefits all users, including people:

  • with cognitive disabilities
  • with low reading literacy
  • whose first language is not English
  • who are trying to understand a topic for the first time

Use simple language and formatting with short, clear sentences and paragraphs.

Rules for language

Page titles

A page title helps users find what they want and recognise if they're in the right place. It can be the first thing a screen reader will read out when the user visits a page. They appear in site maps. The title is the text link that appears in search results.

The H1 is the same as the page title. You should have only 1 H1 on a page.

Each page title must be unique and descriptive.

Creating good page titles

Headings and subheadings

Headings should be styled properly using HTML <H> tags. People who use screen readers often use them to navigate. They jump through the list of headings in a document so they can skip to the content they’re looking for.

If you style headings just using bold text, or by using a bigger font, screen readers will not recognise them as headings. This will stop users from skipping straight to the content they need.

Headers should always be nested and consecutive.

Never skip a header level for styling reasons:

  • H1 = title of page
  • H2 = subheadings
  • H3 = sub-subheadings

Creating good headings and subheadings

Directional language

Do not use instructions or any language that prompts the reader to ‘see’ the layout or design of the page. Some users can’t see the spatial relationships between words and objects.

Don’t say things like ‘use the links on the right-hand side’ or ‘see image above’.

Links and buttons

Links or buttons need to make sense out of context because people who use screen readers often scan through lists of links in isolation. They do not have the surrounding context to help them understand what the link is for.

This means it is important that a link should clearly describe where it will take you, for example: Find your nearest emergency department (ED).

Ideally, link text should match the heading of the target page. If the target page has the heading Symptoms of COVID-19, that's good link text.

Using link text like ‘click here’, ‘more information’ or including the link URL address does not meet accessibility standards.

Other languages links

If a web page includes links to versions of the page in other languages, the text of each link should contain the name of the language and be written in that language.

The language of each link should be indicated in a lang attribute.

Creating good links

Tables

Tables should only be used to display data and not to format content. Data tables are used to organise data with a logical relationship in grids. If including data tables, make sure no cells are left empty.

Accessible tables need HTML markup that indicates header cells and data cells and defines their relationship. Assistive technologies use this information to provide context to users.

Tables without structural markup to differentiate and properly link between the header and data cells, create accessibility barriers. With structural markup, screen readers can read the row and column headers as users navigate through the table.

Creating accessible data tables

Colour

Colour should not be used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

Good colour contrast helps people with vision impairment and cognitive impairments to better perceive content on the page.

Non-text contrast

There should be a contrast ratio of at least 3:1 against adjacent colours for visual presentations for:

  • user interface components
  • states (focus, hover, select, press, check, visited or unvisited and expand or collapse)
  • graphical objects

Text contrast

The visual presentation of text and images of text should have a contrast ratio of at least 4.5:1 except for large-scale text and images of large-scale text.

Custom styling (Inline CSS)

Do not use inline Cascading Style Sheets (CSS) for custom styling, for example, custom buttons and fonts on content pages.

Users with visual impairments may have difficulties reading online content and will sometimes use custom style sheets. This allows them to adapt colour and font size to meet their needs.

Inline CSS styles override these custom style sheets causing them to no longer work.

Resources

A-Z of accessibility

Web style guide accessibility site

18F accessibility guide

Web Content Accessibility Guidelines (WCAG)