Quiz 4.1.4: JavaScript - Part 1: Navigating links
JavaScript is flourishing everywhere. AJAX is the latest new thing on the web, bringing us a wave of dynamic applications for getting things done. 37 Signals brought us Basecamp and Backpack. Other applications, like Next Action are popping up daily. How well does today’s assistive technology cope with these delightful new applications?
About two months ago, both Mike Stenhouse and James Edwards suggested we do some JavaScript testing here. Then, a few weeks later Derek Featherstone wrote a very interesting article suggesting that people using assistive technology might fare better with JavaScript disabled. At about the time the WaSP was forming the Accessibility Task Force, the four of us agreed to collaborate on testing the accessibility facets of JavaScript with today’s assistive technology.
First, some short introductions: (alphabetic by last name to avoid any favoritism)
- James Edwards - the man behind the [brothercake] web development consultancy. James lives somewhere in what he calls a rural area of Shropshire, UK.
- Derek Featherstone - operates the furtherAhead web development firm and the WATS.ca accessibility consultancy, and lives near Ottawa. We know him as a member of the recently formed WaSP Accessibility Task Force.
- Mike Stenhouse - a freelance web developer living and working in London.
We will attempt to find out what screen readers actually do with various JavaScript events by using a series of test cases which break things down to small test areas. This first case focuses on navigation among links. It handles a range of different keyboard, mouse and UI events, and creates a log of every event that’s recorded, so that we can determine which events are generated by different devices. If a screen reader discovers an event and passes it through it will be logged as normal. If the screen reader does something different, that too will be logged (we hope). At the bottom of the test case, a simple form mails the log back to us where we’ll puzzle over the results.
Don’t worry, we are not collecting anything to do with your identity.
By the way, there are no questions with this quiz, as we don’t yet know the right questions to ask. This one is all about quizzing not you, but the technology. Comments are indeed welcome about behaviors you see or hear as you run the test case.
Thanks in advance for trying the test case in as many assistive technology devices as you can.
July 29th, 2005 at 6:49 am
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.
July 29th, 2005 at 7:00 am
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.
July 29th, 2005 at 8:04 am
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
July 29th, 2005 at 9:47 am
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.
August 1st, 2005 at 10:20 am
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.
August 3rd, 2005 at 10:00 pm
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.
August 4th, 2005 at 2:54 pm
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.
August 30th, 2005 at 9:40 pm
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
February 8th, 2006 at 10:33 pm
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.
March 2nd, 2006 at 10:14 pm
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.
May 10th, 2006 at 2:46 am
[…] 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. […]
February 22nd, 2008 at 11:28 pm
Would u tell me how to test javascript working (test cases) as a software tester