Comments on: Quiz 4.1.4: JavaScript - Part 1: Navigating links

By: Bob Easton

Bob Easton — Fri, 29 Jul 2005 10:49:21 +0000

Multiple runs through the test cases might be useful. Letting a screen reader run in straight-through reading mode causes each of the first 6 links to be spoken and may or may not generate events for the log.

Tabbing along in interactive reading mode generates very different events for the log.

I certainly hope some proficient screen reader users run the tests. They are likely to produce more interesting results than those coming from this amateur user who fumbles around a lot.

Something tells me we’ll have a great deal of head scratching as we review the logs.

By: Bob Easton

Bob Easton — Fri, 29 Jul 2005 11:00:24 +0000

When submitting my tests, I appended my name in the input field so they’ll be easy to correlate with these comments. Others can do the same if they please.

My IBM HPR 3.04 tests were done solely within that tool without any other browser. I used HPR in text reading mode, no display of graphics.

Jaws 6.1 was used to read material displayed in IE 6.0.

Window Eyes 5.0 was used to read material displayed in IE 6.0. This one is the most difficult for me because I’ve never been able to fathom how to use it . I gave up trying to get to the input field with keyboard operations and used the mouse

All tests run on WinXP Pro.

By: Yvette

Yvette — Fri, 29 Jul 2005 12:04:39 +0000

At the end of the test it says to use the back-button to review the logs collected during the test, but when I return to the previous page the text area has been deleted and all is has is a document.focus.

I use FF 1.0 on WinXP pro

By: Bob Easton

Bob Easton — Fri, 29 Jul 2005 13:47:10 +0000

Yvette, Yes, you’re right. Going back clears that field. Sorry for the poor advice. You can always look at (listen to) the field before pressing the submot botton. I’ll edit the page. Thanks for bringing it to my attention.

By: Becky

Becky — Mon, 01 Aug 2005 14:20:46 +0000

This was interesting. I got very different results using the WindowEyes 5.0L beta with IE and with Firefox (Deer Park Alpha 2 beta dated 7/21/05). The Firefox page worked better than the IE one in Firefox! I did have a bit of difficulty with link 8 - alt-enter in FF with WE made me lose focus to I had to tab back to link 8 to complete the shift-enter test.

By: Kristin

Kristin — Thu, 04 Aug 2005 02:00:11 +0000

On the second part of the test VoiceOver went to the Accessibility Statement page, so when I hit the back button, I had to scroll through the page again to get to the next test. I am, admittedly, a novice on using screen reader technology. So it may have been an simply an issue of me not knowing the right keystrokes.

By: Bob Easton

Bob Easton — Thu, 04 Aug 2005 18:54:13 +0000

Kristin, that’s an interesting behavior, and I might have an explanation. Link #8 (well, actually all the links) is coded as a reference to “#”, essentially the top of the page. If you travel, or are transported to the top of the page and then activate the first link on the page, you fall onto the Accessibility Statement page.

By: Che Martin

Che Martin — Wed, 31 Aug 2005 01:40:08 +0000

Hi all. I am particularly interested in your findings here. I am a blind php programmer using jaws, and programming games and database functions for the blind. I have recently finished a dice game for the blind, and was hoping to use onKeyDown functions on the page to focus the Jaws cursor to particular lines. For instance, I have a set of headings that show the other players scores, and it would be very useful to the blind player using a screenreader to be able to jump focus to those listings with a keystroke, then back to their own roll with another.
I would be very happy to help with this project as much as I can, which could include asking other blind users to provide feedback or run tests as needed.
I did try some experimentation with the onKeyDown functionality of JS, but with little success so far. It would appear that a Jaws script would have to be embedded for this to work properly, which would mean altering the default browser scripts for jaws users, and that would be a hard sell to say the least.
I look forward to hearing from any and all of you, and thanks for looking into this complication of screenreader usage.
Sincerely,
Che Martin

By: programming

programming — Thu, 09 Feb 2006 02:33:19 +0000

Hi, I thought I’d just leave this message on your blog. I hope you don’t mind. I’ve been trying to find blogs where people are talking about programming and when I was looking, I found this one on you article. thought I would say hi, before I go off to find some more info on this field.

By: Fernando

Fernando — Fri, 03 Mar 2006 02:14:55 +0000

Not a screen reader, but- Lynx for windows displays both the hidden labels and the hidden paragraph. Both appear as if they were normal in every possible way.

By: JavaScript and Screenreaders - The Web Standards Project

JavaScript and Screenreaders - The Web Standards Project — Wed, 10 May 2006 06:46:27 +0000

[…] In the first test case exploring JavaScript and screen readers, we’re looking at some basic events. We’re not exactly sure what we’ll find - and that’s the point, really. We need to start with the basics before we can get very far into the advanced stuff. Hopefully this test will serve as a baseline for comparison as we move forward. This information will be incredibly useful to both the DOM Scripting Task Force and the Accessibility Task Force. […]

By: vikas

vikas — Sat, 23 Feb 2008 03:28:07 +0000

Would u tell me how to test javascript working (test cases) as a software tester