Default Folder 3.1 Released — St. Clair Software has released Default Folder 3.1, improving performance in Navigation Services and Save As dialog boxes and fixing a few bugs. The new version addresses one frustrating limitation of Apple’s Navigation Services dialogs: with Default Folder 3.1, pressing Command and the up arrow key takes you one level higher in the file hierarchy, even when the keyboard focus is in the edit box. You can now also edit a file’s Get Info comments from within file dialogs using Default Folder’s Get Info command. Other fixes include an option to speed up the Recent menu in Navigation Services dialogs, and bug fixes in the Default Folder Control Strip Module and with LaserWriter 8 printer driver Save As dialogs. Default Folder is a free update for registered users, and is a 1.1 MB download. [JLC]

<http://www.stclairsoft.com/DefaultFolder/>

Web Confidential 2.2.1 Adds Import and More — Alco Blom has released Web Confidential 2.2.1, the latest version of his utility for storing passwords and other sensitive information in a highly secure file on Macs, Windows-based PCs, and Palm handhelds. (See "Web Confidential: Securing Information of All Sorts" in TidBITS-441 and "Web Confidential 2.0 Syncs with Palm Devices" in TidBITS-531.) Changes since 2.0 include a tab-delimited text import feature, the capability to change the category of a card, an option to show passwords as text rather than bullets, a new file format that’s compatible with the format used by the Windows version of Web Confidential, and an updated Palm conduit to handle the new file format. Web Confidential for Palm has also received an update to version 1.2.1, adding more options for auto-locking of your password file, random password generation, beaming of records, and the capability to hide the passphrase when entered. Web Confidential 2.0.1 is a 710K download, and Web Confidential for Palm is a 220K download; each is $20 shareware or $35 bundled. Upgrades are free for registered users.

<http://www.web-confidential.com/>

<https://tidbits.com/getbits.acgi?tbart=05020>

<https://tidbits.com/getbits.acgi?tbart=05938>

Web Confidential now has competition from Selznick Scientific Software’s recently released $15 shareware PasswordWallet 2.0.1, which offers similarly strong encryption, a $12 Palm version, and a simpler interface. However, it lacks many of Web Confidential’s extensive customization options and has no categorization features. Still, if the more-powerful Web Confidential is overkill for your needs, give PasswordWallet a look. The Mac version of PasswordWallet is a 390K download; the Palm version 27K. [ACE]

<http://www.selznick.com/products/passwordwallet />

Last week, I described what it means for a Web site to be accessible to people with disabilities (see "Web Accessibility: Surfing the Web Blind" in TidBITS-571). Everything rests on the way Web pages are coded and the adaptive technology a disabled Web surfer uses to read the page. Things are slowly improving, but conditions are not good in general. Web accessibility essentially refers to access for blind and visually-impaired people, but few Web authors even know about accessibility, and fewer still take the time to do things right. Meanwhile, with only one screen reader (a program that reads text, menus, and the like aloud) available for Macs – and which doesn’t work well with Web sites – blind computer users are better off using Windows.

<https://tidbits.com/getbits.acgi?tbser=1189>

But all that pertains to Web sites containing nothing but text and graphics. What about sites reliant on those sexy QuickTime movies or Flash animations?

Multimedia Access — Any kind of online video presents severe accessibility problems by being inaccessible to the deaf (who can’t hear the audio) and to the blind (who can’t see the video).

What to do? Here we must borrow a trick or two from older media. Television and film have grappled with accessibility for decades, and since the forces of convergence are trying to make the Internet look a lot like television, the lessons are transferable.

You make video accessible to deaf and hard-of-hearing viewers through captioning: transcription of dialogue and rendition of other relevant sounds. Captioning isn’t the same as subtitling – among other differences, subtitles are often used for language translation (captions use the same language as the audio) and subtitles render only speech, and not always all of it, either.

<http://www.joeclark.org/ understanding.html#subtitling>

Captions are usually "closed" – you need a decoder to make them visible. Canada, the United States, and a select few other regions use one system (called Line 21), while Europe and pretty much everywhere else use a different system (called World System Teletext). The systems are incompatible, but then again, telecasts themselves are incompatible between continents. Gary Robson’s Caption FAQ will tell you more.

<http://www.robson.org/capfaq/>

If captions are part of the original video footage and can’t be turned off, they are said to be "open." There isn’t much open captioning these days, while nearly all subtitling is open. More than just video can be captioned: captioning in first-run movie theatres is up and running, but hard to find.

<http://www.mopix.org/>

Meanwhile, you can make video accessible to blind and visually-impaired viewers through audio description, in which a narrator, working from a tightly honed script, describes out loud the character movements, settings, costumes, titles, and other visual information needed to understand what’s really going on. The descriptions are usually delivered during natural pauses in dialogue. The largest sources of audio description are on television – on PBS and the Turner Classic Movies channel, both in the United States. WGBH, Boston’s public broadcasting channel, and The Kennedy Center offer a taste of audio description online.

<http://main.wgbh.org/wgbh/access/dvs/dvstv.html>

<http://main.wgbh.org/wgbh/access/dvs/ dvsclip.html>

<http://kennedy-center.org/multimedia/surface/ home.html>

If you can play Region 1 DVDs, you can watch subtitles and listen to audio descriptions on the only DVDs with audio description, Terminator 2 and Basic Instinct. (They work fine on a DVD-capable Mac.) Also, a new three-disc DVD set from PBS, Abraham and Mary Lincoln: A House Divided, is due in March 2001 featuring captions, DVD subtitles, audio descriptions, and, for the first time, audiovisual interface menus.

<http://us.imdb.com/DVD?0103064>

<http://us.imdb.com/DVD?0103772>

<http://main.wgbh.org/wgbh/access/dvs/ presspage.html>

Sounds good, doesn’t it? But there are a few hiccups.

There is no longstanding production experience in multimedia accessibility. Captioning and DVD subtitling is comparatively cheap – in the hundreds of dollars an hour range – but if your site isn’t affiliated with a rich television network or production studio, that figure ceases to be cheap. Audio description is cheap only in movie-budget terms, running about $10,000 per motion picture. Costs will continue to go down, but only gradually. Another complication linked to the knowledge gap: multimedia authors should not try to caption, subtitle, describe, or dub their own productions, because they’re virtually guaranteed to get it wrong. So authors are stuck: the quality won’t be up to snuff if they try to do it in-house on the cheap, but outside services cost good money, and very few do work for online media.

Online systems for closed captioning and audio description are poorly supported. It is possible to embed captions in a QuickTime movie, and there’s an entire HTML-like syntax for marking up captions and audio descriptions (called Synchronized Media Interchange Language or SMIL), but incompatibilities are rife. There are so many online video players out there (QuickTime, RealVideo, Windows Media, etc.), with so many versions, that you cannot rely on your visitor to have the right plug-in or software. Plus, Apple’s documentation for SMIL support in QuickTime 4.1 spends a lot of time explaining how it can be used to embed advertising but no time discussing accessibility applications.

<http://www.w3.org/TR/REC-smil/>

<http://www.w3.org/TR/SMIL-access/>

<http://www.alistapart.com/stories/smil/>

Making audio descriptions hidden (so you can turn them on and off) is difficult or impossible in the various online formats. In any event, closed accessibility is unnecessary in multimedia. With technologies like Akamai that distribute large files over many servers to speed up delivery times, and with disk space so cheap these days, it makes more sense to offer separate versions of an online video with open access features that can’t be turned off. You simply select a captioned (or subtitled, or described, or dubbed) version from a menu and that’s the one you watch.

<http://www.akamai.com/>

<http://www.contenu.nu/200008.html#access>

Another hiccup is that nobody’s making captioned or audio-described video. Period. It just isn’t happening. Virtually all the "content" that’s available takes the form of brief demonstration projects.

<http://main.wgbh.org/wgbh/pages/ncam/richmedia/>

Why not? There are very few tools. Adobe Premiere and similar authoring programs don’t let you create captions and audio descriptions. (You can kludge together some titles, but how long are you going to put up with a kludge?) One specialized tool, MAGpie, works only on Windows.

<http://main.wgbh.org/wgbh/pages/ncam/webaccess/ magpie/>

Existing companies and organizations that caption and describe TV shows and videos are generally incapable of doing the same for online media. The Caption Center and the Descriptive Video Service at WGBH are pretty much the only options.

<http://captioncenter.wgbh.org/>

<http://dvs.wgbh.org/>

The Knowledge Gap — But the technical issues are nothing compared to the knowledge gap. Captioning and audio description (and two related techniques, subtitling and dubbing) are fiendishly difficult. You thought designing Web pages was hard? Captioning isn’t anything remotely resembling simple transcription, and have you ever tried to sum up a scene of your favourite TV show in five seconds or less? There are, moreover, no training materials or courses available to teach captioning, audio description, subtitling, or dubbing (save for one limited course in description in the U.K.).

Two recent technologies, Macromedia’s Flash and burning your own DVDs, have thrown a spotlight on the knowledge gap.

Flash, the nearly ubiquitous, widely misused multimedia authoring tool, has single-handedly spawned an Internet catchphrase: "Skip intro." Flash animations are inaccessible, period. There is no way for a screen reader or other adaptive technology to interpret Flash "content." Even demonstration projects in Flash, such as one at the University of Toronto’s SNOW (Special Needs Opportunity Windows) project, access come equipped with a range of instructions and caveats.

<http://snow.utoronto.ca/initiatives/flash.html>

Macromedia has, however, finally admitted it has a problem, and the company now maintains impressive-looking pages devoted to Flash accessibility. Unfortunately, having read all the Macromedia materials and spoken at length with the fellow running the access project, it is pretty clear that Macromedia does not itself understand the issues involved with access, let alone the difficulty of training Flash authors. And even if the technology provided bulletproof, reliable access to alternate versions of Flash content (like captioned or described variants), Flash artists have no training materials or programs available to learn how to create the alternate versions.

<http://www.macromedia.com/macromedia/ accessibility/>

<http://www.alistapart.com/stories/unclear/>

Then there is the capability to burn your own DVDs. Steve Jobs made a big splash earlier this year at Macworld Expo San Francisco 2001 with iDVD and DVD Studio Pro, Apple’s software that lets consumers and professionals assemble and record their own DVDs using the SuperDrive available on high-end Power Mac G4s. DVD Studio Pro lets you encode multiple audio tracks and subtitle streams. That’s great, however, just because you can add these features to your DVD media doesn’t guarantee accessibility. Poorly done captions and descriptions can be worse than none at all.

<http://www.apple.com/dvdstudiopro/>

<http://www.joeclark.org/dvdsubs.html>

What about Napster? No discussion of multimedia on the Web would be complete without addressing Internet radio stations, Napster, and anything else that’s audio-only. Here the group chiefly affected is deaf and hard-of-hearing people. Although music videos on television and home video in North America can be and are closed-captioned (they’re audio-visual), there’s no way to make traded music files accessible.

<http://www.joeclark.org/snowcc.html>

<http://www.joeclark.org/vibecc.html>

<http://www.joeclark.org/slogancc.html>

Online audio files that contain speech, however, can be transcribed, and indeed this is the preferred method for academic lectures (think electronic learning ventures) and literary readings. It is conceivable to encode visible captions in a QuickTime stream that includes audio only, but no one’s doing it. (You can also encode the transcript as a SMIL file, with attendant incompatibilities and knowledge-gap issues.)

Another issue is the accessibility of plug-ins themselves. Streaming audio is attractive to blind and visually-impaired people, but you still need to control the QuickTime (or RealAudio or Windows Media) player, probably using a screen reader and keyboard commands. QuickTime keyboard equivalents on the Mac are skimpy and controlling QuickTime media often requires direct manipulation of images a blind person couldn’t necessarily see. RealPlayer Plus keyboard shortcuts are extensive, though more so on Windows. If Windows Media Player has any keyboard shortcuts at all, they’re not documented online.

<http://www.apple.com/quicktime/resources/qt4/us /help/sc/pgs/scShrtct.htm>

<http://service.real.com/help/player/plus_ manual.8/htmfiles/ keyboardshtcuts.htm#14791>

Nothing but Trouble — So there’s trouble in paradise when it comes to accessibility. Everywhere you look – adaptive software and hardware, Apple’s own corporate support, developer commitment, Web design, browsers, multimedia – on Windows, the situation is always at least noticeably less bad and often clearly superior.

Discouraging, all this. But it doesn’t have to be this way. After twenty years of watching captioned, described, dubbed, and subtitled TV, writing about it, lecturing and hectoring over it, and obsessing over it, I know from experience that a certain minority of non-disabled people really get accessible media.

Try it yourself: watch all your television and home video with captions (or DVD subtitles) turned on for a good two weeks. (No cheating. Two weeks. Nearly all recent televisions come equipped with caption-decoding chips in North America, Europe, and elsewhere.) You’ll quickly find you have developed new skills in reading, listening, and watching simultaneously. There’s modest experimental evidence that even people entirely new to captioning become proficient at understanding TV even with the new information track.

<http://www.joeclark.org/research- roundup.html#eye>

By the way, in North America deaf captioning viewers are now the minority. Even with the poor typographic quality of captions and DVD subtitles, and the many technical limitations, watching a video stream with captions or subtitles is a much richer experience.

<http://www.joeclark.org/hearing-maj.html>

But you know what would really help? Some mojo from Steve Jobs. What odds do you give that Steve Jobs is the kind of person who truly gets accessible media, or would get it if properly introduced? Jobs is already a media tycoon and an evangelist for desktop movies on the Mac. He needs a few demonstrations of what accessible media – and, for that matter, adaptive technology – can do on a Macintosh. Would he then get religion and bring all of his powers of expression to bear, making it cool?

With that kind of imprimatur, wouldn’t we finally see some real action on the issue of accessibility on the Macintosh?

[Joe Clark is a former journalist in Toronto who’s followed, written about, and worked in the disability field for two decades. Explore his many online accessibility resources at his Web site.]

<http://joeclark.org/access/>

Last week I examined a number of document collaboration systems I’ve used and passed on some advice for setting up a system of your own. However, all the systems I talked about involved sending files – usually Microsoft Word files – via the Internet. This week I’m going to look at a couple of document collaboration systems that exist entirely on the Internet: QuickTopic and WikiWikiWebs. A few similar systems that I haven’t used have also been mentioned in TidBITS Talk – be sure to check them out too.

<https://tidbits.com/getbits.acgi?tbart=06349>

<https://tidbits.com/getbits.acgi?tlkthrd=1312>

QuickTopic Document Review — The first of these services is the new QuickTopic Document Review Web site. First, QuickTopic itself is a lightweight Web-based single-topic discussion space. It’s not completely private – the only security is through obscurity (the URL for your discussion contains a randomized set of letters and numbers) – but it could be useful for quick discussions. It displays messages one on top of the other on a Web page, and it can email you the messages if you prefer. It’s a clever idea, but I prefer to use Eudora, which offers more flexible reading and writing environments, and archives everything for posterity.

<http://www.quicktopic.com/>

I’ve found QuickTopic Document Review more interesting, because it provides an easy way to let any number of people read and comment on a document without worrying about file formats, file exchange, or comment conventions. All anyone needs is a Web browser.

<http://www.quicktopic.com/newfeature.html>

Here’s how it works. First, someone uploads an HTML document, and QuickTopic Document Review prefixes each paragraph with a "comment dot" and a sequentially numbered link. To make a comment, click the comment dot or numbered link, and then enter your comment in the text entry box that appears on the next page. When you submit the comment, QuickTopic creates a new discussion linked to the document and displays it. Paragraphs with comments get a little eyeglasses icon in the original document, next to the comment dot. You can also view comments alone or comments along with the paragraph they refer to, and you can sort comments by poster or by paragraph number, all of which can be helpful when integrating comments into your original document (which you must do manually, of course).

The XNSORG Communications Working Group recently tried QuickTopic Document Review for reviewing a large white paper. It worked well, though there are some rough spots. For instance, making comments and submitting them both take you to new pages, so you must either create comments in new windows or click Back twice to return to the original document. The developer of QuickTopic is constantly polishing the system, so I have high hopes for its future.

To get a sense of how QuickTopic Document Review works, try commenting on this article via the link below.

<http://www.quicktopic.com/6/D/saEbesdoTmcH.html>

Wikis — QuickTopic Document Review enables reviewing of documents, but what if you want multiple people to edit the same document online? For that, you can turn to another technology called a WikiWikiWeb (the term comes from the Hawaiian word for "quick" and is often abbreviated to "wiki").

A wiki is Web-based software that provides live document editing via the Web. In fact, a wiki enables live editing of entire Web sites, complete with automatic page creation. This level of freedom can be unsettling, accustomed as we are to the laborious process of creating, editing, uploading, and modifying Web pages. It’s even more disturbing to think that anyone could edit or even delete your text. And yet, from what I can gather from reading wikis and talking to people who use them seriously, such textual vandalism seldom happens.

The main reason is akin to why open source works – social pressure to fit into the group. Other protection mechanisms exist as well. Every version of a wiki page is saved (efficiently, through the use of diffs that record just changes between versions) so you can always go back to a pre-vandalized version. Plus, some wikis provide IP-range and password security to individual pages so, for instance, everyone can read a page, but only some people can make changes. Another option lets only authorized people edit a page, but allows anyone to add comments to the end.

Another aspect of wikis that tends to throw people is that formatting is minimal. Wikis aim to promote communication, not layout. The level of formatting varies between wikis, but there are usually simple wiki-specific formatting rules (like turning lines starting with asterisks into bulleted lists, turning lines of several dashes into horizontal rules, and so on). Many wikis also support HTML markup, though most people don’t bother since it’s seldom worth the effort. Some wikis support graphics, but it’s safe to say that most primarily contain text.

Using Wikis — The original WikiWikiWeb was created by Ward Cunningham, but I’ve found that site’s explanations overly abstract and disorganized. It’s interesting to browse around in Ward’s original wiki, though I’ll warn you that it’s easy to become brain-boggled in the process.

<http://www.c2.com/cgi/wiki?WikiWikiWeb>

Since the wiki software itself is open source, a vast number of wiki clones have arisen, written in a wide variety of languages and running on a wide variety of platforms. Some even provide free wiki space to all comers, so you can set up your own wiki for testing or document collaboration, such as on the WikiWeb site (where they also sell wiki software for intranet use).

<http://www.c2.com/cgi/wiki?WikiWikiClones>

<http://www.wikiweb.com/>

I used the WikiWeb site to collect questions for the annual Netters Dinner Survey at Macworld Expo this year. People could read the existing questions, and then either edit them (to add new answers, for instance) or add new questions. It worked relatively well for gathering a base set of questions which I used when emceeing the obligatory raise-your-hands survey. I’ve also set up another page on WikiWeb where I originally encouraged people from TidBITS Talk to explore and post comments – it showed me that wikis are too free-form for discussions, since comments can be added anywhere and there’s no indication of when comments were made or (sometimes) who made them. Where wikis shine is creation and editing of documents, and so you can see what it would be like, I’ve uploaded this entire article to the WikiWeb site as well.

<http://www.wikiweb.com/~NettersDinnerSurvey>

<http://www.wikiweb.com/~TidBITSWiki/ TidBITSWikiComments>

<http://www.wikiweb.com/~TidBITSWiki/ DocumentCollaborationArticle>

I’ve had more experience with XNSORG’s internal wiki (we hope to open it up soon) for developing and reviewing content. Pages start in one of two ways – either essentially blank or relatively complete. For instance, we’re talking about new content for our home page right now, so I created a page (page creation is merely a matter of naming the page and clicking a link) and roughed in some text. My goal is not to do all the work on the first pass myself, but to put enough material up there that others, when I send them the URL to that page, will be jogged into adding text, making changes, or perhaps just making comments. Plus, I can make changes any time I want without needing to distribute new versions. This approach can work well for starting a document no one desperately wants to create, since it spreads the workload. In this case, someone always ends up taking responsibility for the document, which entails copy editing, checking links, and tweaking the formatting.

At other times it makes more sense to take a mostly completed document and put it up on a wiki page for review and editing. This approach can save time for the person primarily responsible for the document, since the people reviewing often find and fix minor errors and can add or modify explanations as appropriate. This doesn’t eliminate the need for the author to do the final edit pass, but it remains a flexible way to collect comments and changes without maintaining or distributing multiple versions.

Other uses we’ve found for the wiki include an easy way to publish working group meeting minutes without the effort of building and posting traditional Web pages, an open agenda to which all members of a working group can add items, "road map" documents which change frequently, and to-do lists for members of working groups. Overall, I’d say the wiki is a great success, and we’re still thinking of ways to use it. For instance, once we can open it up to the public, we’d like to use it for FAQs, so people could ask questions and we could answer them, right on the same page as all the others while avoiding the slow process of revising and posting traditional HTML documents in a group setting.

Wiki on the Mac — Although I found the public WikiWeb site, I wanted to see about running a wiki on a Mac. Most wikis are written in nominally cross-platform languages like Java or Perl, but I have neither the time nor the expertise to get them running on a Mac. Then I was alerted to the existence of Swiki, which was written in a Smalltalk variant called Squeak, developed initially as a research project at Apple (the developers reportedly followed Alan Kay to Disney). Swiki (I can’t believe they missed naming it SqWiki, or "squeaky") requires its own Web server, called Comanche, and you can download and install the complete package for free. It wasn’t hard – just follow the instructions on the second link below (since the instructions themselves are on a wiki, I did some editing in the one place I found them confusing).

<http://pbl.cc.gatech.edu/myswiki>

<http://minnow.cc.gatech.edu/swiki/16>

I haven’t tested it under any strain, but it seems to work on my PowerBook G3 (other than email notification of changed pages). I’ve also been impressed with Swiki’s feature set – although I’m by no means experienced with wikis, Swiki seems to offer significantly more features in terms of formatting and access controls than many other implementations. If you like playing with Internet servers, Swiki is definitely worth a look.

Although the PowerBook is a lousy server machine for the simple reason that I take it offline on occasion, I’m considering testing Swiki as a way to collaborate with authors on TidBITS article drafts. The two main drawbacks are that editing tools available in a Web browser text field are primitive at best, and we’d lose our internal color coding system if we took the text out of Nisus Writer. However, I think I can address these criticisms with a macro that uses Nisus Writer as the editing environment and translates between Nisus Writer’s formatting and Swiki markup.

We’ll see how it works, and perhaps I’ll end up with an additional resource in my document collaboration tool kit for future projects. In the meantime, I hope this series has been helpful in providing ideas for your own collaboration needs, and make sure to share other approaches you’ve used on TidBITS Talk.