Why there is a need of accessibility testing?

Web accessibility is an art of building the website for users with disabilities such as physical, vision, cognitive and hearing disabilities.

My goal has always been to enable every tester to maximise their potential through individualised training towards accessibility testing. My method consists of being able to connect with the tester and convert them towards Quality Engineering with a strong ability to test applications using accessibility techniques. In short, every defect fix developed deeper resilience in my QE’s mind, reinforcing the strong belief they had in mind to find any more accessibility issues hence make the web application reliable and consistent for users with disabilities.

According to World Bank’s report, 15% of world population lives with disability; When everyone uses websites to book travel tickets, money transactions, online shopping or post on facebook and twitter, one billion people with disabilities (that is 1 out 5 people around us) interacts with those websites using screen readers/assistive technologies in day-to-day life and experience difficulty when some (many) of the websites are inaccessible!

Audioeye.com listed the high-profile lawsuits against famous retail companies since their websites are inaccessible to people who are blind and have visual impairments.

Tablet accessed by a user with a disability

Organisations trying to recruit right engineers with accessibility skills and Jobserve.com lists nearly 62+ I.T jobs across the UK in the last 7 days with ‘accessibility’ as an essential requirement for their selection process. Monster.co.uk lists 763+ active I.T jobs across UK which also lists ‘accessibility’ as their key criteria to shortlist applications.

On the other hand, there are no sufficient I.T resources available in the market with skill sets to develop and test by keeping accessibility guidelines in mind. So why there are a lot of jobs open but less or very few people apply to these jobs? The answer is ‘not much awareness being made for QAs to focus on accessibility when comparing to automation testing’

Automation testing has been matured as a basic need for a QA to be hired in I.T industry; Gone are days when people think that joining as manual tester and moving to automation tester role can get them to survive in software jobs; now the trend of specialty testing such as accessibility QA is in high demand for testers to grab high-paid job offers in the market! On a different note, accessibility testing is mainly done by manual testing and less or very few ‘regression test cases’ can be automated up to 30% (detailed in my recent book on ‘advanced selenium web accessibility testing’)

The Web Content Accessibility Guidelines (WCAG) and GSA Section 508 provide detailed recommendations and examples to meet the web accessibility requirements. But not many Quality Engineers and Front End Developers are trained to understand the defect classifications of WCAG (A, AA and AAA) and implement those guidelines in software projects.

Chandrashekhar Korlahalli, IT expert in accessibility testing

He use website through android phone for travel ticket booking, shopping online, Google search and so on; Even while walking on London streets, he need to explore options to use information to reach the destination since Google map voice over itself, not that accessible-friendly in finding routes; During the recent discussions, he shared his painful experience on accessing websites from his mobile browsers and hearing them through mobile voice over; Some websites are completely made inaccessible for him to use for basic needs. At least one of the famous professional networking website is 0% accessible (while accessing links or sending/receiving messages) for him to update his professional profile online! He has been testing applications and raising accessibility defects with his strong expertise and also undertakes trainings for QAs to implement accessibility in their testing cycle.

How to understand web accessibility (a11y) violations?

The smart way to learn accessibility violations is to start using axe as a plugin in google chrome browser and test your website for any possible a11y violations:

Axe Plugin for Google Chrome Browser

  • Google search on Axe plugin for chrome.
  • Axe Plugin for Google Chrome browser.
  • Press F12 from Google Chrome to see axe as a tab and click on analyse to scan the page to find accessibility violations on this page.
  • Axe Google Chrome plugin provides the violation list of a web page.

Why learning accessibility testing is not much understood by QAs?

Users with disabilities such as arthritis use keyboards to use the Internet and they find it painful to use the mouse. Similarly, wheelchair users having difficulty in accessing computers, use switches to interact to web applications; If users having disability in touching the computer devices, they may even use nose or part of their fingers from hands or legs to access the web applications in technology devices such as a computer, tablet, and so on. Some users with no vision, have no access or refrain from using a proper computer monitor since it is not required! In such situations, web applications should facilitate users with enough flexibility in using different features of rich media contents such as video play, pause, mute, and so on. Now the need for QA is to write a test case for such combinations by considering WCAG/Section 508 guidelines.

What a good test case looks like?

Test Case Name: 01_NFT_Accessibility_FFXNVDA_Verify_Google_Search.

Test Description: H44 and H32 WCAG standards are verified on the web page www.google.com using Firefox and NVDA.

Pre-requisite: Install NVDA (open source) and Firefox quantum 58.0.2 on the Windows 10.

Test Step 1: Open NVDA on a Windows 10 operating system and use earphone to hear the voice provided by NVDA.(Alternatively, right-click on the NVDA icon on bottom right-hand side of desktop and choose option ‘Tools’ to select ‘Speech Viewer’ which display the texts representing voice-over sound)

Expected Result 1: NVDA should be opened successfully and contents read out clearly by NVDA to the user.

Test Step 2: Open Firefox Quantum (version 58.0.2 (64-bit)) on a Windows 10 operating system.

Expected Result 2: Firefox should be opened successfully.

Test Step 3: Launch www.google.com website.

Expected Result 3: Google search page should be opened and URL should be read successfully by NVDA.

Test Step 4: Navigate from URL to text box using TAB key of keyboard on the Google search page.

Expected Result 4: NVDA should read the details of the text box.

Test Step 5: Enter text within the text box.

Expected Result 5: Text entered on the text box should be read out clearly.

Test Step 6: Press TAB key to navigate to Search Button.

Expected Result 6: Submit button should be read clearly.

Test Step 7: Press ENTER on the Search button.

Expected Result: NVDA should read the search results clearly.

What a Bad Test Case Looks Like?

Test Case Name: 01_NFT_Accessibility_IEXNVDA_Verify_Google_Search.

Test Description: H44 and H32 WCAG standards are verified on the web page www.google.com using Internet Explorer 11 and NVDA.

Reason:

NVDA doesn’t go well with Internet Explorer hence it is advisable to use JAWS for this test case to verify accessibility on Internet Explorer.

Possibilities of Accessibility Automation Tests

Repeating regression tests are painful and expensive hence automation testing has been helping us to repeat any tests, but this is not completely possible for accessibility testing.

Teams which are implemented accessibility scan tools such as pa11y or axe, think that test automation is all about implementing axe into their automation framework-but adding accessibility scan itself does not prove that accessibility issues are completely addressed.

Performing axe code scan would help us identifying first-hand defects but testing the website manually using a screen reader would spot many accessibility violations and difficulty in accessibility certain elements of websites.

Post completion of first manual (accessibility) testing cycle, it is possible to capture the properties(which enabled screen readers to read the sections) such as aria label, alt-text, aria-label, role, href can be verified using test automation tools such as selenium webdriverio-javascript:

driver.findElement(selenium.By.id(qa-selector))

     .then (function(attribute){

     Expect (attribute).toEqual(‘true’);

});

If keyboard actions performed manually (Tab,Shift+Tab), it is possible to automate them for next cycles using keystrokes instructions within selenium webdriverio-javascript such as:

driver.findElement(selenium.By.id(qa-selector))

     .then(function (element) {

     element.sendKeys(Key.TAB);

return element;

})

Why accessibility defects are expensive to fix?

Accessibility testing has been considered as ‘Non-Functional Testing’ in the majority of the companies and scheduled after the functional testing cycle. But accessibility testing itself is a form for functionality testing of web applications using screen readers hence defect identification and fix takes expensive attempt to get it retested. So bringing accessibility testing before build deployment and functional testing would be the best option to avoid multiple deployments to test early in the life cycle! In this shift left accessibility testing, a web application can be tested once developed in the developer’s laptop using a screen reader; Hence html properties can be updated to match the WCAG guidelines and fix those accessibility defects to build the codebase. Hence subset of accessibility tests are performed when the front end code is ready and remaining completed postcode deployments into test environments. Thus cost save across SDLC and it makes life easy for your customers with various disabilities. Aparna Gopalakrishnan, Accessibility Expert explained in DevTestNorth’19[v] that customers (with disabilities) are recommended to engaged(in UAT Accessibility Tests) even after QAs get ‘accessibility’ tested in test environments. Reason being, users with disabilities know better about their challenges than anybody else!

Final Words

Web accessibility testing is all about verifying a website using the keyboard without a mouse and hearing the voice over through screen readers(assistive tools) such as JAWS,NVDA etc. Because the majority of the users with special ability, rely on screen readers and keyboard strokes (such as ‘Tab’ to move from link to link) to interact with websites;

Everyone needs accessibility at some point in their life-let us take responsibility to help global community by learning accessibility and find maximum possible accessibility defects and importantly get them all fixed to give a fair and great experience to users with disability-In fact, help others to help yourself!

Manual testing going to remain strong and exist in the form of accessibility testing; It is evident that anyone learning accessibility testing would have a high demand in the job market near the future.

Complete and Continue