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
A PDF is only as accessible as the document it’s created from. Image-based PDFs that contain a scan of text information are the least accessible. This is because screen readers cannot read the text in images. A screen reader is a piece of software for a blind or visually impaired person. Most screen readers work by having a synthetic voice that reads text aloud.
Any PDFs on the website need to be accessible and optimised for digital use.
Creating accessible PDFs requires specific software, for example, Adobe Acrobat DC.
This software can do several things to make it suitable for assistive technology, including:
- creating tags
- setting the document language
- setting security settings so they don’t interfere with screen readers
- adding bookmarks
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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
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.