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.