New or old, reading or reviewing the benefits of using standards for business, developers/designers, and users may give many extra incentives or ideas about how to help promote change or learn why it is important.
On September 18, 2003 Jeffrey Veen offered up an essay The Business Value of Web Standards. Worth a read for those trying to convince others that using web standards can lead to financial savings at work.
Presented earlier this year, The Business Benefits of Web Standards(Devedge, Published 21 Mar 2003), authored by Tristan Nitot is a good summary and a quick read regarding the use of standards.
Ian Hickson, who was a standards guru before you were a standards newbie, talks about the problems with client-side XSLT. This is a technique which is supposedly supported by all modern browsers -- at least, all modern graphical browsers. But in this case, there is no fallback provided for older browsers, or text browsers such as Lynx (which simply offers to download the raw XML of the page).
The real example that Ian links to (yes, this is being used right now on a commercial newspaper website) works in Internet Explorer, but doesn't even work for me in Mozilla 1.5rc2 (which should qualify as a modern graphical browser, it was released 3 days ago) because of incorrect server-side configuration (MIME type issues).
So basically, this newspaper site has managed to find a way to use web standards such as XML and XSLT in such a way that their site is only available to people running the latest version of Internet Explorer.
Shock, horror! Some people out there think that 'Web Standards' are not the single most important thing to worry about when crafting a web page or site. Well, I can certainly see the argument here:
Web standards can help, and go hand-in-hand with everything else that makes a site a success. They're a big part of a good, professional Web development process. However, it takes much more than Web standards to insure a successful Web site. I would also assert that whether or not a site is tableless or validates, in general, has absolutely no impact whatsoever on the success of a Web site.
It is indeed true that we can all get too hung up on getting the XHTML to be perfectly valid and to worry about the semantics of one tag or another and then totally lose sight of what it was that you were hoping to achieve - a site that many different people would actually want to use. The same argument has been levelled at super-accessible sites that have, in the wrong hands, been turned into something VERY dull because the developer couldn't work out how to achieve aesthetic beauty without sacrificing the purity of the markup.
Let's get things straight - web standards will, to a great many people, mean absolutely nothing. To the average person in the street, they just want to be able to use Amazon or whatever and generally speaking, sloppy coding has not stopped them doing this from one browser to another. Invalid markup? Whatever ... you can still buy a book. Incorrect use of heading tags? Ah, so is that stopping me from finding the DJ Format album? Of course not. BUT ...
The point is that up until now, sloppy practices have been acceptable (as far as browsers are concerned) - in the future this may not be the case, and we must pay attention to standards, otherwise we'll just end up with a fragmented web all over again.
D Keith Robinson states the things that he thinks are more important than Web standards:
- Clear, concise and measurable goals
- A solid information architecture
- Clean, functional and user-centered design
- Well thought-out, audience appropriate content
- Interaction with your users/readers
This is all well and good ... but none of it should be at the expense of web standards; it is possible to achieve all of that AND have a standards-compliant site. But I have to agree 100% with the comment that: "A 100% valid, semantic and tableless site can still be a complete and utter failure."
If you missed Tim Berners-Lee's lecture to the Royal Society, The Future of the World Wide Web, that was webcast earlier this week, it's now available on demand. (Requires RealPlayer plug-in.) He starts out by examining how we got to where we are today and then moves on to look at where we're heading, focusing predominantly on the Semantic Web.
Of particular interest in light of recent patent disputes and royalty issues, Tim repeatedly raises the fact that the Web would not be where it is today had it not been created as an open platform.
So that was the idea of the Web, that it's a universal space and should be able to have anything. And this is the idea of minimal design requirements—imposing minimal constraints on the people who are going to use it or the people who are going to design parts of it. … There are a few constraints you have to work under—there are a few standards. So the whole thing hangs on standards, and if you just go away understanding that, of course, it will have been a wonderfully productive evening.
And later:
We also have tried to set [the W3C] up as a place where the standards could be royalty-free. That whole graph you saw only happened because HTML was royalty-free. All the exciting enhancements which were made to HTML only happened because anybody could take the HTML browser, write a new one in their garage, and then post to the Net their new ideas. So new ideas for how the Web could get better were coming from all over. And they were coming from all over because the initial Web was an open standard.
Make sure you stick around for the Q&A session at the end of the lecture, or you might miss some gems like this one:
Question from Web: How can you let yourself be be broadcast on a system that insists we have IE 5+?
TBL: That's disgusting. That's disgusting. David, would you like to comment about that from the point of view of the Royal Society?
David (emcee): (rather bemusedly) No, I don't know how that's happened.
TBL: Well, actually I was just at the BBC earlier, and I've talked with them about that. And I'll have the same discussion with the Royal Society afterwards. Thanks for that question. I'd point out that the W3C has not been involved in standards that area—in the area of streaming video—and we wonder sometimes if we shouldn't have been.
Incidentally, the audio/video portion worked fine when I viewed it with a recent Firebird nightly, but without the synchronized slide images from the presentation. Those slides are also available from the W3C's site.
Added by lloydi: A related article for you, Net guru peers into web's future - "The inventor of the web, Tim Berners-Lee, outlines his ideas for a more 'intelligent' web in an interview with the BBC programme, Go Digital."
Tables have received so much bad press that some people think they're completely out. Which, of course, is true for last centurie's hodgepodge of spacer-gif-sliced-images-dozens-of-nested-tables nonsense.
But there is a perfectly good use for them, too: Tabular data! And if you want to make your tabular data tables not only standards compliant, but also accessible, this small list of links might help achieve that noble goal.
- Building accessible tables - A nice little introduction by evolt author Tim Roberts. If you think tables are difficult, read this first .
- How to Create Accessible Tables - A detailed "How-to" for both data and layout tables, by webaim author Paul Bohman
- Accessible Tables - Jim Thatcher discusses three simple techniques that make data tables more accessible.
- Techniques for Accessible HTML Tables - Stephen Ferg provides us with a very thorough discussion of techniques for complex statistical data tables. With a focus on current browser support, Section 508 and WAI compliance. This article contains everything you ever wanted to know about tables, and them some.
- Accessible Table Builder - Another fine tool from Accessify. This accessible table builder - guess what! - automagically builds the accessible table for you. No assembly required.
- Tables in the HTML4.01 Specification - Last but not least: The HTML4.01 Specification. Don't leave home without it.
Et maintenant: Bon appétit!
This is one of those 'clearing out your bookmarks/favourites' type posts - a selection of useful articles spotted over the last few days:
- CSS-Based Design - Jeremy Keith of Adactio puts up his notes from the Skillswap talk he gave back in March (better late than never, and it's all good stuff, so we forgive you Jeremey - even the over-enthusiastic use of Matrix quotes).
- Accessible Header Images With CSS And XHTML - Another article explaining the use of CSS to render images in place of
<h1> headers. Have we cracked the problem of accessibility of these solutions? Make your own judgement about that.
- Rounding Tab Corners - a new CSS tutorial from Eric Meyer that explains how to achieve a rounded tab effect using CSS and clever placement of your images. Say goodbye to horribly intricate stretchy-in-parts, non-stretchy-in-others table constructions.
While everyone is trying to take in the implications of the Eolas vs Microsoft case, there are other clouds forming on the horizon that could either develop into a full-blown hurricane or dissipate quietly. Over-dramatic? Only time will tell. The cause of this storm - a tentative proposal from the International Standards Organization (ISO) to raise fees for commonly used industry codes, including two-letter country abbreviations, used in many commercial software products. And, of course, the web.
The standards referred to - ISO 3166, ISO 4217, ISO 639 - cover country, currency and language codes, respectively, all of which are referred to in any number of standards documents drafted by the W3C and others. Until now, In addition, the ISO has not charged for use of any of its codes (for example, within a software application) but does charge copyright royalties for the purchase and reproduction of many of its standards documents.
How does this affect you? Well, if the ISO has its way and software manufacturers are forced to pay for adopting standards, you end up paying for it in higher software costs. Meanwhile web standards are harmed in general if other software manufacturers decide not to pay and instead miss out documenting these standards for fear of doing something illegal.
It's been a difficult enough battle getting people to recognise that there is a lang attribute (e.g <html lang="en">) and how useful it can be (for example, for screen reader users who need to know when there has been a switch in the language being read out, <p lang="fr">Ce n'est pas bon</p>) - to name just one HTML entity. It would be a shame if this ISO proposal goes ahead and pushes good practices like this back into obscurity.
In response to the recent BBC accessibility BUZZ, Isofaro writes: “To meet level A priority does not require a completely valid website, and does not require CSS for layout.”
All true.
The WasP on BBC Accessibility critique is very thorough and worth a read as it delves more deeply into the fine lines and wrinkles between what is a Web standard and what is accessibility. The differences in both concept and technique are important to note.
Still, there can be no argument that following standards, especially in terms of creating structured, valid markup and removing presentational elements and attributes from a document makes that document inherently more accessible.
Best practices in document authoring means writing conforming documents that are also accessible. These practices are interdependent, even if they have exclusive features.
Arrrrr! There's new booty for all you land-lubbin' accessibility types out there. Old Silver Beard 'Dodgydom' accepted a challenge and with a toot on his hornpipe announced his victory. Avast, me beauties! Here be favelets! These lovelies will tell when your page has form elements that are missing <label> tags. Whatever that means. More accessibility tools ahoy! Cast your sea-weathered noggin' in the direction of the Link Summarizer and shiver-me-timbers if it's not a fine addition to yer web armory.
Arrr!
Sorry, I had to do it. And blow me down if there isn't a Pirate Buzz Blog too ...
The scrutiny began earlier today when a fellow WaSP posted the URL to a BBC article, Website owners face prosecution. The article discusses how the Royal National Institute for the Blind is beginning to crack down on Web sites not conforming to accessibility guidelines as described by the DDA and other U.K. legislation. In the article, BBC reporter Andrew Sinclair opened wide and made the claim that “Some get it right: the BBC website is considered to be one of the best for people with disabilities . . . ”
Making self-congratulatory commentary about one's own publication is no problem if you've got the stuff to back it up. Unfortunately, from a standards perspective, the BBC falls short of the mark. But before I point out what and where, I do want to enter this disclaimer into record: I've always enjoyed the BBC's Web sites, and often use them as examples of excellent globalization and multilingual site development. So with all true, blue, and heartily due respect to what the BBC is doing right, here's a bit about what can be improved.
Using the article page as a sample, I first tested document conformance by running it through the W3C validator. I found a number of problems. To begin with, there's an HTML 4.0 Transitional DOCTYPE declaration on this particular page, and the document is written (for the most part) as if it were an XHTML document. Oopsie!
Dollars to donuts and pounds to pickles, just changing that DOCTYPE will get this page, and the numerous others I tested on the BBC site, a lot closer to conformance. Add the xmlns attribute to the opening <html> tag, write event handlers in lower case, and close those non-empty elements and the page is well on its way to validation as an XHTML document.
Accessibility-wise the BBC has much further to go then Mr. Sinclair apparently realizes. As I went through the document, I found that there are very few alt descriptions on the page. While the alt attribute appears numerous times, it's often empty. There's no use of any additional accessibility-related markup: No title attributes, no acronym elements, no label elements for form controls, and no table summaries.
I then ran the page through the Bobby validator for WCAG compliance, and found it to be a no-go. Problems galore from Priority Level 1 on down. I went ahead and listened to the page with JAWS, and was treated to the typical problems found when screen readers access table-based pages. The right-hand table cells with links to other points of interest were read as part of the primary text, making it all very confusing. What's more, while they have a low-image version available, finding it is difficult, even for a person like me with 20/20 vision. The contrast between the link and the background color of the cell in which it resides is incredibly low. Getting to the more accessible page from a mobility standpoint was a bit arduous as well. There's an interstitial page in between the two versions that serves no real apparent purpose.
The BBC does get big points for having eliminated a lot of presentational markup such as font tags and other crimes against markup typically seen on news and portal sites. In general they've done an okay job of lightening up their use of tables, too. With a little more care to detail, reduction (or elimination) of tables, and the addition of simple accessibility features via markup, the BBC site could quite easily become a flagship of transitional, accessible, global, and attractive design.
Today over at Adaptive Path Jeff Veen makes the case for converting to standards compliant, semantically expressive site production.
Many points are left out because of the need for brevity, but at the close of the essay Veen makes an important point: when design and development communities can quantify a return on investment for conversion to standards compliant sites, the current trickle of early adopters will rise to a flood.
When Watchfire bought out the industry-standard accessibility checker, Bobby, a few notable things happened:
-
The online service was restricted such that only a small number of validation tests could be performed online by any given user within a certain timeframe
- The free downloadable application (Bobby 3.2) was removed from the site, never to be seen again.
- To get a standalone application you'd have to buy the WebXM module as part of the Watchfire site management suite.
Now, this is all fine if you are in a large company that is happy to invest in such tools, but for the individual who cares about making his or her site accessible, this reduced options somewhat. There are other checkers online, I hear you cry, such as Cynthia Says, Ask Alice, The Wave and Webthing. What about offline? You could use Lift (as a plug-in for Dreamweaver or FrontPage) or A-Prompt to help author and check accessible pages. But there's a new kid on the block to watch out for ...
WaiZilla is an XUL-based accessibility checker that will integrate with Mozilla browsers (such as Netscape 7, Firebird and ... erm Mozilla) and provide instant checks on local and online pages; it will also work on Windows, Mac and Linux. As project head honcho Tim Roberts puts it: "WaiZilla will be an open source implementation of an accessibility validation tool. Open source meaning it doesn't cost 99 dollars."
The tool is not yet available for download, but Tim is looking for volunteers to help with this exciting project - more information about WaiZilla is available on this thread, along with Tim's appeal for help. So, if you're an XUL dude or a WCAG guru with some spare time on your hands, drop Tim a line and you can do your bit to further the cause of web standards.
When it's a horizontal navigation strip, perhaps?
The Listamatic is a collection of examples of real-world CSS adaptations of the unordered list (<ul>) that demonstrate just how powerful the concept of separating presentation from content can be. Want to see a horizontal navigation scheme with rollover effects? Or maybe a more graphically rich set of list items?
Note that this is just one aspect of a web page, but navigation is among the most important - if not the most important. If you get it wrong and you have a whole site to put right, what are you gonna do? These examples show that it is possible to use the correct markup for the job (after all, what is navigation but a list of potential routes you can take?) and, in the event of a design disaster ("The visitors hate this navigation!") it is possible to radically change the presentation of your navigation.
Listmatic is a copy-and-paste special - visitors can easily take the examples and deploy them without understanding how the effects are achieved (although you should ask yourself how ethical wholesale copying is). However, instant gratification aside, for those who actually want to learn something in the process, you could try out the listutorial where the techniques are explained in full.
If you've been following the news about hiding skip links using the CSS declarations display: none or visibility: hidden, you'll know that screen readers may or may not be picking up the links. If you have a screen reader, you'll want to see (and hear) the test suite What do Screen Readers Really Say? that Bob Easton has created. Currently, there's a series of seven tests, including importing and linking the style, as well as other potential workarounds. So if you've got a screen reader, fire it on up and head on over, making sure to provide Bob your results.
Also, if you're flummoxed or fuzzy about the realities regarding the patent folly underway between Eolas and Microsoft, IE, Flash, and Patents: Here comes trouble by Jeffrey Zeldman will help you grasp more clearly what's going on and what the potential outcome of patent greed may mean for Web browsers, tools manufacturers, and oh yeah, the rest of us.
As many WaSP readers are aware, CSS3 is modularized. Part of the benefit of this is that each module can be worked on independently, placing focus on the development of those options that are proving especially useful without having to revise an entire draft.
This week, the W3C announced an update to the CSS3 Working Draft Module for Paged Media, adding rich features including pagination, margins, headers, footers, footnotes and cross-referencing. There's a great diagram in the page model section of the draft that will help you see how paged media is being modeled at this point in the module's history.
There's good news from
Bondi Beach in Australia, where the lucky people at Westciv have their office. Summer's not yet upon the residents of New South Wales, so Westciv have shut themselves in an office to come up with a new set of standards-based web training (an issue that is close to my heart). Best of all - it's free, as long as you can work around their weekly schedule (old installments will vanish as new ones are added). What more can I say - except to explain to non-Antipodeans that 'bonza' means good.
Bob Easton reports that the popular method of hiding accessibility-friendly "skip navigation" links from visual browsers also hides them from many screenreaders.
Oh bloody hell.
From a technical point of view, those screenreaders actually get it half right: display indeed applies to all media; but visibility applies to visual media only.
Bob comes to the following conclusion:
“In the end, and with current technology, the only certain way of having accessibility material be heard but not seen is the age old technique of placing a link on an image.”
The question remains whether it is good practice to hide "skip navigation" links (and other accessibility material) at all. Accessibility expert Joe Clark argues that it's not; we should keep them visible for all users:
“You're not going to like this, but to make a lengthy list of links accessible, your "Skip navigation" link must be visible. It doesn't have to be intrusive, but it has to be apparent and self-explanatory in all browsers.”
And think about mobile devices, where the screen is small and navigation hard enough already: Your hidden "skip navigation" links would be invisible.
Let's face it: Designing standards compliant sites for a wide array of devices and users is still an evolving art.
Those of you who have an interest in RDF as a W3C-sponsored complement to RSS and Echo should note that on Friday the W3C released six Working Drafts related to RDF.
Elsewhere, tomorrow and Tuesday the WaSP’s Molly Holzschlag will make a number of standards-focussed presentations at Seybold SF, and will be reporting about it here. Make sure to check back tomorrow!
Ever since XHTML was introduced in January of 2000, arguments as to its use and rationale have been flung about in numerous XML, markup, and Web design forums and lists. Publishing our recent WaSP coverage on serving XHTML with the proper MIME type helped stir up the old pot once again, with even advanced developers wondering just how XHTML has benefited them.
Certainly, there are many reasons why XHTML is important, but there are also legitimate concerns with regards to using it properly. In his article, Bulletproof XHTML on Mezzoblue, technical writer Evan Goer looks into the issue and provides us with helpful insight.
With all the attention being given to what should be an old issue, it's becoming clear that we require better information in order to make good choices when it comes to the languages we use to author our documents. So backroom discussion this week at WaSP has led us to the decision that we should dig more deeply into XHTML: Why it is, what it's best used for, how to use it properly, what the differences between versions are, and what XHTML 2.0 will bring (or deny) us.
For the time being, it's important for anyone interested in standards to realize that authoring to standards doesn't mean you must use XHTML! Why this basic point is so often missed is confusing. Choosing to author to standards really means understanding as much of a given specification as possible, using it intelligently, and validating documents to test for conformance. Whether you're using XHTML 1.1 or HTML 3.2 to do this is really irrelevant. That you are working
with the real language, as it is written, and working to create documents that are conforming is key to rediscovering the interoperable platform the Web was meant to be.
Q: Which MIME type should XHTML be served with? A: The short answer is application/xhtml+xml, of course. But this MIME type isn't recognized by a number of user agents, Internet Explorer included. So, what to do?
In our long-awaited return to the WaSP Asks the W3C series, we ask the good members of the W3C's Quality Assurance Group just what we can do to properly serve our documents.
The W3C Device Independence Working Group has published two new Working Group Notes:
Device Independence Principles describes Web access "anytime and anyhow" from user, authoring and delivery perspectives. Authoring Challenges for Device Independence are considerations and implications for building
universally accessible Web content and applications.
Euroaccessibilty has updated its Web site with more information about its mission. EA has been founded to avoid a risk of fragmentation in Europe and to answer demands from governmental organisations. Apparently, there is a risk that the W3C/WAI guidelines may be promoted differently in different countries.
How do we know if our sites are accessible? Even if we follow Standards and Guidelines for Markup and Accessibility websites may still be inaccessible to some users. Automated checks, following guidelines, and using specific applications have limitations.
Lynx is a great tool to evaluate the accessibility of content delivery on one level, but more tools and checks are needed. Some items used in web page development may interfere with accessing content or navigating a website or page, and may be missed by Lynx. Lynx may give a false impression a site is accessible but fails to deliver results for users where a page is loaded normally in a browser, viewed on a screen, and accessed by mouse, keyboard, pointing devices, or other items.
An article Text-Only is Not Accessible(2002) points out a few issues surrounding the use of Text-only as an alternative to delivering accessible web pages. Some of these same issues can or may show the limitations of relying on Lynx as a tool that will give the impression text-only works for all deliveries. It is important to realize that Graphics, other visual elements, usability, and interactivity with web page content are also important accessibility features for users.
There remains questions about which items of markup, script, and CSS are supported by various accessible technologies and devices. This includes support for title, abbreviations, acronyms, form items, accesskeys, and more. It would be nice if developers of these tools outlined and made available their support features in regards to items of Markup, CSS, scripting.
As designers and developers we need to expand our own definition or beliefs about web accessibility beyond visual disabilities and realize that there are people accessing web with motor difficulties and without a mouse. We may not wish to hide skip links, or other features of navigation or added descriptions to visual content. We need to test websites on various browsers with only a keyboard for these users, one hand, one finger, and or maybe trial with a pointing device. How do these users get more descriptive information on a web graphic of a chart, diagram, etc? Getting to a link inside page content, and after a long link menu may show us a need for providing a visible skip link for this group, and search features up top. We also need to realize that other users may have access diffulties in other areas: cognitive, reading, language, and hearing difficulties.
The Web Accessibility Initiative Outreach and Education Group offers a draft Evaluating Web Sites for Accessibility. This document gives tips and outlines various ways to review work for Web site accessibility. The Preliminary Review contains several manual checks that will help identify accessibility problems that may not appear by using automated tests, checks, or tools.
ReUSEIT is a contest for designers and coders to create a redesign of Jakob Nielsen's useit.com that must use valid tableless XHTML 1.0, CSS, and it must meet WAI Accessibility level 1. JavaScript, GIF, JPG and PNG images may be used. Eric Meyer's quote says it all, "Design Eye for the Usability Guy." WaSPers Molly Holzschlag and Jeffrey Zeldman are judges.
Well, with all this talk of free copies of JAWS, it seems timely that today Freedom Scientific are offering a public beta of JAWS 5.0. Correction - they were offering a free download, but because of some issues that people reported Freedom Scientific "made the decision to postpone the public beta release until this behavior could be thoroughly investigated". That said, if you are a genuine JAWS user, you can download the new beta version (but you will need an authorised copy running on your system already). Among the new features are automatic language detection in HTML (assuming you've specified a value for the lang attribute) and new navigation quick keys. There's also a whole bunch of other additions that you'd never understand unless you were to switch off your monitor and use JAWS exclusively for a week ;)
It's too early to say how well it supports all the existing web standards that we constantly strive to promote - hopefully Gez can lay his hands on a copy and update his extremely useful assistive devices behavior chart.
New versions of Mozilla and Opera Web browsers have been announced by the Mozilla.org open-source project and by Oslo-based Opera Software ASA, respectively.
For Mozilla's part it was another beta release - version 1.5 and among the new features are
- a spellchecker for MailNews and Composer
- an overhaul of ChatZilla (Mozilla's internet relay chat client)
- Gecko now supports setting color for
<hr> (hooray!)
- view source now displays line and column numbers in the status bar
- and general improved performance, stability, standards support and web compatibility (according to the What's New page).
Opera moves up to version 7.20 for Windows. The company is claiming increased speed and performance and support for additional bidirectional languages, including Arabic and Hebrew. They have also released a beta version of Opera 7.20 for Linux, Solaris and FreeBSD, so nobody gets left out of the party.
The Royal National Institute of the Blind (RNIB) in the UK has launched a set of new accessibility information pages on its site today. The Web Access Centre was developed with the support of Standard Life who also support the RNIB's 'See It Right' campaign. Sections in the site include:
In addition, the RNIB are going to be delivering a number of web access seminars across the UK during October and November.
It's good to see the addition of these pages on the RNIB's site, and hopefully it will mean even more people will learn more about the topic. However, it should be noted that the RNIB did come in for some criticism when it redesigned its site a little while back, leaving many people in the accessibility community less than impressed (including Simon Willison, Tom Gilder and myself). Let's hope that people read the advice on these pages rather than looking at the source code behind them ("Do as we say, not as we do").
So, web developers need to get a copy of JAWS to know that their web site sounds right? As covered in a previous post, this is not necessarily the case (although it is undoubtedly a 'nice-to-have'). As Mark points out, we should develop to standards, not to specific technology (otherwise we would all be developing for IE/Win and nothing else); he also suggests some other resources that developers can, and should, try out if they cannot afford a full copy of JAWS.
This morning I was going to re-purpose an earlier piece I wrote 'Accessibility Testing On A Budget' to focus purely on the specifics of screen readers and to further address the current JAWS debate. However, I noticed this morning that Kynn Bartlett (who was very opposed to the petition's existence) has somewhat reduced the neccessity for such a piece with his piece 'A Web Designer's Guide To JAWS'. Topics include 'How can I design for JAWS?', 'What are my alternatives to JAWS?', 'How do I get JAWS users to test my site?'
Meanwhile, W3C and WAI bod Matt May suggests that Freedom Scientific, the makers of JAWS, could at the very least offer a web-based service that spits out speech like a real copy of JAWS would. It might not be ideal for more interactive sites (and by that I mean where the users has to do anything above simply sitting back and listening, e.g. filling in a form), but it would be a step in the right direction.
