Testcase for Javascript, Accessibility and .NET
I was commenting only the other day that there were some problems with .NET and accessibility because of the way in which .NET uses javascript to carry out postbacks to tell the server to carry out updates on the web page. As I said then, this isn’t Microsoft’s fault — they are working within the limitations of HTML which really only provides for contacting the server on pressing a button or clicking a hyperlink, and .NET allows you to do server updates in more circumstances than this.
I personally could happily do without the rest of the javascript features, but the postback one is really, really useful. However obviously if you provide functionality which requires javascript and doesn’t have an equivalent unscripted option — which you can’t do for a postback — you are in breach of WCAG 6.3, and therefore can’t produce a site that meets even conformance level single A.
And yet, it’s possible that the majority of assistive technologies will be able to carry out this task. I was having a discussion with Robin Christopherson of AbilityNet and he pointed out that the only way to accurately test whether or not assistive technology works would be to actually carry out the testing.
So here we have it — my testcase — please note that this requires javascript and is therefore one of the exceptions to my site’s normal accessibility policy.
Hello. I am 
Just testing the accessibility of do postback functionality.
Server Application Unavailable!
Grant Broome has carried out some testing using JAWS 7.0, and both test cases seem to be fine using this. I’ll spare you the technical descriptions and just leave you with this:
Hi,
The first test case worked fine for me but the second one didn’t.
I am using JAWS 7.0 and Microsoft Windows XP Professional and Internet Explorer 6.0.
When I checked the first check box and the information got updated JAWS read the updated information. However in the case of the second check box, JAWS only read the change in the state of the check box may be because of the heading and read the entire page again.
Ideally JAWS should have read the data table that is added on the page.
In addition would like to make a suggestion label for a check box generally appears to the right of the control as per normal conventions. This is what I feel, I am an individual with low vision and found it very confusing at the start.
Anyways it was a good attempt…
Priti,
sorry - it did actually work. In the second case it was actually intended that the entire page was read again. I appreciate that not that much actually changed on this page but in theory the second check was to allow a postback to the same page with significant differences where you would want the entire page read again!
Priti:
also good point re: the checkbox labelling…
Jack - this tool appears to address this problem, at least in part:
http://www.ajaxium.com/ajax-for-asp.net.aspx
Ajaxium automatically downgrades to a traditional ASP.NET application for visitors whose browsers don’t support JavaScript, XML over HTTP, or whose JavaScript is disabled.
[...] agents. For example, Microsoft .NET uses javascript to carry out a “postback” which my limited testing has suggested is certainly supported by at least some assistive user [...]