E-mail List Archives
Thread: Web application testing
Number of posts in this thread: 19 (In chronological order)
From: Tim Harshbarger
Date: Fri, Aug 05 2016 6:40AM
Subject: Web application testing
No previous message | Next message →
I would strongly advocate that you start with automated testing before you even bother with doing any type of screen reader testing.
I think the key is just to ensure that the only tests you automate are always correct. If it says there is a defect, it should always be a defect. That simplifies things a great deal.
While automated testing won't catch everything that manual testing will, it is faster and cheaper to do.
Also, if you are working with other developers, it is a lot easier to teach them how to use the automated tool and its results.
Personally, I think it is essential to test with screen readers if you want to produce high quality user interfaces. However, testing with a screen reader adds a lot more complexity.
To test well with a screen reader, you need to know how to operate it and understand what kind of information it is going to convey if everything is working correctly. One of the tricky parts comes when you run into defects. Most of the time, it is fairly easy to determine if the defect is related to application code. Other times, it is difficult to figure out if the problem is the application code, the browser, or the screen reader.
My suggestion would be to check the code frequently with automated testing and then follow up with screen reader testing less frequently.
Thanks,
Tim
From: Jim Homme
Date: Fri, Aug 05 2016 6:50AM
Subject: Re: Web application testing
← Previous message | Next message →
Hi,
What automation tools do you use?
Jim
=========Jim Homme,
Accessibility Consultant,
Bender HighTest Accessibility Team
Bender Consulting Services, Inc.,
412-787-8567,
= EMAIL ADDRESS REMOVED =
http://www.benderconsult.com/our%20services/hightest-accessible-technology-solutions
E+R=O
From: Jamous, JP
Date: Fri, Aug 05 2016 7:31AM
Subject: Re: Web application testing
← Previous message | Next message →
We use the WAVE toolbar.
I know it only works with Google Chrome for now, but I have not had an issue using it with JAWS.
Since all of our devs use Macs, They install Chrome and add the toolbar to it. That is only for internal pages.
External pages, we use the WebAIM site, which is a wonderful way to automate.
From: Preast, Vanessa
Date: Fri, Aug 05 2016 8:03AM
Subject: Re: Web application testing
← Previous message | Next message →
I've used the following for different reasons. Sometimes I have to check a site that doesn't play well with Chrome or Firefox or IE, so I switch to a different checker depending on needs. Sometimes I'm recommending checkers for others who have certain preferences or system set-ups.
WAVE is my usual go-to tool, with AInspector as second for page-by-page checking. Sometimes WAVE chokes up on our LMS, so I might then see what results the other tools can tell me. I've got a copy of SortSite Desktop by PowerMapper, and will use that for a quick multi-page scan for accessibility and usability issues.
Chrome plugins:
WAVE chrome plugin (https://chrome.google.com/webstore/detail/wave-evaluation-tool/jbbplnpkjmmeebjpijfedlgcdilocofh?hl=en)
aXe chrome plugin (https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd?hl=en)
Web Developer chrome plugin to assist manual check (https://chrome.google.com/webstore/detail/web-developer/bfbameneiokkgbdmiekhjnmfkcnldhhm?hl=en)
Accessibility Developer Tools chrome plugin (https://chrome.google.com/webstore/detail/accessibility-developer-t/fpkknkljclfencbdbgkenhalefipecmb?hl=en)
Firefox Add-ons:
AInspector Sidebar (https://addons.mozilla.org/en-US/firefox/addon/ainspector-sidebar/)
aXe DevTools (https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/?src=api)
Fangs Screen Reader Emulator (https://addons.mozilla.org/en-US/firefox/addon/fangs-screen-reader-emulator/) - writes out what a screen reader would read
Colour Contrast Analyser (CCA) | The Paciello Group (https://www.paciellogroup.com/resources/contrastanalyser/) nice desktop tool to check color contrast on anything on the desktop including contents in a browser, PowerPoints, etc...
SBF Color Contrast Checker / Analyzer includes both HEX and RGB (http://www.sbwfc.co.kr/ColorChecker/)
Screenreader - NVDA (http://www.nvaccess.org/)
Readability: http://www.hemingwayapp.com/ and MSWord readability scores
From: Tim Harshbarger
Date: Fri, Aug 05 2016 8:08AM
Subject: Re: Web application testing
← Previous message | Next message →
I would recommend looking at automated testing tools which have primary goal of reducing the number of "false positives" reported.
The more false positives reported, the less the developers will trust the tool and the more time they will need to spend determining if the reports are valid. The value of automated testing is that it provides quick feedback that can be acted upon quickly.
It isn't that developers should never learn anything about manual testing, but automated testing can take care of many key issues more quickly and more consistently. It can actually make some of the manual testing a bit easier to conduct since you have already eliminated some potential culprits for defects.
Here is another way to look at it.
I can use my screen reader to manually test 10 pages to ensure that controls have labels and names. However, in the same amount of time, I could use an automated test to find those defects and be already fixing them.
This isn't a cure all. Automated testing won't find all the important problems. But it can help with finding some defects faster and fixing them more quickly which can save a project time.
From: Jim Homme
Date: Fri, Aug 05 2016 8:09AM
Subject: Re: Web application testing
← Previous message | Next message →
Hi,
I'm asking because I'm a screen reader user. It appears that the Wave toolbar would be problematic for me to use because chrome interacts badly with both screen readers I use.
Jim
=========Jim Homme,
Accessibility Consultant,
Bender HighTest Accessibility Team
Bender Consulting Services, Inc.,
412-787-8567,
= EMAIL ADDRESS REMOVED =
http://www.benderconsult.com/our%20services/hightest-accessible-technology-solutions
E+R=O
From: Jim Homme
Date: Fri, Aug 05 2016 8:13AM
Subject: Re: Web application testing
← Previous message | Next message →
Hi,
My sighted testers use NVDA silently and turn on the speech viewer and park that in a corner of the screen so they can see the verbalizations.
Jim
=========Jim Homme,
Accessibility Consultant,
Bender HighTest Accessibility Team
Bender Consulting Services, Inc.,
412-787-8567,
= EMAIL ADDRESS REMOVED =
http://www.benderconsult.com/our%20services/hightest-accessible-technology-solutions
E+R=O
From: Jamous, JP
Date: Fri, Aug 05 2016 8:17AM
Subject: Re: Web application testing
← Previous message | Next message →
It does fine with JAWS and Chrome Jim. You just have to follow the execution sequence in order. I have used it internally for demonstrations.
At first, I thought it was inaccessible. Yet, as I gave it its fair share, I noticed it is accessible.
From: Jamous, JP
Date: Fri, Aug 05 2016 8:21AM
Subject: Re: Web application testing
← Previous message | Next message →
Vanessa,
Wow, those are great resources. Thank you so much.
Do they work well with screen readers?
From: Jim Homme
Date: Fri, Aug 05 2016 8:53AM
Subject: Re: Web application testing
← Previous message | Next message →
Hi Jamous,
This is encouraging, because most of the developers I know and the developer books I read use Chrome. It would be nice to use a single environment as I continue learning development.
Jim
=========Jim Homme,
Accessibility Consultant,
Bender HighTest Accessibility Team
Bender Consulting Services, Inc.,
412-787-8567,
= EMAIL ADDRESS REMOVED =
http://www.benderconsult.com/our%20services/hightest-accessible-technology-solutions
E+R=O
From: Jamous, JP
Date: Fri, Aug 05 2016 9:05AM
Subject: Re: Web application testing
← Previous message | Next message →
I will send out the instructions on how to use it. I'll do that over the weekend as I am at work now.
If I do forget, make sure to remind me please.
From: sucharu
Date: Sun, Aug 07 2016 2:34AM
Subject: Re: Web application testing
← Previous message | Next message →
Hi ,
I am still looking for the answer to my question "which browser screen reader combination after initial testing with automated tools". And more important why.
From: Jamous, JP
Date: Sun, Aug 07 2016 6:18AM
Subject: Re: Web application testing
← Previous message | Next message →
To use the WAVE toolbar with Chrome and JAWS 17, perform the following.
1. Install the toolbar
2. Ensure it is displayed on the Chrome UI by pressing the Alt key once and right-arrowing until you hear "Extension WAVE Button Menu"
To check a page:
3. Visit the page, press the Alt key and right arrow to the WAVE button.
4. Press the Space Bar once and wait for about 30 seconds.
5. Press F6 and you will be in the DOM.
6. Down-arrow from the top of the page and you will start reading the summary of the WAVE toolbar.
7. When you are done with the report, press F5 and the page refreshes showing only the page content.
If you press F6 and the report is not there, retry the steps above and give it a bit of more time. It might take the checker some time depending on the complexity of the markup and your computer resources.
From: Jonathan Cohn
Date: Sun, Aug 07 2016 9:30AM
Subject: Re: Web application testing
← Previous message | Next message →
Hello,
You should try as many combinations as you can afford to try, including JAWS 12 Windows XP and IE6. But of course, you probably don't want to do that.
Use JAWS with IE and/or Firefox because JAWS does not work great with Chrome and JAWS is the most popular screen reader.
Use NVDA with FireFox if you have more modern web development because this is generally believed to have the best support for ARIA and HTML 5 accessibility without trying to guess as much what the web developer was trying to do. ,
I believe however, that especially as a sighted tester, you will get more information about issues that are non-automated testing by working with a ZoomText or Magic. Also, please make sure your alt-attributes are spelled correctly.
Since VoiceOver is the only scrrenn reader on the Macintosh, it makes sense to test with that. Also, Voiceover on the Macintosh in "group" mode has a tendency to read "Title" attributes for div tags instead of the content of the div tag. So, this might be a place specifically to test with VoiceOver.
Best wishes,
Jonathan Cohn
> On Aug 7, 2016, at 4:34 AM, sucharu < = EMAIL ADDRESS REMOVED = > wrote:
>
> Hi ,
> I am still looking for the answer to my question "which browser screen reader combination after initial testing with automated tools". And more important why.
>
From: Tim Harshbarger
Date: Mon, Aug 08 2016 7:22AM
Subject: Re: Web application testing
← Previous message | Next message →
There is not a single answer to this question. You will probably get different answers from different people. Each of those answers are likely good ones, but may only best apply to their situation.
The right answer for you is going to involve balancing the results you want to achieve with the cost and time it is going to add to implementing the application.
Every browser and screen reader combination you add to your testing increases the time it takes to complete the work and the number of potential defects you will need to work through. Not to mention that the people testing with the screen reader will need to be somewhat knowledgeable about the screen reader.
And as you might have noticed, people are also mentioning testing browser/screen reader combinations using different versions of screen readers and browsers. And that increases the complexity of the question.
You really need to start by deciding what your goal for accessibility testing is and estimate how much time and cost can you spend on that piece. Is your application available both for desktop and mobile? Which browsers do people most frequently use to access the application?
Who is your audience? Which screen readers are likely to be available to them? In a closed environment, everyone might be using just one or two screen readers. In an open environment, which screen readers might be used most frequently?
Is your goal to conform with WCAG 2.0? Then maybe you want to consider which browsers and screen readers provide you the best opportunity to do that without a lot of hacks.
Perhaps, you decide just to start small with a single browser and screen reader--and look at adding others over time.
There are a couple pieces of advice I would personally add...
Start with the assumption that you will never have an application that is 100% free of accessibility defects. During every iteration of the application, you need to aim for fixing whatever accessibility defects you can fix for that iteration. Know that some defects are going to get through. But your plan is to catch them in the next iteration. You will ultimately find that as technology and techniques change, you will find new defects or realize there are now better ways to fix old defects.
The second piece of advice I have actually comes from my father who use to be a lead tester for a large complex system for a few decades. The key purpose of testing is not to let any of the big or nasty defects through. As long as your testing can catch those types of defects and you can ensure they are fixed before your users has to deal with them, you are doing good. Repairing more defects than that would be even better. Repairing all the defects would be grand. But catching and stopping the defects that prevent people from being able to use your app is essential.
If you are just starting your testing, chances are you will find a lot of those "big" defects and you will want to spend most of the effort clearing those out. Over time, you might see less of those and find yourself with more time to go after other less critical but still important defects.
Thanks,
Tim
From: Jamous, JP
Date: Mon, Aug 08 2016 7:41AM
Subject: Re: Web application testing
← Previous message | Next message →
Tim,
Amen to what you said brother.
I was like that when I first started in the corporate world. I wanted to get every screen reader/Browser combination tested. I noticed that the more dirt you add to the water the muddier it will get and you lose focus and clarity of the situation.
That was why, we decided to focus on:
JAWS/Internet Explorer
NVDA/Firefox
VoiceOver/Safari
With the above we test for all latest versions as the latest would allow us to overcome certain bugs on the screen reader side.
We have a way to tackle bugs on our side:
1. Blockers - Issues that block the user completely from using the site or app.
2. Critical - Issues that almost block users, but might have some work-around for them.
3. Major - Issues that can enhance efficiency and productivity of the user.
4. Minor - things that could be done to improve the user experience.
Pay attention to the word, things. In the Minor category we do not have issues at all. Just things to improve based on UX and not WCAG. WCAG kicks in from the Major category and higher.
Do yourself a favor and focus on KISS-Keep It Simple Stupid. Our devs aren't blind and do not care to use a screen reader. We have collaborated with them to include screen readers in their testings and different people reacted to it differently. Some were all about it, while others do not like it and don't care. However, they have to care if they want to keep their jobs though.
So as you see it is an uphill battle. That is why you have to simplify it and tackle it based on your users' requirements priorities and other categories that you might find useful to your situation.
There is no one standard that is perfect to all situations. Each situation is unique and its requirements and priorities are different from the rest.
From: Jim Homme
Date: Sat, Aug 13 2016 12:32PM
Subject: Re: Web application testing
← Previous message | Next message →
Hi Vanessa,
How do you like the reports from PowerMapper?
Thanks.
Jim
=========Jim Homme,
Accessibility Consultant,
Bender HighTest Accessibility Team
Bender Consulting Services, Inc.,
412-787-8567,
= EMAIL ADDRESS REMOVED =
http://www.benderconsult.com/our%20services/hightest-accessible-technology-solutions
E+R=O
From: Bourne, Sarah (MASSIT)
Date: Tue, Aug 16 2016 7:00AM
Subject: Re: Web application testing
← Previous message | Next message →
Dylan Barrell covers coming up with a "sparse testing matrix" in his talk, Taming the Beast: Agile and the Automated Testing of Accessibility. (On Vimeo with captions: https://vimeo.com/151658306 ) Starting at 11:45, Dylan discusses the huge range of technologies that need to be considered, and the ridiculous number of OS/browser/AT combinations that results in. At 15:05, he shows the matrix he uses to figure out the combinations you actually need to use to find the most problems with the fewest tests.
Dylan presents this in terms of agile development, where there's a LOT of testing done frequently, so you may find his sample matrix too sparse in other situations. For example, you would want to expand it for an audit test or as part of usability testing. But at some point, all you're going to turn up is browser or AT specific bugs, rather than bugs in what you're testing. You may need to know about them, but there's not much you can do about them.
sb
Sarah E. Bourne
Director of IT Accessibility, MassIT
Commonwealth of Massachusetts
1 Ashburton Pl. rm 811 Boston MA 02108
617-626-4502
= EMAIL ADDRESS REMOVED =
http://www.mass.gov/MassIT
From: _mallory
Date: Tue, Aug 16 2016 9:15AM
Subject: Re: Web application testing
← Previous message | No next message
There was a similar talk at CSUN but unfortunately no video, just
http://www.csun.edu/cod/conference/2016/sessions/index.php/public/presentations/view/246
the abstract and
http://www.slideshare.net/MarkStimson1/transforming-novices-into-skilled-accessibility-testers-csun-2016-60188894
the slides
Mark Stimson at Kaiser Permanente. When about to launch a large
mobile-based version of all their everything, wanted to let QA
also be able to flag accessibility errors instead of relying on
their small number of a11y experts.
His talk was about how they did that: QA was often contractors who
may be gone after 8 months, so it had to be something they could
learn to do quickly. They devised a few-hours-long training program
for every QA person to learn VoiceOver, and then using a 3 x 3 grid,
QA could find some 90% of issues (which hit both mobile and desktop)
and the accessibility specialists found the remaining ones.
_mallory
On Tue, Aug 16, 2016 at 01:00:49PM +0000, Bourne, Sarah (MASSIT) wrote:
> Dylan Barrell covers coming up with a "sparse testing matrix" in his talk, Taming the Beast: Agile and the Automated Testing of Accessibility. (On Vimeo with captions: https://vimeo.com/151658306 ) Starting at 11:45, Dylan discusses the huge range of technologies that need to be considered, and the ridiculous number of OS/browser/AT combinations that results in. At 15:05, he shows the matrix he uses to figure out the combinations you actually need to use to find the most problems with the fewest tests.
>
> Dylan presents this in terms of agile development, where there's a LOT of testing done frequently, so you may find his sample matrix too sparse in other situations. For example, you would want to expand it for an audit test or as part of usability testing. But at some point, all you're going to turn up is browser or AT specific bugs, rather than bugs in what you're testing. You may need to know about them, but there's not much you can do about them.
>
> sb
> Sarah E. Bourne
> Director of IT Accessibility, MassIT
> Commonwealth of Massachusetts
> 1 Ashburton Pl. rm 811 Boston MA 02108
> 617-626-4502
> = EMAIL ADDRESS REMOVED =
> http://www.mass.gov/MassIT
>
> > > >