Watchfire: WebXACT
Home / News & Resources / Watchfire: WebXACT
A nicely thought out piece from Mark Pilgrim on the new release of Bobby.
And not very encouraging
Watchfire's fault not Mark's.
Why they would even consider using JavaScript in their reports completely baffles me. There is absolutely no need for it.
Cheers,
Nigel
_________________
Nigel Peck / MIS Web Design
Share: 
Hmm, quite a useless piece of kit, really
Any ideas if Watchfire is open to developer suggestion?
Instead of sitting back, it would be more productive to let them know of the issues we're witnessing
_________________
Designory :: Design & Marketing
tel: (0845) 056 8392
www.designory.co.uk
Share:
I don't have any info or time, if you have the time then good luck 
You could suggest they run the site through Bobby
Cheers,
Nigel
_________________
Nigel Peck / MIS Web Design
Share:
| designory wrote: |
| Hmm, quite a useless piece of kit, really
Any ideas if Watchfire is open to developer suggestion? Instead of sitting back, it would be more productive to let them know of the issues we're witnessing |
I have sent a note to various contacts I have at Watchfire and have asked them to comment directly back to the forum or if they don't want to register and take part in discussions, to reply directly to me and I will post back here.
_________________
Build Your Own Web Site the Right Way!
A beginners' HTML/CSS book with web standards at its heart
The Ultimate HTML Reference
A complete reference, in glorious hardback
Share:
Great, hope they come back with something _________________
Nigel Peck / MIS Web Design
Share:
I have received an officially agreed statement from Watchfire, which is detailed below. I also received an off-the-record response that I can't put here - it was private, after all - but let me just say that it showed that there are people at Watchfire who do care about these issues and that it's not some faceless corporation that won't entertain queries of this nature.
Anyway, here's the official response - and the person who sent me this from Watchfire has said that they are keen to get reponses "If we do hear of actual problems (not just test situations where someone turns of JavaScript to prove a point) I want to know about them so I can use them as ammunition in the lobby to get this changed"
| Quote: |
| WebXACT does violate WCAG 1.0 Checkpoint 6.3. It is in large part because of this that Watchfire has delayed a complete replacement of the older Bobby service (http://bobby.watchfire.com/) with the new WebXACT service, and for some time now we have been running both. We hope that most users will see the advantages of WebXACT, but Bobby is available for those who need a tool that does not depend on client side scripting.
The reason WebXACT has this problem is that the majority of its functionality comes from code it shares with WebXM, Watchfire's enterprise Web evaluation tool. WebXM was written before there was an accessibility specialist on staff to advise the organization about this kind of issue. Unfortunately, the dependence on client side scripting is so deeply embedded into the product that Watchfire has not yet been able to remove it, in spite of the fact that most of the script used in WebXACT does not add functionality that would require scripting. It has been Watchfire's hope that, although this is a technical violation of WCAG 1.0, it does not actually impede accessibility for today's technology. The WCAG 1.0 requirement that pages function without script support was written at a time that client side scripting was new and many assistive technologies did not support it. The best data we have been able to gather indicates that now all or nearly all technologies used by people with disabilities support client side scripting, and WebXACT has been determined to be accessible in an environment that supports scripts. We seek feedback about this so we can make the best decision possible about the product. It is also worthwhile to point out the approach in the next version of the Web Content Accessibility Guidelines, in the development of which I am an active contributor. In order to be more timeless, WCAG 2 is not bound to the functionality of user agents at a given point in time. All the details are still being worked out, but we expect it will be possible to achieve a WCAG 2-conformant site that requires client side scripting, as long as the script, when operating properly, is itself accessible. Scripting is one of several WCAG 1 requirements that turned out to be too tied to a particular moment in history, so we find ourselves turning to WCAG 2 more and more. It is perhaps unfair to justify a violation of present guidelines on the basis of guidelines that do not exist yet, but at least the decision has been taken on the basis of best available information from current work in the field of accessibility. |
_________________
Build Your Own Web Site the Right Way!
A beginners' HTML/CSS book with web standards at its heart
The Ultimate HTML Reference
A complete reference, in glorious hardback
Share:
| Quote: |
| ... WCAG 2 is not bound to the functionality of user agents at a given point in time. All the details are still being worked out, but we expect it will be possible to achieve a WCAG 2-conformant site that requires client side scripting, as long as the script, when operating properly, is itself accessible. |
I am curious about part of this quote - it almost seems to say that WCAG-2 will require client-side scripting which I don't think is true but I can't seem to interpret this statement any other way.
Someone help?
_________________
Jules
Share:
| Jules wrote: | ||
I am curious about part of this quote - it almost seems to say that WCAG-2 will require client-side scripting which I don't think is true but I can't seem to interpret this statement any other way. Someone help? |
I'm not 100% sure, but I interpreted the statement (not WCAG 2.0, but that statement quoted above) as saying: we believe we can conform to WCAG 2.0 as long as any required client side scripting works properly and is accessible when it is working.
Delving a little deeper into the WCAG 2.0 Draft, I see a few things:
Currently Checkpoint 6.3 (a Priority 1 checkpoint no less) of WCAG 1.0 says:
| Quote: |
| Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page. |
Viewing the correlation and checkpoint mapping of WCAG 1.0 to WCAG 2.0 indicates that this will now be dealt with by checkpoint 4.2 (an EXTENDED checkpoint):
| Quote: |
| Checkpoint: 4.2 [EXTENDED] Technologies that are relied upon by the content are declared and widely available. |
Checkpoint 4.2 Extended indicates:
| Quote: |
| Required Success Criteria for Checkpoint 4.2
1. the Web resource includes a list of the technologies users must have in order for its content to work as intended. Users who do not have one or more of these technologies can still access and use the resource, though the experience may be degraded. |
This is where I think they may have misinterpreted -- I know I did upon first read... however, it seems to me the key is "Users who do not have one or more of these technologies can still access and use the resource, though the experience may be degraded"
So, even if they list JavaScript on the list of technologies that a user should have for the resource to work as intended, absolute reliance on JavaScript for navigation (through javascript: pseudo-protocols in hrefs for example) would not meet this requirement and therefore not be in conformance.
The way I interpret it, they would still need to be able to provide functionality so that users that don't have their "required technology" can still use and access the resource. Interpretations of "use" and "access" may be very different -- I'd take it to mean not relying on JS for navigation etc... others may interpret it as "provide a text based version".
Just some meanderings -- I'm not sure that I like the wording of the WCAG 2.0 draft -- upon first read, I wasn't sure what they were saying in that checkpoint either. In fact, I'm still not 100% sure, but at least I think I know what the intent was...
EDIT: I'm just hoping others don't read it and try to use it as an excuse to "get out of extra work" so to speak... taking what they believe to be the "easy way out" rather than actually dealing with accessibility issues...
Feather.
Share:
I haven't even tried to peruse the WCAG 2.0 Draft documents but I think I understand what you are saying and your quotes are saying too. For me, the most telling point is the phrase "though the experience may be degraded" - is non-functional within the realm of degraded? I don't think so and I will freely admit that I haven't visited Watchfire with JS disabled so I don't know what effect it would have. However, if the lack of JS renders the Watchfire application unusable, this is more than degraded. I consider image rollovers (ie. JS equivalents to :hover) to be acceptable but beyond that, one has to be careful._________________
Jules
Share:
From reading the "Checkpoint 4.2 Extended" I think is it quite clear that a page should be still functional without the use of JavaScript or than an alterative solution may be provided of a similar functionality.
Indeed it does look like they have misinterpreted the guidelines believing that giving a minimum browser specification will suffice. Basically even the W3C example strongly suggested in its 'online store' example by following that route people are less likely to revisit the site for e-commerce if they cannot interact with the site via their chosen user-agent.
_________________
};-) http://www.xhtmlcoder.com/
WVYFC chose the Yorkshire Air Ambulance as the main charity to fund raise for in 2006
Share:
I can buy web hosting at Cornerhost.com without turning on Javascript.
I can buy high-speed internet access from my friendly local cable monopoly without turning on Javascript.
I can buy a computer at Amazon.com without turning on Javascript. Hell, I can buy a computer at Amazon.com with Lynx.
But once I spend all that money, I can't check my own site for accessibility with WebXACT's accessibility checker without turning on Javascript.
I did not turn off Javascript to "prove a point". I turned off Javascript because 13% of the world browses without Javascript. This is *up* from 11% last year. (source: http://www.thecounter.com/... ) Once again, the accessible solution turns out to be the right solution. No site should require Javascript. Most sites don't. If your site does, your site is broken. This applies equally to anyone, but it is especially pathetic when the site we're talking about alleges to be an accessibility checker.
WebXACT needs to wake up to reality, fire all their web developers who don't know how to create *a simple link* without Javascript, and come back with a version 2.0 that works in Lynx.
Share:
First of all I'm pleased to see that Watchfire have taken the time to respond to this and thank them for their response.
I agree with Mark (f8dy) on this one, as I said at the start of this thread, there is no need for JavaScript for this, the fact that it's based on their previous systems that were built that way is no excuse.
If it's not up to being a release then I don't see any reason to release it, it needs sorting out to be fully functioning without JavaScript, end of story.
It's not as if they are a small operation with a tight budget who need some recognition and funding in order to develop it further, Bobby is without doubt the most well known Accessibility checker that exists, and new versions should be implemented in a way that reflects that status.
Cheers,
Nigel
P.S. Even if the WCAG 2.0 do say that a Web app can be classified as Accessible when features rely on JavaScript (I'm not saying they will and as they don't exist yet I can't, a draft is a draft) surely Watchfire would want their Accessible Checker to be Accessible to all users regardless of JS?
After all it is the first thing most people think of when they think of accessibility, that kind of status comes with a level of responsibility in my opinion.
_________________
Nigel Peck / MIS Web Design
Share:
I'm the guy from Watchfire whose response Ian forwarded. There's not much more I can add about WebXACT, but there seems to be some confusion about what I said about WCAG 2.0 guidelines. First, I should disclaim that although I work with the Web Access Initiative I don't speak for them. I can only reflect my interpretations; one of the challenges of developing the guidelines is making sure they are written to be uniformly interpreted.
As was pointed out, WCAG 2 checkpoint 4.2 does require that pages be usable with technologies turned off. However, this is an extended checkpoint, which means it is not in the minimum requirements. My interpretation is that it is preferrable for a page to be functional with technologies like JavaScript inoperable, but not required if you are just targeting minimum conformance, as we expect many organizations will do. This is a change from WCAG 1.0 where this was a priority 1 checkpoint.
It is tough for me to speak to the merits of this. On one side, I understand that accessibility involves supporting user agents that do not yet support the latest technologies. This is why it was priority 1 in WCAG 1.0. On the other hand, it probably isn't practical, for the rest of time, to require that all sites be functional in the absence of any technology later than HTML 1.0. At some point we have to be able to say, "new technology X is now widely supported and has accessibility features, so we don't need to require a site be functional if technology X doesn't operate". Where we draw that line I don't know, nor how. WCAG 1.0 drew it at HTML 4.0 plus CSS 2.0 sort of. I'm hearing from this forum a great concern that JavaScript is not yet ready to be included in the list of technologies. I will raise the issue in my work with W3C but one way for people here to make the concern visible is to discuss it on the WAI interest group mailing list - w3c-wai-ig@w3.org.
WCAG 2 is also not final, so while I speak to a particular draft, requirements may change at any time. This is the time to raise concerns with the W3C about any problems in the drafts, before they grow roots.
Share:
Hi Michael,
Thanks for joining us. Does Watchfire intend to update WebXACT so that it will be fully functional without JavaScript in the future?
I know you said in your first response:
| Quote: |
| Unfortunately, the dependence on client side scripting is so deeply embedded into the product that Watchfire has not yet been able to remove it... |
Which I think implies that you are intending to remove it ('not yet'), but I wanted to clarify.
Cheers,
Nigel
_________________
Nigel Peck / MIS Web Design
Share:
Unfortunately right now I can't make a commitment one way or the other, it may get fixed in the future but right now there isn't a schedule for it. Sorry that's all the information I have right now.
Michael
Share:
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