Accessibility statement

Objective of the City of Helsinki

With regard to the accessibility of its digital services, the City of Helsinki’s objective is to achieve the AA level or higher, as defined in the Web Content Accessibility Guidelines (WCAG).

State of the Hel.fi service’s accessibility

This website complies with the statutory accessibility requirements at the AA level of WCAG 2.1 but includes the following shortcomings.

Non-accessible content, observed shortcomings

The content specified below does not meet all statutory accessibility requirements.

Across the entire site

• In the mobile view of the web site, search and navigation menus are provided in the banner section as expandable buttons. When the buttons are expanded, their accessible names become truncated and only read “Close,” that is, they no longer describe which function they will close. WCAG 1.1.1 Non-text Content (A)
• The Hel.fi jump-to-content link points at an empty anchor tag in the main content of the page, which may result in an unusual behavior on some screen readers.
• Some news and article pages have a section titled “More on the same topic,” which hosts a number of social media links. The links are rendered with insufficient contrast when focused with keyboard or mouse. WCAG 1.4.11 Non-text Contrast (AA)
• Many pages offer a feedback mechanism titled “Did you find what you were looking for on this page?” There are two accessibility issues with this feature:
  • If any one of the feedback buttons is selected with a keyboard, the entire button group becomes inaccessible for keyboard users, in consequence of which the selection can no longer be undone even though this should be possible. WCAG 2.1.1 Keyboard (A)
  • The buttons also fail to describe to assistive technology whether they are selected or unselected, as their status is only displayed visually. WCAG 4.1.2 Name, Role, Value (AA)
• When search results or other compositions are spread out to multiple pages, there is navigation mechanism by which one can move to a specific page number of jump back and forth between pages. The navigation links will not describe to assistive technology users which page number represents the current, open page. WCAG 4.1.2 Name, Role, Value (AA)
• Headings are missing for assistive technology in a number of repeating sections:
  • “On this page” links with text blurbs
  • “More on the same topic” sections on landing pages and article pages
  • Numbered lists of titled activities, available on many pages that guide users on how to complete various procedures with the city
  • Individual missing headings are found here and there, often with the text

  • styled only visually but not technically as a heading

    WCAG 1.3.1 Information and Relationships (A)

• Hel.fi main page and “What’s new” pages provide links as a list of clickable cards that host an image and a heading link. For assistive technology users, the reading order of the card is incorrect, as the image precedes the heading of each card. WCAG 1.3.2 Meaningful Sequence (A)
• The web pages of some of the City of Helsinki’s service units (daycare centres, schools, general upper secondary schools) show the service unit’s name in a language other than the language used on the pages. An accessible name may be conveyed to assistive technology in the wrong language. (WCAG 3.1.2 Language of Parts)

Chat applications

Watson-chat (chat-bot and human interaction)

• All the chat contents are marked as English for users of assistive technology irrespective of the actual page language. This may render the chat controls and messages illegible for users whose screen reader is set to use a non-English synthesizer. WCAG 3.1.2 Language of Parts (AA)
• The chat window is incorrectly defined as an application rather than normal web content. For this reason, users of some screen readers, such as NVDA, will have to enter the chat window by using the screen reader’s forms mode or by asking NVDA to jump directly into the next control inside the chat. WCAG 1.3.1 Information and Relationships (A)
• A number of the chat controls suffer from accessibility issues, namely:
  • Buttons at the beginning (the top-end banner area) of the chat window are missing accessible names. The dialog that is used to close the chat is also missing an accessible name. WCAG 4.1.2 Name, Role, Value (A)
  • Moreover, there is a vague “close” button within the dialog that will not close the chat but only the dialog itself.
  • Finally, there is an extraneous button role definition in buttons that are used for giving feedback, which may cause a screen reader to describe them in an unusual manner.
• The message list will not describe for assistive technology users who the sender for each message is, even though this is shown visually. WCAG 1.3.1 Information and Relationships (A)
• There are also some poor color contrasts used within the chat window (WCAG 1.4.11 Non-text Contrast):
  • The message input field is difficult to discern
  • There is no keyboard focus indicator on the message list or the disabled send button.

Telia ACE -chat (human interaction)

• There are English names and descriptions in the chat even when the web page language is set to other. WCAG 2.4.6 Headings and Labels (AA)
• The button that opens the chat window is incorrectly defined as a region rather than an expandable button for assistive technology. WCAG 1.3.1 Information and Relationships (A)
• The chat window contains unusual semantical structures that some assistive technologies may expose. These include, amongst other things, unnecessary form controls and multiple H1 headings. WCAG 1.3.1 Information and Relationships (A)
• The message send button vacillates between active and disabled states, but this status is not passed on to assistive technology. WCAG 4.1.2 Name, Role, Value (A)
• There are also some poor color contrasts used within the chat window (WCAG 1.4.11 Non-text Contrast): For instance, the send message button may be difficult to discern.
• When the other party is typing a message, there is a visual, animated notification, but no matching indication for non-visual users. WCAG 4.1.3 Status Messages (AA)

Site search

• The search page is missing a standard “jump-to-content” link with which keyboard and screen reader users can quickly access the page main content.
• Some search results may contain a link whose accessible name is missing the link text itself and only reads “link leads to an external service.” WCAG 2.4.4 Link Purpose (In Context) (A)
• The checkboxes grouped under the title “Limit results” are not marked as a named group for assistive technology users. WCAG 1.3.1 Information and Relationships (A)

Embedded videos

• The web site uses embedded YouTube video players and content. Depending on the video material, some YouTube labels or controls that are displayed on top of the video may suffer from poor contrast. WCAG 1.4.3 Contrast (Minimum)
• Some of the video players on the web site use controls that are incorrectly named in English for assistive technology users irrespective of the page language. WCAG 1.1.1 Non-text Content (A)
• Some videos are missing subtitles for the spoken audio track. WCAG 1.2.2 Captions (Prerecorded) (A)

Embedded maps

• The maps used throughout the service present poor legibility for users who struggle to visually discern colour hues or low contrast texts and graphics. Moreover, some interactive elements displayed on top of the maps fail to show a clear keyboard focus indicator. WCAG 1.4.1 use of color (A), 1.4.11 Non-text Contrast (AA)
• Maps that present upcoming construction and related planning are interactive and provide additional details on mapped objects. This information is, however, only available via mouse or touch interaction. WCAG 2.1.1 Keyboard (A)

Filtered searches

• The page has a search field that is accompanied with a text that instructs users on how to format search terms. Screen readers will not announce this help when the input field is focused. WCAG 1.3.1 Information and Relationships (A)
• Search results are shown inside a tabbed section that allows one to switch between a list and a map view. The tab buttons do not follow the standard keyboard focus management pattern for a tab list component. WCAG 1.3.1 Information and Relationships (A)
• The map view tab uses an iframe to host the results map. The iframe is named based on the source of the map data, not on the current context used to show it, and so the name may appear unusual or misleading to screen reader users. WCAG 1.1.1 Non-text Content (A)
• Some pages provide a search field that displays search suggestions as the user inputs characters. The number of suggested results is announced to screen readers, but if the number is zero it is announced in English irrespective of the page language. WCAG 3.3.2 Labels or instructions (A)
• The “Search for new items” field has a clear button, but its name is always in English for assistive technology users irrespective of the page language. WCAG 1.1.1 Non-text Content (A)
• Input fields that require a date provide the user with a calendar widget that is presented as a modal dialog. The dialog does not, however, automatically receive the suer’s keyboard focus, as a modal dialog should when opened. Hence, the user must use the TAB key or their screen reader’s form navigation mechanisms to enter the calendar. WCAG 2.4.3 Focus Order (A)

Correcting shortcomings

The City of Helsinki is continuously taking action to correct the shortcomings observed in accessibility. The city will update the list of accessibility shortcomings presented in this statement as shortcomings are corrected. 

The accessibility requirements do not apply to all content

The service contains videos that lack captions and audio descriptions. The law states that video content published before 23 September 2020 does not need to be rendered accessible or removed from the site retroactively (WCAG 1.2.2., WCAG 1.2.5).

The service includes maps that are not accessible to all users. The law does not require map content to be accessible, but essential guiding content must be available as written text, for example.

Did you notice shortcomings in accessibility?

We are constantly striving to improve the accessibility of the online service. If you encounter issues that are not described on this page, please report them to us and we will do our best to rectify them.

Provide feedback via this online form ( palautteet.hel.fi(Link leads to external service)) or send email to helsinki.palaute@hel.fi(Link opens default mail program).

You can also use the feedback channel to request accessible information on the content of the Hel.fi website.

Requesting information in an accessible format

If you feel that the website’s content is not available in an accessible format, you can request information by using the feedback form at palautteet.hel.fi(Link leads to external service). We will try to respond to your request within a reasonable time.

Accessibility control

Finnish Transport and Communications Agency Traficom monitors compliance with the applicable accessibility requirements. If you are dissatisfied with a response or do not receive one within two weeks, you can submit your feedback to Traricom.

Finnish Transport and Communications Agency Traficom
Digital Accessibility Supervision Unit
www.webaccessibility.fi(Link leads to external service)
saavutettavuus@traficom.fi(Link opens default mail program)
telephone switchboard 029 534 5000

The accessibility statement for the Hel.fi website is the responsibility of the Communications Content Production Unit of the Helsinki City Executive Office. This statement was prepared on 1 March 2026.