Curated by T Ashok @ash_thiru
Summary
Evaluating accessibility by using only able-bodied people(testers) or by enabling accessibility only via use of checklists are not useful. The simplest tests to ensure a complex application is well covered via ‘only testing using the keyboard’, ‘relying on the spoken word to navigate’, ‘using high contrast mode of display’ & ‘disabling certain options in the browser’ (for web apps). This article is curated from four interesting articles.
Valid experience is vastly more important than mere simulations. Accessibility testing really isn’t so different than surgery in this regard. You want a team chock full of people who are “native users of assistive technology” (which is the nice way of saying “disabled”), and not people simulating disabilities.
says Sheri Byrne-Haber in her interesting article “Make People with Disabilities Part of your Accessibility Testing Program”.
Why would that be? Here are some of the key reasons:
Running an accessibility testing program without people with disabilities is disrespectful “..at the end of the work day, those non-disabled testers get to go back home to their abled lives. They do not experience the day-in, day-out 24×7 frustration of someone with a disability slamming head first into either digital or physical barriers every single day.”
Running an accessibility testing program without people with disabilities is neither inclusive nor diverse “…no one can legitimately claim that testing with completely able bodied testers will give you the equivalent experience of a population of people with varying degrees of disability.”
Running an accessibility testing program without people with disabilities is neither inclusive nor diverse “…not considering or using people with disabilities in your accessibility testing program is deliberate and discriminatory exclusion, the opposite of being diverse and inclusive. ”
Do read the full article here (5 min read)
In the article “Accessibility Checklists — Just say No”, Sheri Byrne-Haber says in the long run, general accessibility checklists do far more harm than good in establishing a good accessibility program as:
- Checklists are part of a reactive, not proactive accessibility practice
- Checklists are a black and white solution in a sea of gray
- Checklists do not motivate people to think neutrally or positively about people with disabilities
- Checklists are a crutch
- Checklists put blinders on users
- Checklist items open to interpretation create more problems than they solve
- Checklists don’t lead to an inclusive culture
“Design for accessibility, train everyone who touches the content and infrastructure, and include people with disabilities in every step of the path including research and testing” is what the author concludes at the end of the article.
In the article “Three tests for accessibility“, Jonathan asks the question “given that there are so many criteria for good accessibility, and that the application itself may be complex in many ways, how do we verify that all parts of the application are accessible?” and outlines three simple tests to accomplish this:
- Screen-reader-only test : Try to use the application, relying only on hearing the spoken word.
- Keyboard-only test : Try to use the application, relying only on keyboard input. Put the mouse away or disconnect it, or disable your trackpad.
- Automated test: Run an automated testing tool on your application, analyse the output and address all major errors detected.
The 6-min read of this article is time well spent.
Continuing on this same train of thought is another interesting article by Karl Groves that outlines the six simplest web accessibility tests. The author outlines these as :
- Unplug your mouse and/ or turn off your trackpad- Interact with the site using only the keyboard.
- Turn on high contrast mode- Colors on the site are essentially removed entirely.
- Turn off images – Images shouldn’t be required to understand the page and shouldn’t be relied upon for important UI controls
- Check for captions or transcripts- If you have media on your site, check for captions, transcripts, and other possible alternatives
- Click on field labels- Issues with forms tend to fall into three main categories: Missing or incomplete labelling, ineffective error handling, and poor focus control.
- Turn off CSS – Presentational methods cannot be overridden by users who’ve created custom style sheets.
Read the full article The 6 Simplest Web Accessibility Tests Anyone Can Do
Click here to read a summary of six interesting articles in accessibility..
About SmartQA The theme of SmartQA is to explore various dimensions of smartness to leapfrog into the new age of software development, to accomplish more with less by exploiting our intellect along with technology. Towards this, we will strive to showcase interesting thoughts, expert industry views through high-quality content as articles, posters, videos, surveys outlined as a SmartQA Digest weekly emailer. SmartBites is “soundbites from smart people”. Ideas, thoughts and views to inspire you to think differently.
Signup to receive SmartQA digest that has something interesting weekly to becoming smarter in QA and delivering great products.
No comment yet, add your voice below!