All posts by Mindful tester

Accessibility, Assistive technology

Test idea number 1 – Use the screen reader – part 2

At the Club of Ministry of Testing, Rosie Sherry asked to share test ideas in five words or less. My first test idea was: use the screen reader. In the previous blog post some aspects of testing with a screen reader have been highlighted. There is more stuff to think about. Or to be read.

A more holistic approach

Getting good quality also implies involving developers, product owners, and managers from the start. A lot of people tend to determine the quality of an app or web site for a screen reader in the final phases of the development of a product. This order of activities is not as expected.

If some laws require to make web sites or apps accessible for screen readers, then the selection of the UI elements should be strict. A law has some priority. Fortunately.

Whether the UI elements came through the initial test, they should be monitored. Even, if they are not updated by your own developers. Even removing UI elements can have some consequences for the operation of the app or web site.

There are other test activities than reviewing use stories and using the screen reader at the end. This means, that extra developer activities must be added. This is the reason I call this a holistic approach. As a tester, I tend to, look at the tools and the processes to make the software. That can be outside the tester comfort zone.

According to me, a life cycle approach should be used for each UI element. This cycle contains the following phases: Create, Read, Update, and Delete.

How to test Create a UI element suited for a screen reader

Use standard UI elements, which are automatically recognised by screen readers.

Use a library of accessible UI elements.

Extend existing code of UI elements. Inheritance is a way to make stable code. It is like adding some extra features to an existing UI element. A combo box based on code of another combo box might also
change.

Avoid making UI elements from scratch. For web sites the HTML tag Aria looks very compelling, but it takes some consideration. Suppose I like have a blue car. Inheritance would lead to buying a car and painting it blue. Aria would be like building a car from scratchans using blue paint. 

Use standard development practices. This year Sonos released an inaccessible app for iOS. The standard iOS elements are accessible, so the developers had taken some strange steps to use own elements
and instead.

Use good tools. This also applies for systems which can be adjusted to your company or organisation. I heard about a system which was accessible for job seekers, but not for the people inside the company.

Make a big app or web site with all custom-made GUI elements for evaluation. This is also needed for 3rd party softwire like cookie banner, chat bots, and web shop functionality.

To be extended.

Accessibility, Assistive technology

Test idea number 1 – part 1

At the Club of Ministry of Testing, Rosie Sherry asked to share test ideas in five words or less. My first test idea was: use the screen reader. That saved 1 word.

Introducing the screen reader

Describing the screen reader

A screen reader is a program, which reads aloud, what is happening on the screen. This program is used by blind or visually impaired users. Now they can get their own information or buy their own things. There is less need for help from family members or friends. That saves 5 minutes or more.

Mentioning aspects of the screen reader

My first experience was reading a legal text on a laptop. It was about Content. Now you might ask which other aspects are applicable.

During the demonstration, the cursor sprung from one paragraph to the next one with a short cut or key combination. The first paragraphs formed an introduction, which could be skipped after listening to the first sentence. So, the next aspect is Construction.

During the last years I noticed, that also my input was spoken aloud. Especially the buttons with a restricted input like checkboxes and combo boxes. It is always nice to hear, what I selected. This leads to the next aspect: Control.

There are some parts in the world, where people can speak different languages. For example, I live in the Netherlands and read English. One of my apps overruled the language of the screen reader, so I do not hear Dutch words with an English pronunciation. That is quite agreeable to hear. The last aspect is Choice of language.

So, testing with a screen reader is about Content, Control, Construction, and Choice of language. This will come back later.

Finding a screen reader

A lot of operating systems have a built-in screen reader. Windows has Narrator and Apple MacOS systems Voice Over. On the mobile front there is TalkBack on Android and VoiceOver on the iOS. On Windows there are alternatives like NVDA and JAWS, which is a part of Fusion.

Did I mention LINUX? There are also screen readers available for that operating system.

How to test with a screen reader

Let’s go back to Content, Control, Construction, and Choice of language. As promised.

How to test Content

Move the focus to images. By hovering the mouse above the a over a picture. Or pointing with a finger on the picture on a touchscreen. A picture should have a short story in the alternative text like the pictures in this test automation blog post. The same applies for a graph or a map.

How to test Control

Select a button and listen to the alternative text. This should explain the interaction of the button. Some buttons with nice pictograms might miss some explanation.

Select a value in a combo box or a switch, then listen to the selected value. Check boxes in cookie banners can be quite confusing,

Check whether the format of an input field is read aloud. For example, the date has the format DD-MM-YYYY. In case of error, check whether the error message is clear.

Check the code of the GUI or Graphical User Interface. The alternative text should be filled, if the button has a picture or if a graph is used. A possible solution might be static code analysis. There are accessibility test tools, but they might miss strange alternative texts.

Find the button using the find function of the screen reader. One of the most frequent used buttons, the Logout button, is sometimes hidden in unexpected ways. Note, that a screen reader can convert text to braille, A deaf blind user can use a braille reader to navigate a web site or app.

Feel the course, Luke.

How to test Construction

Check the use of proper headings. I like to
have good overview of an article, why not offer it to people with bad vision? Screen readers offer a nice list of headings and their levels like ”heading level 3, How to test Construction”. The list of headings also gives a user a fast way to jump to the section like “How to test with a screen reader – 2”.

Is it possible to make short cuts? It is like shopping in a super market. I do not want walk pass every shelf for buying only three items. A screen reader like JAWS has a feature to bookmark a certain place on a web page. This is a time saver.

Do you hear where you are or you do? A screen reader like JAWS stores everything it said. It is called history. If the history is not clear, how can a user know what is happening?

Compare the histories of two different executions of the same customer journey with each other. They should be the same, unless the differences are the results of bug fixes. In this case a new baseline for the history must be made. Emily Bache calls this Approval Testing. There are tools available to compare text files. My inner test automation nerd is pondering about combining RPA, a  file comparison tool, and Selenium.

How to test Choice of language

Set the language of the screen reader to English and open a Dutch app. Listen where Dutch is spoken. Or choose the favourite languages of your users based on user data.

A similar test could be executed for a web site. There is an HTML tag for language.

To be continued

Psychology

System 1 and System 2 in testing – part 3

In the previous blog posts System 1 and System 2 were discussed.

For the fast observations System 1 is used in most cases. This way of thinking provides fast, almost effortless way to digest information. Like walking to a restaurant.

For the thoughtful observations System 2 is used. An example is choosing what to eat in a restaurant.

In this episode I will write about situations, where System 1 and System 2 are used after each other. It is like shifting gears. This can lead to new test ideas.

Switching from System 1 to System 2

Switching off the auto pilot

Just like in previous years, I filled in my tax form this spring. There is an advantage for using a computer. I could save the form and correct any errors later on.  I just had to find the numbers and type them in the right text fields.

I read a strange term. What did this mean?

The following things happened:

”Hey hey, what does it actually say?
Clicking the question mark like JARVIS calling Stark
Getting tips when the question parts the lips.
Thinking, ’A.I. is not needed all the time.
Especially for this simple rhyme.’ ”
(On the melody of “American Pie”.)

Looking back

While I was filling in my tax form, it was like filling in a standard form. I did not need to think a lot. At that moment I was using System 1. Then I hesitated, there was something new. I might continue and paying too much tax. Not a pleasant thought.

I carefully thought about the situation.
Luckily, there was a way to get more detailed information. I pressed the question mark and got the requested information. With all this thinking, I was using System 2.

A well-designed web site provides enough information in case of questions.

Switching from System 2 to System 1

Taking a decision

Because of the increasing complexity of web sites, one of my kids helped me. while I booked the tickets. Holidays are always a good reason to get help.

The first questions were simple. I selected an airport a day and a time. Then I entered all the needed information about the passengers like names and birth dates. Then I needed to fill in the number of pieces of luggage. This question was not a surprise. I had done my homework.

Then the unexpected questions came up. Would I like to reserve seats? I only wanted 2 passenger seats next to each other. The other passengers would have no problem. But the web site did not allow to book reserved seats for a part of my company. It was all or none. I made a choice,

Would I like to rent a car? I did not intend to drive a car. No thanks.

Of course, I could book a bus ticket. That was not in my homework. A price of the bus tickets was shown on my screen. My kid looked on the mobile phone to determine, whether the bus ticket was better than the public traffic. The price sounded good enough. Then I could select a destination. I looked to my kid again. Using a map app and the location of the accommodation. my kid gave me a good suggestion.

Then we looked again to all the made choices. It looked good. I wanted to pay and pressed a button. Nothing happened. I pressed again. No deal.

Then I remembered that I got 2 warnings for booking too slow. Both times I requested for more time to book the flight. But somehow, I ran out of time. So, I spent a lot of energy and time for nothing.

Now I could go to another web site or do another attempt. Then the following things happened:

“Why, why did I do an extra try?
The thinking was done, the hesitating was gone.
Making the same choices, without any noises.
Thinking, “This’ll be the day that I retry.
This’ll be the day that I buy.”
(On the melody of “American Pie”.)

Looking back

Answering unexpected questions made me think. The questions about the bus tickets took 2 persons to answer them. System 2 was in use. For the second attempt to book the flight tickets, I could rely on my memory. Remembering things costed me less than a second. System 1 was now in use.

During the whole process I switched from Systen 2 to System 1. The choices were clear. If an application or web site does not provide an easy path  to remember, then the it will not be used for a second attempt.