Posted in accessibility testing

Accessibility testing


Web accessibility testing is a subset of usability testing where the users under consideration have disabilities that affect how they use the web. Wikipedia might tell you more about it.

But why is it so important?


Can you imagine that? There is 1 billion people with disabilities, who might be the users of your application – either web or mobile. Basically, it depends on your testing, if they would feel comfortable with that or not.

What does disability stand for?


Disability is an impairment that may be cognitive, developmental, intellectual, mental, physical, sensory, or some combination of these, and that substantially affects a person’s life activities.

In creating apps that satisfy the needs of all users – we should mainly focus on:

UI features:


  • color selection
  • icons size
  • display customization
  • ease of use and installation (if needed)


Backed features:

  • volume (regulation, presence)
  • adjusting to VoiceOver (iOS) and TalkBack (Android)
  • correct structure
  • guided access
  • speech adjustments
  • captioning
  • audio description

You could obviously wonder if people with disabilities use ‘normal’ apps? Aren’t there special apps or website for them? The answer is – yes – in both cases. They use “normal’ apps, as they need them just like any other person and there is a tiny range of apps dedicated for people with disabilities.

You may also wonder how – for example blind person – would be able to use my mobile app. The answer differs in the way that people and disabilities differ, but it doesn’t mean that we are not supposed to think about it while developing or testing.

Google said:

Everyone should be able to access and enjoy the web. We’re committed to making that a reality

I would completely agree with that. What is more, I personally believe that in societies, where technology is present in everyone’s life and life length extends – this is our duty to create software that is beyond ‘standard’ rules.

As Google tells you about the approach to accessibility – Android and iOS do so. If you don’t know how to start – just follow their advice.

Your accessibility testing should have the following, high level goals:

  • Set up and use the application without sighted assistance
  • All task workflows in the application can be easily navigated using directional controls and provide clear and appropriate feedback

Treat such testing as an act of kindness for all the people, who will use your app in the future.


The following tests must be completed in order to ensure a minimum level of application accessibility.

  1. Directional controls: Verify that the application can be operated without the use of a touch screen. Attempt to use only directional controls to accomplish the primary tasks in the application.
  2. TalkBack /VoiceOver audio prompts: Verify that user interface controls that provide information (graphics or text) or allow user action have clear and accurate audio descriptions when TalkBack /VoiceOver is enabled and controls are focused. Use directional controls to move focus between application layout elements.
  3. Explore by Touch prompts: Verify that user interface controls that provide information (graphics or text) or allow user action have appropriate audio descriptions. There should be no regions where contents or controls do not provide an audio description.
  4. Touchable control sizes: All controls where a user can select or take an action must be a minimum of 48 dp (approximately 9mm) in length and width, as recommended by Android Design.
  5. Gestures work with TalkBack/VoiceOver enabled: Verify that app-specific gestures, such as zooming images, scrolling lists, swiping between pages or navigating carousel controls continue to work when TalkBack/VoiceOver is enabled. If these gestures do not function, then an alternative interface for these actions must be provided.
  6. No audio-only feedback: Audio feedback must always have a secondary feedback mechanism to support users who are deaf or hard of hearing.

A friend of mine, who is a blind person but uses smartphone or web on daily basis, said one day that iPhone is waaaay better for her than Android devices. But the question is – if that depends on OS itself and their talking software or on poor Android apps that don’t fully support TalkBack and – to be honest -are annoying even for people whose vision is completely OK. I’m leaving you with this question.

In case of any comments – stalk me on Twitter.


Posted in tools

How does the Internet work? #Balsamiq


Two at once blog post.

#1 Balsamiq

Balsamiq is an amazing tool for UI prototyping. Any of you could take advantage of it. It helps not only in UI prototyping, but also may be used in any sort of your visual communication with customers, stakeholders or developers. It is simple, free to try for 30 days and easy to use. Balsamiq provides various options for web and mobile prototyping.

What I wanted to visualize today is an interesting question:

#2 How does the internet work

Let me rephrase that question: what happens when you type into your web browser. My Balsamiq-made info graphics – hopefully – would be an answer.


What the browser is going to do?

Step 1:

It will try to translate your URL into IP address. In order to do that – the browser checks cache (a place where system saves last translation results). If the cache is empty – browser will send a request to DNS server. The DNS server provides the browser with URL translated into IP address. Finally our browser would know the address (a default HTTP port = 80) which is responsible for GET our request.

Step 2:

Server transforms the request and if everything is OK response with the HTML website and at the same time 200 OK status.

Generally, in order to understand how does the internet work, we would have to know the answer to a question – what the HTTP protocol is.

HTTP stands for “Hypertext Transfer Protocol”. The entire World Wide Web uses this protocol. Almost everything you see in your browser is transmitted to your computer over HTTP. For example, when you opened this article page, your browser probably have sent over 40 HTTP requests and received HTTP responses for each.

HTTP headers are the core part of these HTTP requests and responses, and they carry information about the client browser, the requested page, the server and more.

To make my above graphics simpler – we could present it this way – using Balsamiq again:


Hope my short post encouraged you to try Balsamiq and use it within your testing tasks.
In case of any comments –  stalk me on Twitter 🙂

Posted in tools

Chrome DevTools – mobile testing


Moving on – Chrome DevTools could be used in web and mobile testing. Any tester should take advantage of it, because those tools are free and easily accessible. Let me introduce the most useful ideas for testing purposes, maybe you’ll come up with some new ones?

I hope that my super-fantastic screenshots enable you to find all the options and play around.

#1 Resizing and Rotating

As I said some time on my presentation, it is very important to check UI of your website on mobile browsers. Different ones. When we proceed manual tests (or don’t test our websites at all) it may happen that they are useless on mobile devices. And I am not talking about web applications, but also about any website accessible via web browser on your smartphone.

I am able to enumerate number of such examples – the most spicy you could find on my Twitter. If you find your ugly page here or on my Twitter – it’s nothing personal. i just want the web-world to be a better place 🙂

So… to avoid this:




or that…


Use the “Responsive” option in Chrome DevTools in order to make sure that majority of different screen resolutions is covered.

Remember – over 50% of google searches come from mobile browsers nowadays!


We can select a number of different mobile devices from the drop down menu in order to test with the different screen sizes. Chrome also tells us the screen dimensions of the device in the top menu as well, what is more, you are also able to rotate the screen. Screen rotation is also a common cause of mobile bugs, as the mobile website layout changes when the screen is rotated and page elements may need to reload.

It won’t pretend the real device, but give you lot of hints what other tests should be performed on your application.

#2 Console – debug

Either a developer or a tester is able to debug a website on mobile device (I wrote here how to connect your smartphone with Chrome DevTools).

In your JavaScript Console – you are able to find all range of errors appearing within the application.

As the complexity of JavaScript applications increase, developers need powerful debugging tools to help quickly discover the cause of an issue and fix it efficiently. The Chrome DevTools include a number of useful tools to help make debugging JavaScript less painful.


#3 Network and Throttling

The Network option allows you to observe the order and time of loading elements. You are provided with insights into resources that are requested and downloaded over the network in real time. It very important in mobile testing as users expect that mobile apps would work smooth and fast.

  1. Open DevTools (F12)
  2. Click the ‘Network’ tab
  3. Click Throttling in s row below
  4. Select which type of connection you want to imitate
  5. Reload the page to see assets downloading at that connection speed


The Network tab in Chrome DevTools has an option to faux throttle your network, so you can experience what your users might see visiting your website on 3G, 2G and EDGE connections. Throttling option is also useful for visualizing how fonts load.


What kind of errors are likely to avoid with such testing? Let me show you a few examples:



#4 Audit

The Audit panel can analyze a page as it loads. Then provides suggestions and optimizations for decreasing page load time and increase perceived (and real) responsiveness.

#5 Elements

The Elements panel allows you to see everything in one DOM tree, and helps inspection and on-the-fly editing of DOM elements. It is very useful option for those, who automate their testing.

But you’ve been probably heard about this one:)

#6 Location

And this is a great functionality! How to test the app that must work in different locations and presents a map for you – teleport wasn’t invented yet! There is an option in DevTools that allows you to mimic location. The option is a bit hidden:

  1. Open Dev Tools
  2. Click action bar on the bottom right of the screen
  3. Select More Tools
  4. Click Sensors



Now you are able to provide a website/application with your desired geo-coordinates and pretend you are there. Remember about reloading the page with every coordinate change.

There is more – all you need is to explore the options.

Have fun with DevTools. In case of any questions – stalk me on Twitter.