On June 28, 2025, the “Barrierefreheitsstärkungsgesetz“ (BFSG) based on the European Accessibility Act (EAA) will come into law in Germany.
On the one hand, this law obliges us to offer low-barrier software for our customers. As a provider of software for state actors, we must comply with the Web Content Accessibility Guidelines (WCAG) of at least levels “A” and “AA” (see EU standard “EN 301 549”). In order to ensure proper implementation in accordance with the EU standard, we therefore work together with affected persons.
For this reason, we are currently looking for a suitable test management tool that can be used by people with disabilities.
Can you tell me to what extent Testiny is suitable for people with disabilities? What WCAG compliance level is achieved by Testiny? What measures to increase accessibility has Testiny already taken or will soon be available? In particular: Is Testiny fully and easily usable by blind people with a screen reader and keyboard only and without mouse?
This is a really exciting topic and we have been focusing on accessibility
right from the start of development work on Testiny.
This is why ARIA tags are used across the board and keyboard operation is also possible everywhere.
However, as you know, Testiny and test management in generell, is a very data-heavy topic and despite the use of best practices in the accessibility area, operation purely via accessibility features could be a challenge.
But Testiny can definitely be used by people with disabilities.
Just, generally speaking, the handling of the topic of “test management” can quickly become cumbersome, for example, if there are many tests in a project due to the sheer volume of data.
I hope you can understand what I mean.
We attach great importance to all guidelines defined in the WCAG and do our best to fulfill all necessary guidelines.
If you notice anything in Testiny that is against the WCAG guidelines, we are always grateful for feedback
I completely understand that. As a person with normal vision, it is really difficult to put yourself in the shoes of someone with impaired vision.
Specifically, we imagined that employees with normal vision would create the test cases in the form of exploratory tests, i.e. formulating the objectives to be achieved in each case rather than describing specific and detailed procedures. This alone might not be easy for our employees with normal vision. The test runs are then also created by people with normal vision. Everything is prepared for the test run, so to speak. The visually impaired users should actually only be able to call up the tests and tick them off. I have just tried this out myself with keyboard control and the screen reader “nvda” in Chrome. (I can really recommend everyone to try it out for themselves. It’s a really interesting experience.) Yes, you can clearly see that a lot of emphasis has already been placed on barrier-free operation. Pretty much everything important can be accessed via keyboard control. Although it is actually difficult to understand exactly where you are.
I spontaneously noticed the following points:
There are mouse-over effects in tables (headers and rows). The icons cannot be highlighted with a border when tapping through.
After clicking on “Start test run” the sidebar is opened. It takes a relatively long time to get there when tabbing and when the user is there he does not know that he is in the test execution panel.
When I add a result, it is difficult to find out which step you are currently in and whether you are on the left of the steps or on the right of the expected behavior. The step number and context could be read out better.
Optional: Alt texts for images could not be added during test case creation.
