Why should you learn Accessibility Testing right now?

Learn Accessibility Testing became a must have for test automation software developers.

About 20% of the population has disability issues.

·        1 in 10 people have a severe disability

·        1 in 2 people over 65 have reduced capabilities

Disabilities include blindness, deaf, handicapped, or any disorders in the body.

A software product can cater to this big market, if it’s made disabled friendly. Accessibility issues in software can be resolved if Accessibility Testing is made part of normal software testing life cycle.

If you are still not sure if it is worth doing.  Think not about how much extra money you are acquiring, but how much potential money you are losing.

According to the 2016 survey, more than 4 million people in the UK have abandoned a retail website due to accessibility barriers. This figure is substantial — especially when you consider that there are 14 million people in the UK with disabilities, and 6.1 million with a disability affecting their use of the internet.

The survey also finds that customers who leave a website due to accessibility challenges have an estimated spending power of £11.75 billion ($15.38 billion USD). This represents roughly 10% of the UK’s entire annual spending on e-commerce.

What is Accessibility Testing?

Accessibility testing is testing an application for compliance with the W3C guidelines, namely Web Content Accessibility Guidelines (WCAG) 2.1.  During Accessibility testing, experts check how accessible an application is to people with disabilities.

What limited capabilities can you really adapt the platform to?

Accessibility often helps not only people with disabilities, but everyone else under certain circumstances.  In a noisy environment, for example, or vice versa, if you can’t make noise, when you don’t have headphones at hand, you can watch a video with subtitles.  Or vice versa: when there is no way to read something, you can listen to it.

Most often, applications are tailored for users with hearing or vision impairments, and less often for people who cannot use a keyboard or other manual input device.

What functionality needs to be added to the site / application for this?

All this should be taken into account during development, and even earlier, when drawing up requirements.  Basically, all these features that help to adapt are hidden in tags and attributes, in the page markup, in the layout.  Videos in such applications must necessarily support subtitles.

There are additional programs and extensions for browsers that help people to view pages, to perceive information in any way, visually or by ear.  It is in our power to make sure that users click on the necessary page elements.  You can remove some long and complex words, make them shorter and more understandable, important pictures can be accompanied by captions that can be voiced using a screen reader.  Usually they are already embedded in the device’s firmware: on iOS it’s VoiceOver, on Android it’s in the Accessibility tab, which you can find in the settings, and on Windows you can install NVDA.

Also, the page may contain design elements that are not directly involved in its direct control and do not affect the content in any way – something that people, in fact, do not need.  It is advisable to hide such elements.  It is within our power to make these bodies focus on what is needed.

Should people with disabilities be involved in the adaptation process?

It is not necessary.  In fact, any person can “limit” some of his opportunities.  Mute the sound or use the application with your eyes closed, try voice input.  Perhaps this would only be useful in final testing – alpha or beta – when focus groups are involved.

What are the main distinguishing features of accessibility testing?  Which tools should be used?

The testing itself takes place as follows: items are selected from the document, which must be adhered to when developing the application and tested.  Testing first with automated tools and browser extensions like Wave (the tutorial can be found here https://bit.ly/36v2O1s ).  Check the code, contrast, font size, etc.  After checking, such tools give out gross inconsistencies and recommendations for improvement.

Then the developers fix everything and the tasks go to manual testing.  Test cases are written for this, which describes what needs to be checked as part of the accessibility of testing.  Found inconsistencies are tested and sent to the bugfix, with recommendations for improvement.

Not everyone can catch automatic tools, so it is desirable to have both auto and manual testing.  Auto-testing often skips spaces between paragraphs, or some kind of trap when navigating on a page.  For example, using the “tab” button you can switch between page elements, and if something gets stuck in a paragraph or between links – these things are already calculated by specialists separately.  Also, auto-testing will not help detect this on tablets and phones.  It is better to do it manually – watch, listen to how it will look from the side of a real user.