Book page

Accessibility guidelines for metadata files

ACCESSIBILITY GUIDELINESS FOR METADATA FILES 

1. Introduction

2. Accessibility topics

 

For service support, please contact:

ESTAT-DATA-METADATA-SERVICES@ec.europa.eu

Last reviewed : 12-12-2024
ESSMH web portal

 

1. Introduction

Accessibility is crucial in ensuring that content is usable by everyone, regardless of their abilities. The aim of accessibility is to provide equal access to information for all individuals, including those with disabilities. When creating metadata files, respecting accessibility guidelines is particularly important, as it enables users to navigate and understand the content more easily. By following these guidelines, content creators (national data providers and Eurostat domain managers) can ensure that their metadata files are perceivable, operable, and understandable by everyone, including those who rely on assistive technologies. This is crucial for promoting inclusivity, equality, and social participation, ultimately benefiting society as a whole.

To achieve these goals, it is necessary to understand the specific accessibility guidelines and requirements that apply to metadata files. The following section outlines the key accessibility topics and guidelines that should be followed when creating a metadata file.

 

2. Accessibility topics

The accessibility guidelines outlined in this section provide the requirements to be respected when writing a metadata file. It is based on the European accessibility act and Eurostat’s accessibility guidelines tailored for the metadata files. To improve usability, the guidelines are structured by topics and tables. “Requirement” guidelines in the first column of the tables provide recommendations on how to solve the identified errors in order to make the document accessible. The second column, called “Quality measures errors and FAQs” provide the errors identified based on the newly implemented ESS-MH features. 

An FAQ page is also available to guide and provide the answers to the most frequently asked questions related to accessibility guidelines. The FAQ link is displayed in the second column, "Quality Measures Errors and FAQs", if available.

 

2.1 Lists

Requirement

Quality measures errors and FAQs

To properly create lists, use the built-in markup tools of your editor. Don’t create fake bullets with hyphens for instance. For ease of reading, we generally

  • limit the text by each bullet point
  • do not capitalise the first letter of each point
  • do not use punctuation such as commas, full stops or semicolons at the end of each Point (unless it’s the final bullet point)
See FAQ.

 

2.2 Formatting

Requirement

Quality measures errors and FAQs

Don’t use text formatting (bold, italic, strikethrough nor any visual styles) to convey key information such as “Items in bold are still available, items in strikethrough are not available anymore”. Screen readers don’t spontaneously mention the visual aspect of text. Instead, use lists – say “The following items are still available:”.See FAQ.
Avoid using italics, except for a term in another language or very short emphasized terms 
Bold font to be used sparingly, of maximum 3-4 words in a sentence, or to emphasize a sub-section of a concept. 
For quotes, please use the following: quote marks, indentation, author cited…See FAQ.
Don't underline anything but linksSee FAQ.
Use Left alignment for the text instead of Justified. Justified text is not allowed.See FAQ.

 

Requirement

Quality measures errors and FAQs

Meaningful link labels - Link labels should tell the user where they will end up when they click on them.

Link label should be more meaningful

See FAQ.

In sentences, avoid links on meaningless terms like “click here”, “here”, “more”, “read more”. Links should be intuitive and meaningful even when extracted from their context.

Link label should be more meaningful

See FAQ.

Avoid links on URLs: rather use the target page title or the website name as link.Link label should be more meaningful
As far as possible, name similarly all links to the same target across a page or website (so that the user knows he already visited that related page from another location). There can be variation due to the different sentence structure (verb instead of name, plural instead of singular…), but keep the links similar.See FAQ.
Links should be underlined to make them easy to identify even with colour-blindness. If a different colour is used for the links, make sure the colour complies with colour contrast rules.See FAQ.
Identify hyperlinks without an attached link (the hyperlink appears as a text). First, because all hyperlinks should be clickable, and second, all hyperlinks, as stated above, should be accompanied by a meaningful name/label.

URL is not linked

See FAQ.
 

The text is blue and underlined, but there is no link attached to it.

There is no link attached

See FAQ.

Don’t TIPS:

  • don't make an article number of a legal document part of the link unless you are anchor-linking to the article.
  • don't underline any links manually or any other text (Links in text are underlined automatically by the web content system.)
  • don’t use ‘Useful links’ as a heading. Why would we give users any other type of links? Choose a heading that tells the reader why the links are useful:
    • other organisations dealing with …
    • legislative documents
    • studies on …
 

 

2.4 Images

Requirement

Quality measures errors and FAQs

Every image should have an appropriate alternative text. See below some tips for creating a good alternative text.

Tips:

  • Appropriate alt text:
  • The text needs to convey the same meaning as the image. That is, if someone cannot see the image, they get the important information from the image in the alternative text.
  • Images that are functional — for example, images that initiate actions (like submit buttons) and linked images (like in navigation) — need alt text that is the functional equivalent.
  • If there is text in the image — for example, in a logo — that text needs to be included in the alt text.

2. What is not needed in the alt text:

  • If the image is not important for understanding the content — for example, it is just decoration or "eye candy" — it should have null alt (alt=""). One way to help determine if an image should have null alt is to ask yourself: If the image was removed, would the user still get all the information from the page?
  • The alternative text does not need to include the words "button", "link", or "image of". (Screen readers automatically provide that information.)
  • If the image is sufficiently described in the text — for example, a simple diagram illustrating what's written in the web page text — it can have brief alt text such as "Diagram of work flow as describe above."

Images without an AltText

See FAQ.

If a complex image (like a chart) has an alternative in the form of one of the following:

  • long textual description below, or
  • a link below to long description in another pages, or
  • a table alternative below,

mention this in the short description of the image (“alt text”), so that blind visitors know where to find an alternative version of the content. For instance, “Milk production trend in EU from 2002 to 2020, see data table below”.

Images without an AltText

See FAQ

For charts, you may include in the alternative description:

  • The trend in the graph
  • The type of chart (at the end of the description as it is purely visual)

Images without an AltText

See FAQ.

For formulas, insert AltText to explain what is behind the formula. If an image contains formulas and text in between, split the image in smaller images in order to keep the text out of the image.

Example:

Example for a formula
See FAQ.

Images should be imported using the ESS-MH Wizard menu, “Insert image” feature:

Example uploading image

Embedded image

See FAQ.

Images should be imported using the ESS-MH Wizard menu, “Insert image” feature:

Example uploading image

Missing ID

See FAQ.

 

2.5 Tables

Requirement

Quality measures errors and FAQs

For simple data tables, make sure the 1st row is properly marked as a header, via the built-in feature of your editorSee FAQ.
For matrix tables that have both a 1st row and 1st column crossing headers, both must be marked as such via the built-in feature of your editorSee FAQ.
If possible, avoid empty cells that make it more complex to get an overall idea of the table structure for blind visitors. Also, do not use “X”, “NA” etc. to mark that the cell has no value. Use “Not applicable”, “Not available”, “No value”, “Unknown” for instance. This can be hidden to sighted readers, for instance by using white font.See FAQ.
Don't use any highlighting. The table should have no colour.See FAQ.
Merged cells to be used in the table headers only, but not inside the table. In the header of the columns/rows it is needed to properly set-up the row and column spans).See FAQ.

 

2.6 Dates format

Requirement

Quality measures errors and FAQs

Write the day as a number and the month in letters - e.g. 12 May. In the metadata files, especially the concept 2. Metadata update is affected. If possible write the dates, instead of 18/12/2012 - replace with 18 December 2012.

Invalid date formats

See FAQ.

 

2.7 Language

Requirement

Quality measures errors and FAQs

Words in another language inside a paragraph will need to get properly marked so that screen readers adapt their pronunciation. This does not apply to foreign terms frequently used in the other language, like “parking”, “design” etc. In ESS-MH we can use quotes (“foreign term”) to mark foreign terms. 

 

2.8 Use of colours

Requirement

Quality measures errors and FAQs

Don’t use any highlighting of the text 
Don’t use any font colour for the text, except for the hyperlinks, that should follow the colour contrast rules. 

 

2.9 Good practices

Requirement

Quality measures errors and FAQs

Apply good practices of web writing such as: short paragraphs and sentences, plain English with no jargon, active voice.