This website is not accessible.

ISTQB Advanced Test Manager (1)

Theory – you can scroll down if you know it 🙂

Accessibility of mobile and web applications means to enable all internet users, especially the impaired people, to feel, understand, navigate and capable the full usage of the applications. The ability of accessibility testing is extremely important for all web content creators and enables to raise the bar height and enlarge the range of users.

The impairment, so to speak, may be connected with hearing, visual, mental or physical limitations. On the other hand, being an impaired person doesn’t have to mean cyber exclusion. How the modern internet looks like depends on developers’ and testers’ willingness to deal with modern quality requirements.

It may seem that impaired people make just a tiny piece of mobile and web application users – on the contrary – stand the results of research made by Google Inc. since 2005, which prove that there are over one billion impaired users in the world, who use the applications on daily basis. The number may impress, but also shows the scale of the new market, that demands better software quality.

Developers and testers in each mobile or web project should always estimate how much and what kind of accessibility testing is required and how to measure the accessibility testing coverage. Better accessibility means a higher quality level and better user experience, which all brands would like to be associated with.

What does it mean to adopt a website’s content to meet certain needs? At first, developers should focus on good HTML code quality, compatible with helpers – devices and applications – on PCs and smartphones. For example, lack of unique ids stands for a severe bug, that might be discovered with the help of accessibility testing.

Basic principles

Here is the set of basic principles of creating applications that meet the accessibility requirements.

When creating applications that meet the unique needs of users, special attention should be paid to the implementation of user interface elements, such as:


People affected by visual impairment, that prevent the correct perception of colors, may be excluded from the audience of applications if they can not properly distinguish individual elements. This can be verified by using specific screen filters (eg from – compatible with Windows, Mac, and Linux), that mimic certain dysfunctions.

– icons

Their size and simplicity are particularly important to people with motoric impairment or with cognitive difficulties.

– the ability to change the resolution of the displayed elements

– ease of use and installation of the application

and backend elements:

– volume control

– adaptation to speech assistants, e.g. VoiceOver (iOS) or TalkBack (Android)

– appropriate structure of the application HTML code

so as to enable communication between our application and speech assistant software for the blind.

– the ability to use audio descriptions.

Practically, accessibility testing means to meet all of the above and increase the number of usability tests. However, the case is not to fulfill subjective aesthetic feelings in relation to a given application, but to conduct certain test suites, designed for particular user groups. The spectrum of the tester’s capabilities is basically unlimited – creativity is the key. It is also necessary to imagine yourself as a person with a specific need, and consequently to select a set of tests aimed at in-depth testing of a narrow area of ​​applications, e.g. selected elements of the graphical interface. It should also be noted that while in the core layer and the relevant quality requirements are simple – the code itself has to be thought out, readable and adapted to work with various types of helpers. Developing a test suite requires a lot of ingenuity and empathy from the tester.

A properly working application available for people with disabilities should always ensure:

– easy installation,

– navigating without the help of sight,

– the ability to use the application with simple gestures,

– clear feedback to the user.

Creating mobile applications and websites that will work with helpers – that support people with disabilities – is not only a correct implementation of basic functionalities but also the ability to replace or enrich specific actions in the application with others. For example – by adding vibrations each time you touch an active element, enlarge the font or highlight parts of the image for the visually impaired people. Testing of such applications should check whether:

– it is possible to navigate without using a touchscreen,

– audio description is available for every visible element,

– there are application areas devoid of audio descriptions,

– all elements to which you can click have at least 48 dp (9 mm) in length and width,

– all voice elements have an additional mechanism to support users with hearing impairments.

Both – developers of speech assistants and application developers – eventually experience the same challenge. Working on sufficient such solutions is to keep the consistency and availability of applications without losing the features of a modern product. Each new design should be supported by both parties.


You had one job.

Do you remember a friend of mine – about whom I was talking during UK Star? She cannot see. On the other hand, she would like to stay active and simply work.
She takes various jobs, when she has such opportunity and usually she actively looks for it.

Let’s focus on this particular case.

Last week this friend of mine called us saying, that she has found a new job opportunity, but the website she is supposed to enter is not fully accessible for her. She was simply asking for help. What is more, she was confused, because the job description was quite clear.

There is an application which gathers various voice recordings. The purpose of the job is supposed to be transferring those recordings into written words. Transfer them into text.
My friend uses a computer and keyboard on daily basis, so it seemed to be suitable work for her.

The problem was, that for some reason, her voice assistant (Ivona) was not able to access all website elements, so she was not able to go through the application, not mentioning to complete her job, that’s why she asked for help.

So we opened the website…

It turned out that the voice assistant has not been mistaken.


How does it work?

Assuming you have a (Polish) recording that you wish to transcript. You shall go to this website, register yourself, upload the file and the magic happens. When I write magic – I mean a person – as a friend of mine – does the transcript for you.

I shall quote my beloved developer: “This website has been implemented before the Internet era begun or by someone who has never seen the Internet before”.

The main page is even not the worst. It’s getting muuuuuuuuuuuuuuch worse when you log in. In order to perform the translation, you need to use specific keyboard shortcuts, and they are spread all over the keyboard without reasonable order. You can customise the shortcuts later, but at first, when you cannot see, you and your voice assistant have to deal with the existing ones and this task is not easy.

This website doesn’t have responsive web design.

This website doesn’t have accessible HTML code.

This website makes voice assistants completely lost.

I don’t want to say, that companies are forbidden from making ugly websites.
Do whatever you want, BUT when you employ impaired people, just try not to insult them.
Thank you.


This time I’ll leave the judgment and comments for you, guys. Just check the website by yourself if you wish.
I’m speechless.

If you have any cool job offers for people, who cannot see, I have some friends to recommend!



The power of “what if” testing



I may be repeating myself, but today we’ll try to think a little bit about a matter of testing outside the box and companies’ reputation on the market.

Most of you, my Dear Readers, work on big software projects. Not all of you in agile ones. As I found out recently, there are still tons of projects that in the field of testing follow very structured and organized test plans, cases etc. It is all great because without your work major bugs would never be discovered.

Today I would like to highlight edge-case testing – all those “what if…” situations that may be not spotted in regular test scenarios. You can always take a step back to see the purpose of your job. I mean it. When you rush in the project work, it is always to little time to look around you. It’s possible, that sometimes you are too focused (or focused enough) to obtain your in-company, in-project testing goals, so you are missing some important factors that make software GOOD.

My purpose today is to convince you that sometimes is good to take a step back and have look on the product, to test outside your comfort zone or, possibly, to ask somebody else to pair with you in testing. Such activities might improve the overall product quality, and make live users – like me – happy and calm.


When I was at the beginning of my career as a software tester, I thought (and I believe
I was also told so), that if I try hard enough, my product will be bugproof and bug-free. The more projects I took part in – the more I realized that it is not necessarily true.
At least some of ISTQB statements are right – software will never be bug-free, and you are not able to stop testing. There always will be something to test, something to improve. On the other hand, some of us – testers – often fall in the trap of checking.
No matter if we write automated test scripts or just repeat series of activities on well know the product. Unintentionally we suffer from pesticide paradox in our projects.
I was in such situations several times by know, when, after a period of really hard project work, I thought that I did everything I could to improve the quality. How big my surprise was when the bugs come back from live customers.


Not thinking outside the box is one of the hardest testers’ sin. Let me give you a recent example. Some of you may have heard that Apple experiences issues with their product updates. There were situations reported online about devices going on fire after an update (wow).

It sounds spectacular and not as breathtaking as this reply from Apple Support (wow):

“That’s definitely not expected behavior. DM us, so we can look into this with you”


I believe that the end user could have been upset and even frightened.
Does it mean that Apple doesn’t test the updating process of their own software? I don’t believe that. But, on the other hand, even such big companies seem to omit some edge cases in their testing process, in the great rush of introducing innovation.
There is more this week from Apple Support. One of my favorite Polish travel vloggers – BezPlanu – put a message on Facebook:

This Sunday I was supposed to present the last chapter form Venezuela. Unfortunately, using fast Chile’s internet, I’ve decided to install the newest iOS update – Mojave – on my MacBook. My computer requested it for two weeks. I’ve ended in the position where I’ve lost everything – including half-done new film (plus part of my Lima recordings and part of Santiago recordings) – they have not been archived on an external disc. After 4 days of the fight and dozens of phone calls with Apple consultants and other specialists, I’ve acknowledged that “it happens when updating” and “you have to back up everything” and it is normal that a computer worth 22 000 PLN could not handle the OS update…

A piece of advice from Apple care was to back up your data before software update. Sure.

And again, it doesn’t mean that they have never tested that, maybe they have, but overall it influences the whole product reputation. The product reputation is not only the matter of marketing but something that identifies the work of all employees, developer, testers, and people involved in creating this software.

It reminded me also of the same situation I had with my Samsung a few Android updates ago. My SIM Card died after the update. The ‘funny’ fact was that no one reported such situation online before. I just got used to such situations in my tester’s life. Lessons learned – always do the backup in case somebody omitted update tests on your device / SIM card model.


Why am I pointing that? Because I believe that, as the software testers, quality evangelists, we are responsible for thinking outside the box and trying to fit in user’s skin. What the user would do with our software? What might be the craziest thing that comes to my mind? What if I…? and so on. It may allow us to avoid some expensive mistakes. I think that we should always consider event the least likely “what ifs” – especially when we work for the well-known company because the equation is simple – the better known the company is – the more expensive are our mistakes. They cost money and – most harmfully – reputation.

Tiny last example from last week.
I’ve started attending German classes in order to improve my language skills. One of the tests on the course was to change the language on my mobile into German. The fun has begun. Not only some of my applications started to throw errors – they event were lost in the UI layer.


It seems that Instagram is not dealing properly with German names that might be long and uncomfortable for UI, especially mobile UI. Fun! But embarrassing. But Fun 🙂

As a summing up – I would like to encourage you today – in your own projects – go tomorrow to work and test something unexpected: backup, installation, simulate network change. Do something potentially crazy, something outside your range of responsibilities. Pair with your non-technical friend or let somebody else test your software (if possible). It is possible that such action, from time to time, may save your company’s reputation and some money.

Good luck bug hunters!

In case of any comments – stalk me on Twitter.