Accessibility Statement for Secure Forms

This is an accessibility statement from SSH Communications Security.

Measures to support accessibility

SSH Communications Security takes the following measures to ensure accessibility of Secure Forms:

• Include accessibility as part of our mission statement.
• Include accessibility throughout our internal policies.
• Integrate accessibility into our procurement practices.
• Assign clear accessibility goals and responsibilities.
• Employ formal accessibility quality assurance methods.

Conformance status

The Web Content Accessibility Guidelines (WCAG) define requirements for designers and developers to improve accessibility for people with disabilities. They define three levels of conformance: Level A, Level AA, and Level AAA. Secure Forms is partially conformant with WCAG 2.2 Level AA.

Compatibility with browsers and assistive technology

Secure Forms is designed to be compatible with the following assistive technologies:

• Screen readers (e.g., NVDA, JAWS, VoiceOver, Orca)
• Keyboard navigation tools

Secure Forms is not compatible with:

• Outdated browsers (e.g., Internet Explorer)
• Assistive technologies that do not support ARIA or HTML5 form elements

Technical specifications

Accessibility of Secure Forms relies on the following technologies to work with the particular combination of web browser and any assistive technologies or plugins installed on your computer:

• HTML
• WAI-ARIA
• CSS
• JavaScript

These technologies are relied upon for conformance with the accessibility standards used.

Limitations and alternatives

Despite our best efforts to ensure accessibility of Secure Forms, there may be some limitations. Below is a description of known limitations and potential solutions. We are actively working to address these issues and improve accessibility.

Known limitations for Secure Forms:

• Printed PDF versions of web forms:

  Form fields, labels, and images in printed PDFs may be partly inaccessible to some screen readers or keyboard users. The PDF output becomes a static visual copy and might miss some accessibility tags or form controls.

  We are evaluating other PDF printing software solutions and improving the conversion process from form HTML to PDF to better preserve accessibility features. Use the HTML printing option in the form settings as an alternative in the meantime to produce accessible form content when downloading the form.

• Language identifiers for certain Sámi languages (e.g., Skolt Sámi):

  Some content may not be correctly identified or labeled with the appropriate language code, which could affect text-to-speech, screen readers, or other language-sensitive assistive technologies. Users may need to manually select the language in assistive technologies if available.

• Announcement of conditionally revealed inputs:

  Some questions are hidden by default and are revealed only when a dependency is satisfied. When these questions become visible, the change is not programmatically announced to screen readers. As a result, users of assistive technologies may not be aware that additional questions have appeared.

  The impact is partially mitigated when users navigate the form sequentially from top to bottom, as all dependent questions will eventually be encountered. However, non-linear navigation, such as skipping questions or navigating backward to change earlier answers, may result in newly revealed or removed questions not being communicated, which can lead to unexpected behavior for screen reader users.

• Navigating help pop-ups:

  Help pop-ups may present keyboard navigation issues for screen reader users. While standard tab navigation functions as expected, navigation using screen reader-specific commands, such as arrow key navigation in NVDA, may not consistently expose the pop-up content. In addition, some users may experience difficulty dismissing help pop-ups when they are triggered by mouse hover interactions.

• Screen reader issues on multi-page form review pages:

  Review pages displayed at the end of multi-page forms may present issues for screen reader users. In some cases, screen readers may announce incorrect text when describing form content. This is caused by inconsistencies in question identifiers across multiple pages. Users may need to rely on alternative confirmation page options while we address this issue.

Assessment approach

SSH Communications Security assessed the accessibility of Secure Forms by the following approaches:

• Self-evaluation
• External evaluation

Revision Date

This statement was last updated on 20 January 2026.