A lot has been realized by most of us regarding the Accessibility of the application. There are different standards, laws and guidelines to help every one of us in building a product that provides equal opportunities to everyone in this society e.g. WCAG 2.0, Equality Act 2012, BS 8878, etc.
Rather than considering this as some form of enforcement on us, we need to understand the benefits associated with being accessibility compliant. But before this, let us look at few myths associated with accessibility:- Accessibility gives what is needed by people with special needs and elderly people.
Accessibility means providing great user experience, enjoyment – fun of use & right value of our product to disabled people.
- In journey of accessibility compliance, web sites should follow WCAG 2.0.
WCAG is useful for techies / designers in building the website. WAI docs are useful in getting how disable people use net & for mobile site creators, browser developers, etc.
Along with such initiatives a standard like BS8878 is useful – as it provides entire process of how we should follow and maintain accessibility compliant web sites and associated tests.
- There is not much ROI / What will be the return on investment?
The population aware of internet and using sites / apps for their regular tasks is increasing regularly. It is advisable to build accessibility compliant product.
A joint study by Microsoft and Forrester conveys that- huge number of people are likely to be benefited from use of Accessible technology.
- There is no need to perform separate testing for accessibility once the compliance / standard is followed.
Quality is conformance to the requirements; following the standards is not sufficient - unless the impact of compliance (during the development) is validated on different browsers.
Testing accessibility
This needs to be addressed case by case; however what all would like to understand is a common high level approach that can be used for accessibility testing.
This involves creating two fold matrix of your product.
Matrix – 1: Map the pages based on the level of compliance or type of accessibility solutions expected.
Matrix – 2: Map the pages to the checkpoints – this provides the details picture of which page should comply with which checkpoint.
For accessibility testing, merely validating the checkpoints on one browser is not sufficient; we should validate the accessibility checkpoints / test cases across multiple browsers and platforms.
This is a place where the concept of combinatorial testing is extremely useful. The algorithms provide us the good trade-off between number of combinations and coverage.
Once this framework is ready; it can be implemented on one product or entire portfolio. It is highly recommended to implement this across entire portfolio.
Few tips to remember when we talk about accessibility testing:
- Comes without saying: If it is a web based application or native mobile app, Accessibility requirement comes without saying. In fact – even the desktop applications should be an accessible solution.
- Brings in browser-platform support: the expectations from accessibility compliance automatically bring in the cross platform support for you site.
- While testing the site – follow a thumb rule that the entire site should be accessible only with keyboard!
- You should test multimedia pages without speakers … even if it sounds silly; this is the best possible way to identify and highlight the importance of text-video relation.
- Do not rely on results of one tool.
Typical activities in the test strategy:
- Static testing of code (for accessibility provisioning)
- Browser testing – manual (checkpoint validation)
- Check the pages without loading any image on the page
- Use combination of tool driven tests and manual testing (online tools, JAWS, WAT 2.0).
Fitting this entire framework in your structured testing and risk based testing if obvious activity.
We do get a question sometimes that how do we test accessibility in agile world ... Is agile world different as far as accessibility compliance is considered? Absolutely not. Merely, look at it as fitting the above framework in another framework (related to agile methodology). It is advisable to move upstream in case of accessibility testing (like any other testing). Jointly with developers - identify which type of test will add value upstream and then just 'add those cases'.
