Thoughtful, detailed coverage of the Mac, iPhone, and iPad, plus the best-selling Take Control ebooks.

 

 

Pick an apple! 
 
Open Files with Finder's App Switcher

Say you're in the Finder looking at a file and you want to open it with an application that's already running but which doesn't own that particular document. How? Switch to that app and choose File > Open? Too many steps. Choose Open With from the file's contextual menu? Takes too long, and the app might not be listed. Drag the file to the Dock and drop it onto the app's icon? The icon might be hard to find; worse, you might miss.

In Leopard there's a new solution: use the Command-Tab switcher. Yes, the Command-Tab switcher accepts drag-and-drop! The gesture required is a bit tricky. Start dragging the file in the Finder: move the file, but don't let up on the mouse button. With your other hand, press Command-Tab to summon the switcher, and don't let up on the Command key. Drag the file onto the application's icon in the switcher and let go of the mouse. (Now you can let go of the Command key too.) Extra tip: If you switch to the app beforehand, its icon in the Command-Tab switcher will be easy to find; it will be first (or second).

Visit Take Control of Customizing Leopard

 
 

Web Accessibility: Surfing the Web Blind

Send Article to a Friend

In two previous articles, I explained concepts related to accommodating Macintosh users with disabilities, some of the hardware and software (adaptive technology) available for that purpose, and how Apple has fallen asleep at the switch in recent years when it comes to accessibility. (See "Accessibility on the Mac" beginning in TidBITS-568.)

<http://db.tidbits.com/series/1189>

These days, of course, nearly every new Mac sold is connected to the Internet, as are scads of the old ones - even my coelacanth of a machine, a Power Macintosh 7100/66. But the Internet raises entirely new issues when it comes to accessibility, with a crucial new wrinkle: making the Web accessible requires not only important adaptive technology on the Mac owner's part, but also careful design and coding choices by Web authors. If you thought accessibility on the Mac was in bad shape, Web accessibility is worse. On the positive side, things are improving quickly.

Traditional Media -- Let's think of old media for a second. Start with one of the oldest media, the printed book. If you can't read the type on the page due to a visual impairment, you have a few choices:

  • Wait for a large-print, Braille, or audio tape version to come out (months later, if it happens at all).

<http://www.loc.gov/nls/web-blnd/bph.html>
<http://www.rfbd.org/catalog.htm>

  • Use a magnifier to enlarge the print until it's big enough to read (usually on a big monitor not connected to a computer).

<http://www.telesensory.com/products2-1.html>

  • Use a reading machine that scans print and reads it aloud (a near-miraculous technology when Raymond Kurzweil invented it in 1976, now quite commonplace). Reading machines, formerly separate, free-standing equipment, are largely Windows-based now, though the L&H Kurzweil 3000 electronic text reader is available for Macs.

<http://www.ccs.neu.edu/home/elan/ray.html>
<http://www.LHSL.com/kurzweil3000/mac/>

In other words, to make a printed book accessible, you must use something other than the book itself.

On the Web - By contrast, to make a Web site accessible, the site itself must be set up properly and, in most cases, you also must use adaptive technology. An important distinction comes up here between accessibility on the Web and on the Mac in general. Even in the age of Napster and QuickTime, the Web remains essentially a visual medium composed of text and images. Accordingly, the accessibility or inaccessibility of the Web mostly affects blind and visually-impaired people.

Deaf or hard-of-hearing Web-surfers might find an occasional accessibility problem with multimedia, while people with learning disabilities like dyslexia may find reading all that colourful online text difficult, but the extent of these barriers pales in comparison to the simple issue of seeing and understanding the screen.

The World Wide Web Consortium has a very readable site that gives some imaginary examples of people with various disabilities and the ways in which they use the Web.

<http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/ Overview.html>

It's All about Options -- As you undoubtedly know, Web pages are written in a markup language called HTML (though an increasing number of Web pages consist of non-HTML technologies like Flash). The markup gives structure to a document. For example, text in a paragraph goes between <P> and </P> tags. Or an image might reside in an <IMG> tag that contains details like the filename and the image's size.

For a Web page to be accessible, you must include layers of meaning and redundancy. The most common example is adding text to an image - usually in the form of an ALT (for "alternate") attribute which enables text to be included in the IMG tag. If your browser doesn't load graphics, or if you use an adaptive device like the reading machine mentioned earlier, you can rely on the text version rather than an image you can't see. As an easy example, the logo on the TidBITS home page carries the ALT text "TidBITS Electronic Publishing." If your browser loads graphics and if you're not using adaptive technology, you typically never see the ALT text, because you don't need to: you can look at the image instead.

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

Accessibility, then, is all about options. Can't see a picture, for whatever reason? No problem. We'll give you words to read instead. Unfortunately, simple measures like this are seldom implemented. Web authors are interested in a lot of things: earning their livings, meeting deadlines, showing off, expressing themselves, pleasing their clients. What they are generally not interested in is accessibility. Why?

  • Unfamiliarity. Generally, Web design books and courses barely mention the issue. Web shops rarely have adaptive technology on hand to test their designs, nor do they do usability testing with disabled people (if they do usability testing at all).

  • Priorities (often misplaced). Web designers will spend untold hours coding JavaScript for a page and will labour over egregious Flash animations, but too often ALT attributes and a few other easy accessibility features get left out.

  • Squeamishness. As explained in previous articles, disability makes people nervous. To code for accessible Web design requires a leap of the imagination - to conceive how, for example, a blind person would navigate your site requires you to imagine being blind yourself.

Despite these problems, designing for accessibility can help even non-disabled populations. Just as level entrances and wheelchair ramps make it easier for someone pushing a stroller to get into and out of a building, an accessible Web site works for old browsers, for people with graphics loading turned off, and for Web-enabled PDAs and cell phones.

Resources -- Yet blame cannot be fully laid at the feet of Web designers or even the clients paying for the Web design work. Put bluntly, the resources available for accessible Web authoring are poor.

The current HTML standard includes many features for accessibility - ALT attributes barely scratch the surface (though they are actually required in the current HTML version, 4.01). The source of these HTML specifications is the World Wide Web Consortium's Web Accessibility Initiative (WAI), which provides guidelines, checklists, and techniques for making Web pages accessible. However, in the grand tradition of World Wide Web Consortium standards documents, those pages are long, confusing, meandering, and either maddeningly generalized or overly detailed.

<http://www.W3.org/WAI/>
<http://www.W3.org/TR/WCAG10/>

There are surprisingly few other online resources for accessible Web authoring. You can find links at the HTML Writers Guild Aware Center and the Web AccessiBlog I maintain.

<http://www.awarecenter.org/>
<http://www.joeclark.org/accessiblog.html#specs>

There are only two books on accessible Web design: Universal Web Design, by Crystal Waters (out of print) and Web Accessibility for People with Disabilities, by Mike Paciello. (Last week I signed a contract with New Riders Publishing to write a competing book.)

<http://www.typo.com/store/webbooks.html>
<http://www.webable.com/book_desc.htm>
<http://www.amazon.com/exec/obidos/ASIN/ 1929629087/tidbitselectro00A/>

In short, it is hard to learn how to code HTML accessibly. And authoring tools like Adobe GoLive, Macromedia Dreamweaver, and even the trusty BBEdit make it difficult to include access features. You usually have to edit the code manually.

Through The Web, Darkly -- The design of Web pages is half the problem; adaptive technology is the other. People with low vision use screen-magnification software like Apple's CloseView utility or InLarge by Alva Access Group.

<http://www.aagi.com/aagi/inlarge.asp>

(Why not just select a very large font size in your Web browser? Don't forget that the browser runs on the Mac. The entire system needs to be accessible. Nice big type on a Web page doesn't help that much if your menu bar fonts and dialog boxes are still using teeny 12 point text. Moreover, due to poor Web-authoring practices, many sites look terrible and are almost unusable with extra-big fonts.)

If you have such poor vision that you can't really see what's on your monitor at all even if magnified, you need a screen reader - a program that reads onscreen text and menus, and interprets icons and other items out loud. However, there is but one screen reader for Macs, OutSpoken by Alva Access Group, and it doesn't interpret HTML. Meanwhile, Windows screen readers are remarkably sophisticated, understanding tables, frames, and many of the HTML access features.

<http://www.aagi.com/aagi/outspoken_products.asp>
<http://www.joeclark.org/accessiblog.html#screen>

And yet, even well-coded Web sites can remain inaccessible thanks to the fact that no browser fully supports HTML, let alone all of the language's accessibility features.

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

Netscape 4 is notorious for its incompatibilities, even with HTML tags that were current back in 1997. Microsoft Internet Explorer 5 for Macintosh supposedly supports the entirety of HTML 4, but it isn't true (features like LONGDESC, used for long textual descriptions of images, are absent). The Mozilla project maintains a hefty list of unsupported HTML tags in the new, allegedly standards-compliant Netscape 6.

<http://www.mozilla.org/newlayout/ faq.html#Which%20open%20standards>

Meanwhile, the tiny, impressive Web browser iCab has much wider support of HTML 4, including nearly every access tag (LONGDESC is available), though iCab's accessibility support isn't documented.

<http://www.icab.de/>

And of course, with only one screen reader for Macs which, by its maker's admission, does not interpret HTML, the tight browser/screen-reader integration we find on Windows is simply absent on Macs. To put it bluntly, you're lucky if you can get things to work.

When it comes to Web accessibility for Mac users who are blind or have low vision, then, the news is pretty much all bad. In the short term, these people are still better off using Windows. In an upcoming article, I'll address the even trickier issues involved in accessible multimedia. Just what do you do with all those QuickTime movies and Flash animations?

[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/>

 

READERS LIKE YOU! Support TidBITS by becoming a member today!
Check out the perks at <http://tidbits.com/member_benefits.html>
Special thanks to Drukkerij Bulckens bvba, Adam Bell, Charles Reeves,
Jr., and Charles E Hamel for their generous support!