JAWS Demo -- its about to expire
Home / Site Building & Testing / JAWS Demo -- its about to expire
I had responded somewhere indicating that we could easily use the demo version of JAWS for doing minor testing (think "how will Jaws react to this bit of code with display:none?") The rebooting after 40 minutes is a minor inconvenience if you are lucky enough to have a "spare" machine to be able to use for testing. This has been successful for me for quite some time, and it has allowed us to do basic testing that we might otherwise not be able to complete.
Today, when attempting to test a code snippet, I started the Demo of JAWS and was greeted with:
| Quote: |
| Thank you for using this JAWS for Windows demo. You have 2 days remaining. Call your local access technology dealer or contact Freedom Scientific... |
Not wanting to wait two more days, I changed my computer's clock to be a week from now, and started JAWS. I was greeted with:
| Quote: |
| JFW will not speak in restricted mode |
So, it appears time is up. I've had it installed since April 2003, so its going on almost 8 months now. I'll be cleaning it and reinstalling to see how that works and I'll report back.
Anyone else been through this yet?
feather.
I'm starting to veer further towards the school of thought that says, don't test in individual screenreaders - because you probably don't use them like their actual users do, and so the results you get may not reflect what end users get, or anything like. Better then to use something like Lynx to do serial-access testing, and a CSS-aware but non-javascript browser to represent environments where hidden content is permanently hidden.
And anyway it's a nightmare, given that there's virtually nothing you can do to feed content only to screenreaders, it just creates frustration - I think this is another situation where the right thing to do is use valid semantic code, and what individual UAs do with that is not our responsibility.
Screenreaders are what you might call "pragmatic user agents" - designed, like SE robots, to work with what's actually out there - so it's arguably better for the vendors, and ultimately the users, if we do nothing to optimise our pages for them, but rather let them optimise the software to what we do - valid semantic coding.
When I use a reader myself I prefer HPR, even though I know it's technically inferior, it's much easier to use and suits me just fine for audio surfing, and as a lower denominator than JAWS, is arguably better for accessibility testing anyway.
Incidentally - have you noticed CSS display/visibility differences with J5.0 - it can't see hidden elements, where 4.51 could? Honestly .. it's harder to keep up with than gecko rendering quirks
| brothercake wrote: |
| I'm starting to veer further towards the school of thought that says, don't test in individual screenreaders - because you probably don't use them like their actual users do,
|
the solution is, of course, to spend some time learning basic use of JAWS. i'm in the process of writing a quick "idiot's guide" with basic operations and keyboard shortcuts for minimal web browsing...watch this space.
| Quote: |
|
Incidentally - have you noticed CSS display/visibility differences with J5.0 - it can't see hidden elements, where 4.51 could? Honestly .. it's harder to keep up with than gecko rendering quirks |
it's the same as writing to web standards for visual browsers: in theory we should just go by the book (i.e. the specs at W3C), and all browsers should display pages the same way and behave consistently...but unfortunately we still have to do at least minimal testing in IE, Mozilla, Opera and co. to ensure sites actually work. the same goes for screenreaders. as with the example of visual browsers, though, there is a difference between "testing in" (which should be done whenever possible) and "coding for" (which obviously goes against the idea of making universally accessible sites).
getting back to the topic of the JAWS demo timing out: i for one was never a fan of the "let's use the demo" solution...it's certainly in a legal gray area, as the demo is explicitly provided as an evaluation to influence a firm purchasing commitment.
_________________
Patrick H. Lauke / webmaster / University of Salford
co-lead: WaSP Accesibility Task Force
take it to the streets ... WaSP Street Team
personal: splintered | photographia | redux
co-author: Web Accessibility - Web Standards and Regulatory Compliance
All times are GMT
You cannot post new topics in this forumYou cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum



