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.
Robin says:
October 3rd, 2006 at 4:28 pm
Just testing the accessibility of do postback functionality.
Gavin says:
October 4th, 2006 at 12:55 pm
Server Application Unavailable!
JackP says:
October 10th, 2006 at 10:07 pm
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:
priti says:
December 12th, 2006 at 5:18 am
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…
JackP says:
December 12th, 2006 at 7:47 am
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!
JackP says:
December 12th, 2006 at 7:47 am
Priti:
also good point re: the checkbox labelling…
Ian Sparham says:
May 2nd, 2007 at 10:41 am
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.
ThePickards » Blog Archive » Be Accessible, Don’t Meet Guidelines says:
May 7th, 2007 at 4:06 pm
[...] 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 [...]