Accessibility statement

The accessibility statement applies to the service Help site was published in 2023, so the service is subject to the Act on the Provision of Digital Services, which requires that public online services must be accessible.

The accessibility of the service has been assessed by an external expert organisation.

We observe shortcomings related to the accessibility of the site, for example, with the help of the Wave and the Siteimprove programmes and using the NVDA screen reader. We constantly correct the accessibility deficiencies detected on the site and its content.

This statement contains

The Help website will undergo an accessibility audit in January 2024, after which the full accessibility report will be published.

The statement was last revised on 13.2.2024.

Accessibility at Jamk

Accessibility means that websites and mobile applications and their contents are accessible, i.e. everyone must have equal opportunities to use online services.

In Jamk, accessibility means that every student and personnel member can feel equality and participation regardless of their personal characteristics or situation in life. 

Accessibility plan of Jamk (pdf) (login required)

Accessibility status of the digital service

The accessibility of the sites is at a fairly good level. Accessibility requirements have been clearly considered. But, as is most often the case, some corrections, both technical and content-editing, were found.

Content or functions that are not yet accessible

The Help website will undergo an accessibility audit in January 2024, after which the full accessibility report will be published.

Accessibility issues preventing use

  • The presentation of the video on the site is implemented with a HTML5 video element. Each browser is responsible for the implementation of the HTML video element, which is why the commands used to control the video may vary from browser to browser. In a test on a Mac platform, Safari did not load or display a <track> element in a video element with captions in a standard .vtt file. Other browsers recognized the subtitle file, which could be displayed browser-specific using the controls of the video element.
  • For some videos, the poster link is incorrect and no preview is displayed in place of the video.
  • In the Windows environment, there was also a problem with the high contrast mode.  When the page loads, the video preview (poster) does not appear and the screen remains black. Only the video controls and timeline are displayed. Only after starting the video will the image (video) appear.
  • Video function buttons were accessible with a keyboard, but not very well with a screen reader unless you enable full-screen mode. In addition, the screen reader does not receive sufficient information about the available controls from all video players. For example, the browser’s own video player only informs the screen reader of the information “button”. Compare to a Youtube video player that clearly announces the function for each button it offers.
  • When a high-contrast theme is selected, the check mark does not stand out in form elements.

Accessibility problems hampering use

  • Content zoomed in with the browser’s own commands (Ctrl + or Cmd +) changed the view to match the “mobile view”. Also on two tested machines (Windows 11 and Mac), Google Chrome no longer opened the menu at all after zooming.
  • At 400% page zoom, the page header covers a very large part of the page area, making it difficult to view the content. When using the keyboard for navigation, scrolling down is quite easy when scrolling the page reaches the point where the header also scrolls hidden at the top of the screen. In this case, the entire browser window is available for the actual content. When scrolling back up, the header immediately appears and covers a large part of the browser window, making it difficult to access the content. Hiding the header area also seemed to work differently in different browsers. In Google Chrome, the header seemed to remain visible even when scrolling down.
  • in the application forms not all form fields are named in such a way that assistive technologies would be informed to identify the field. Missing form field descriptions make data entry more laborious with a screen reader. If the fields are named correctly, the assistive device user can switch directly between form fields with a single press of the Tab key. If the fields are not named, entering data in the form becomes more complicated and slower, if not impossible.
  • The purpose of HTML markup is to tell about the content of the page, the purpose of the content – what the content is. Marking must be done according to the specification and correctly. The HTML structure must mark the headings that build the content of the page logically and hierarchically correctly. The title should always be followed by the content for which the title is written.
  • A significant number of users take advantage of contrast themes provided by operating systems, in which typically the colors of the screen (content) are inverted. On some pages, the image disappears when you hover over the image. When navigating with the tab key on the keyboard, this does not happen.
  • A screen reader converts text to speech. If the language attribute of a page or individual text is something else than the language in which the text was written, it may be difficult or even impossible to understand the content by hearing, as the assistive device program produces, for example, Finnish, which is pronounced in English.
  • Screen readers read the names of user interface elements to the user. If the names are not in the same language as the site itself, browsing the content becomes slower and more difficult.
  • When the page loads, the position of the active section should be in the reading order, i.e. initially at the top left side of the page. From now on, the user navigates as they wish.
  • On page, there is also a peculiar situation with the Jaws screen reader: when the page loads, the screen reader beeps to inform you about the transition to the so-called form mode, where text is received instead of navigation commands (navigation actions are performed with letters in non-form mode).
  • An error in the contact form (missing mandatory information – “Field is required”) becomes general information, but the user is not told what the error is and in which form field.
  • For screen readers, the notification appears after the Send button and the screen reader reads it automatically. If the user does not find out right away, he will try to read it again, but this will not succeed. Text cannot be found even if the user uses the up/down arrow buttons to search for an error message.

Accessibility issues related to mobile use

  • When a screen reader is enabled on your mobile device, video playback does not work normally:
    • When using swipe gestures, the indicator of the active point is drawn around the entire video element, not around the Play buttons.
    • The video can be started with a double tap, which opens the video on a “transparent” page.
    • When navigating with a screen reader, the contents of the page left in the background can be read. To pause and exit the video, the user must see to touch the video element and then tap. After this, the user can exit the view only if the user navigates backwards to the entire content of the page that remains in the background. This requires several dozen backward-swiping gestures.
    • If you know how to do this, you will finally be able to access the Close button at the top left.
    • Guiding swipe gestures activate the entire video element, but the Play button in the middle of the video cannot be accessed. If the user sees the start button in the middle of the video, touching it directly will play the video.
    • This issue prevents you from working on the site you’re testing, but the alternative channel provided must be reached and that’s where the video can be launched.
    • A tip about an alternative channel should be placed before the video so that the tip does not go unnoticed by the user. Now the tip is after the video. When a user’s actions fail, they may not scroll through the page content.
  • When you start a video on the inspecting page on a mobile device with a screen reader enabled, the active part bounces to the top of the page, i.e. the video disappears from the screen.
  • In mobile view, language selection is done at the bottom of the navigation menu. Even in terms of vision, the location is too far away, especially if the user is browsing the site by stepping on the keyboard interface, for example. Using a screen reader
  • On a mobile device, the screen reader says “Areena Pro” or “Areena Public” next to the images. The meaning does not open to the user.

Other observations related to ease of use and accessibility

  • Centering text causes lines in a body paragraph to begin at different points on the screen. For a person who has reading problems or uses a screen magnifier – or has a so-called screen magnifier. tube vision – this makes it difficult to read the contents.
  • The navigation is built in such a way that the button displayed on the screen opens the submenu. First up is the link to the landing page of the opened category, which is named the same as the button that opens the submenu.
  • The site uses a method where a large area leads to a page on a topic and the user is shown an excerpt from the text of the destination page under the title. Cognitively, it might be better if there was some coherent caption under the title, which the user reads as a description of the topic of the link. Now a clip of the first body text paragraph has been previewed and the sentences run out.
  • Alternative descriptions must be written for the images according to accessibility requirements.  For ease of use and usability, descriptions should only be written when the image somehow adds information to the user in the body text. Screen readers receive a huge amount of information about all the elements of the page, so all so-called screen readers. Unnecessary information only slows down the browsing of content.
  • If the link opens something other than another web page and the user should know how to act correctly with the new application that is opening, information about the changing activity must be included in the link text

Did you notice the lack of accessibility in our digital service?

Tell us about the lack of accessibility and we will do our best to correct the lack. We welcome suggestions, comments, questions and suggestions for improvement regarding the accessibility of Help site by e-mail to saavutettavuus(a)

We are constantly working to improve the accessibility of the online service. If you find any problems on the site that are not described in this statement, please let us know. We are also happy to receive other comments and suggestions for improvement regarding the accessibility of the website.

Identify your feedback as accurately as possible. This will speed up the processing of feedback and help us fix it.

  • Describe the problem and how it affects your use of the site.
  • Enter the address of the web page where you encountered the problem or where the dataset is located.
  • If you request material, enter a name for the file.

Accessibility monitoring

The Regional State Administrative Agency for Southern Finland supervises the implementation of the accessibility requirements. If you are not satisfied with the response you have received from us or if you do not receive a response at all within two weeks, you can submit feedback to the Regional State Administrative Agency for Southern Finland (link opens in a new window).” The website of the Regional State Administrative Agency for Southern Finland provides detailed information on how to file a complaint and how to handle the matter.

Contact details of the supervisory authority

Etelä-Suomen aluehallintovirasto (available in Finnish and Swedish)
phone number 0295 016 000 (exchange)