Topic Archive: Accessibility

Keeping up with Firefox 3: The agony and the ecstasy of full page-zoom

Brian Dillard, Wednesday, February 27, 2008 @ 5:50 pm

I've been playing with the page-zoom feature in Firefox 3 Beta 3. Thanks to the hard work of the Mozilla folks, Firefox is now the third major browser (behind Opera and IE7) to support this feature. (Safari, of course, supports page zoom on the iPhone but not yet on the desktop.) I don't know whether to be elated or annoyed.

A little background: For years, browsers have allowed users to scale the font-size of any web page using built-in browser controls. The text would get bigger, but other page elements wouldn't. Increasing your font size wouldn't affect the layout of the page at all. If sites weren't careful about how they built their CSS, absolute positioning and fixed-width elements would conflict with the zoomed-up font sizes. The result wold be pages where the main content was readable, but navigational and chrome elements looked grotesquely distorted or in some cases disappeared into the seams of the CSS (see photo below).

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (2)

agile ajax

Accessibility and Ajax: Progressive enhancement vs. side-by-side UIs

Brian Dillard, Wednesday, October 10, 2007 @ 12:00 pm

One of the most eye-opening sessions I attended at Adobe MAX last week covered the topic "Building Accessible Applications with Flex." Flash/Flex apps have a reputation for being inaccessible to assistive technologies, but presenters Andrew Kirkpatrick and John Bennett debunked that myth. Using lots of code examples, Kirkpatrick and Bennett actually walked us through Flex apps in a screen reader and showed how to use MSAA (Microsoft Active Accessibility) tools - including insepct32.exe - to make them function properly. The practical, how-to value of this presentation was on par with Derek Featherstone's talk at An Event Apart a couple months ago. The Flex world, it turns out, is just like the Ajax world: If an app is inaccessible, blame the developer, not the platform.

This session got me thinking again about the future of accessibility in a post-Ajax world. The standards crowd will argue that Ajax should be sprinkled sparingly on top of old-school webapps; it should be part of a separate behavior layer, with careful attention paid to progressive enhancement and accessibility. Turn off JavaScript and/or CSS - or use a screen reader, or a mobile device - and your app should still function perfectly.

I spent most of the last two years working on just such an application in my former life as a UI engineer at Orbitz Worldwide. Orbitz's new travel platform, introduced with the relaunch of the U.K. travel site ebookers.com, implements progressive enhancement on a massive scale. It was inspiring and educational to help build a giant ecommerce site with first-class support for web standards and Section 508. After a while, the techniques that make such applications possible become second nature.

That said, progressive enhancement sort of locks you into a Web 1.0 mindset - or at least a Web 1.5 one. It's pretty hard to imagine a full-on desktop-style Ajax app that magically degrades into a plain-vanilla website using the same markup and client-side code The more complex your Ajax functionality, the higher the cost of weaving advanced and accessible functionality into the same components. It's not just development cost; it's also performance cost. We've all seen progressively enhancement sites with a noticible redraw effect when onDOMLoaded fires. HTML form elements suddenly morph into widgets as your JavaScript transforms the original markup into Ajaxy goodness. This effect will only intensify as you move past basic Ajax effects and into full desktop-level functionality. So what's a standards geek with next-generation aspirations to do?

Plenty of developers have come to the conclusion that you should just build a separate, accessible UI. Look at Microsoft Outlook Web Access and Gmail, the two applications that put Ajax on the map. Both of them offer an advanced client and a stripped-down, plain-HTML one. If it worked for them, why can't it work for a lot of sites? Writer Bex Huff outlines the advantages of this approach pretty compellingly. The accessibility gurus at Webcredible have come to pretty much the same conclusions, albeit after a bit more hand-wringing. I doubt the WC3's forthcoming Web Content Accessibility Guidelines 2.0 will provide a comprehensive roadmap, but the draft version does at least acknowledge how much the landscape has changed.

Accessibility vs. Ajax has been a big topic for a couple of years now; my former Orbitz colleage Mark Meeker has earned plenty of kudos for his talks on the subject. But why do so many discussions of the topic still start from the premise that the same client-side code should support all users? I'd be interested to hear from developers of ecommerce sites and full-featured web applications. Are you building accessibility into your application architecture at all? If so, how? Progressive enhancement or separate UIs? Let me know in the comments.

Technorati Tags

• Ajax
• Accessibility
• Web Standards
• Section 508

• Digg
• Reddit
• del.icio.us

Comments (2)

agile ajax

An Event Apart: Wrap-Up

Brian Dillard, Friday, August 31, 2007 @ 5:30 am

The dust has cleared from An Event Apart Chicago 2007. Now that I've gotten the basic reportage out of the way (here and here), on to the editorial page.

Three things I loved

• The wide range of topics: Despite increasing specialization in the web-development field, jacks of all trades still dominate our industry. An Event Apart offered sessions by and for designers, information architects, writers and developers alike. The most interesting sessions were often the ones that didn't cover my own specialties. Dan Cederhom and Jason Santa Maria both tackled visual design. There was little overlap between their presentations, yet each offered up practical device for folks who have to wing it with graphical design without much formal training. Similar cross-functional advice dominated the agenda.
• The skepticism about rules: Presenter after presenter - most especially Liz Danzico - prioritized guidelines over rules, research over dogma, and attention to one's own audience over one-size-fits-all solutions. One thing that usually distinguishes a great developer, or at least a mature one, is the ability to juggle a host of competing concerns without getting lost in the weeds. Accessibility vs. Ajax, beauty vs. usability, power users vs. Great Aunt Tilly - everything is a tradeoff. If there was on overriding message to An Event Apart, it was that we have to think deeply and often about our audience, our business and our objectives and make informed decisions.
• The focus on end users: It should surprise nobody that the ALA folks are usability nerds, standards geeks and champions of the end user. But it was inspiring to see how the speakers translated that well-worn agenda into series of discrete, actionable tips for everyday developers. As with any complex human endeavor, web development is all about picking your battles. With a potentially limitless number of improvements that could be made to any site or application, it's easy to feel overwhelmed. Most speakers showed how simple steps could provide incremental improvements in usability, accessibility, compatibility and profitability - all without starting over at the ground level.

Three things I didn't love so much

• The absence of concurrent sessions: Packing all 500 attendees into one room for the same 12 sessions (picture here) allowed ample cross-pollination. I'm an RIA developer, but I got the most out of the design, IA and BI sessions. Nevertheless, I longed for the ability to choose from multiple sessions, split off from my colleagues, and come back together during breaks to compare notes. It's not that any of the sessions were completely worthless. It's just that most were designed for intermediate skill levels in the same core technologies. I really didn't need to spend 15 minutes having xmlHttpRequest and getElementByID explained to me. It would have been great if some content had been pitched to masters as well as journeymen. The only way to make that work is through careful scheduling of multiple concurrent sessions.
• The dearth of programming content: A List Apart calls itself a site "for people who make websites," but not for people who make webapps. The broad range of topics very rarely extended to the programming realm. Only one session directly tackled JavaScript, and it was at an extremely elementary level. There was nothing on Java, Ruby, Python or .Net, let alone RIAs, widgets, mash-ups, Flex, Silverlight, GWT or JavaScript libraries. I know, I know, plenty of conferences already cater to those crowds. But as a programmer, I felt shortchanged. Again, concurrent sessions could have solved this, but I'm not sure programming - client- or server-side - will ever be on the ALA crowd's agenda.
• The lack of schmooze time: The schedule included some after-hours social events and a 90-minute lunch break each day, but I talked to lots of attendees who felt like they didn't get enough time to chat with other attendees. Other than a lonely bulletin board - and a social-networking site opened a few weeks ahead of time - there weren't a lot of structured opportunities to connect job-seekers and recruiters or peers from separate companies. Part of the problem was probably the cramped accommodations. When folks had breaks, they were too busy stretching their legs to schmooze. Still, I would have loved to see breakaway sessions aligned by job or industry categories.

Conclusions

For "people who make web sites," An Event Apart was probably a fantastic chance to hear practical advice and smart prognostication from industry leaders. For people who write client-side webapp code, it was a very good round-up of philosophies and techniques that too often get lost amidst the technical details. For pure software engineers, it probably would have been a waste of time and money.

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax

An Event Apart Chicago: Day 2

Brian Dillard, Wednesday, August 29, 2007 @ 9:03 am

Tuesday saw the conclusion of An Event Apart Chicago 2007, the two-day web-development conference from the folks at A List Apart. Here's my sequel to yesterday's day-one overview. I'll be back Friday with analysis and afterthoughts.

Jeremy Keith, author of "Bulletproof Ajax" and "DOM Scripting," led the day. His topic? "Be Pure. Be Vigilant. Behave," wherein he outlined the concepts behind "Hijax," the application of progressive enhancement to Ajax functionality. A staunch proponent of unobtrusive JavaScript, Keith warned against throwing web standards out the door when developing Ajax functionality. His examples demonstrated how to separate behavior from content and presentation by abandoning such outmoded techniques as the javascript: URL pseudo-protocol. His most extensive example showed how to code a graphical widget for the assignment of star ratings so that it would degrade gracefully into a standard HTML select box in less capable browsers. After discussing the difficulty of making XHR functionality play nicely with bookmarks and the back button, Keith acknowledged that his parting message - when in doubt, leave XHR out - was a bit of a copout for the author of an Ajax manual.

Next up was Luke Wroblewski, a Yahoo product designer whose resume includes work on the original Mosaic web browser. Wroblewski covered "Best Practices for Form Design" using exhaustive research from his forthcoming book on the subject. In case study after case study, he demonstrated how simple choices in the design and deployment of HTML forms - from the widths and alignment of inputs and labels to the placement and visual differentiation of cancel and submit buttons - can cut the time it takes to complete them in half. Wroblewski's most persuasive argument, however, was conceptual rather than technical. He made a powerful case that because forms are barriers between users and the things they want to do - buy your product, join your site or begin creating content - you should make them as easy to get through as possible. This central thesis added considerable weight to his many practical how-tos.

Accessibility advocate Derek Featherstone closed off the morning with "Accessibility: Lost in Translation." Featherstone looked at how markup choices can make a site transparent to assistive devices - or render it totally opaque. Using real-world examples from Amazon and other sites, he demonstrated how screen-reading software actually parses markup. His live examples proved that the lack of semantic markup and the absence of ostensibly optional HTML attributes can render a site worthless for disabled users. Featherstone then went beyond the basics, explaining how source order - the sequence in which nodes appear in your markup - can be used to enhance accessibility. By placing your central content first, then positioning chrome above it with CSS and providing jump navigation to skip past inessential modules, you can achieve the presentation you want for typical users without shortchanging disabled ones. In another example, Featherstone examined the ways in which meaning can be encoded in the color and position of elements on the page - and how to replicate that meta-data in a way that disabled users can understand. As with many of the other speakers, Featherstone's examples argued persuasively for the continuing relevance of web standards.

After lunch, CSS expert Eric Meyer again took the stage, this time to explore "The State of CSS in an IE7 World." Using the recent release of Microsoft Internet Explorer 7 as a springboard, Meyer illustrated the concepts that have governed the changing of the browser guard for more than a decade. His overall premise was that developers need to use their own server logs to gauge when support for an older browser can safely be dropped for their site. For most of us, IE6 isn't going away anytime soon, so we need to get creative if we want to harness advanced functionality. To that end, Meyer delved deeply into the details of IE7 techniques, filters and hacks. He praised the browser for the strides it makes over IE6's CSS engine in such areas as child selectors, adjacent sibling selectors and attribute selectors. His real-world examples demonstrated how such functionality adds power and elegance to our code. To cope with IE6's continuing market share, Meyer advocated the use of Dean Edwards's IE7 compatibility script, a JavaScript library that adds IE7 capabilities to older versions of the browser. The take-home message was that older browsers may take a long time to die out, but creative programming techniques can harness the future of CSS now.

The final two sessions for AEA Chicago 2007 were a little offbeat, which was a relief after 10 technical sessions in the previous 32 hours. In the highly anecdotal "Selling Design," ALA publisher Jeffrey Zeldman used stories from his own long career to illustrate best practices for handling difficult clients. His thesis was that collaborative work requires us to deal with a wide range of other people, so we should hone our ability to influence our collaborators - and pick good clients to begin with. Agency owner Jim Coudal closed things off wittily with "Dealing With the Both of You," a slide-free presentation about the crossover between personal projects and professional work-for-hire. Coudal assembled a number of satirical short films to drive home his point: Because most web developers are curious and easily bored, we should strive to marry passion with professionalism whether our clients are external or ourselves.

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax

An Event Apart Chicago: Day 1

Brian Dillard, Tuesday, August 28, 2007 @ 7:42 am

The folks from A List Apart rolled into town yesterday for An Event Apart Chicago 2007, a two-day web-development conference. Around 500 programmers, designers and information architects flocked to the seventh floor of the downtown Mariott for a varied slate of talks by some of the biggest names in the industry. Today and tomorrow I'll give high-level overviews of each day's sessions. On Friday, I'll provide some color commentary.

Stylesheet guru Eric Meyer's "Secrets of the CSS Jedi" kicked things off with an in-depth case study in which pure CSS 1 and 2 transformed tabular data into an Excel-style bar graph. Meyer's presentation was interesting not only for what his techniques could accomplish, but also for what they couldn't. It was inspiring to see that plain-vanilla data could be given a powerful visual makeover, yet still remain completely semantic and accessible to handicapped users. But it was disheartening to see that the simple addition of tick marks within the graph demanded the addition of hard-coded percentage values to a number of CSS classes. The lack of simple computational ability within CSS declarations has long been a drawback of the "not a programming language" language. CSS remains a powerful and flexible technology, but, as I discussed at length a few days ago, it's got a lot of room for growth. For those who were already conversant with Meyer's techniques, perhaps the most interesting digression in his talk was the chance to tear through Firefox's built-in browser stylesheets and see how even the most fundamental rules of HTML presentation - such as the invisibility of meta tags and the entire <head> block - are controlled by CSS behind the scenes. Meyer also went over the basic building blocks of the kind "reset" stylesheet most jedis use.

Up next was Jeffrey Zeldman, publisher of A List Apart and therefore another another rock star to this crowd. A lot of recent ALA content has focused on the overlooked art of writing for the web, so it was no surprise that Zeldman tackled the topic "Writing the User Interface," which packed in plenty of practical advice for writers and non-writers alike. His central thesis was that copy was the cheapest and easiest thing to improve on most sites. Using lots of witty real-world examples, he provided a useful paradigm for breaking textual content into discrete components - guide copy (a.k.a. instructional text), brand copy (taglines and other branding assets), copy copy (a.k.a. real content), labels and URLs - and applying different editing criteria to each. As befits the author of "Designing With Web Standards," Zeldman was careful to demonstrate that the rules of good web writing and the rules of semantic markup are often one and the same. As with most of Zeldman's advice over the years, he started with a compelling philosophy, then showed how to break it down into small, actionable steps.

Happy Cog designer Jason Santa Maria finished off the morning block with "Design Your Way Out of a Paper Bag," a look at the process of rebranding and redesigning an existing site. An illustrated tour of Santa Maria's own iterative design process, the presentation was, like the earlier sessions, a case study in how a series of small steps can have a big impact on the usefulness of a site. Using an amusing Flickr tour of real-life signage and the abuse and misuse of the poor apostrophe therein, the designer drove home his biggest advice: "Sweat the small stuff." Along the way, he touched on typography, branding, logo development, grid-based layout, whitespace and other design concerns. As befits a designer, Santa Maria's session was probably the most visual and the least easily captured in the PDF slides distributed to attendees. He did, however, suggest some excellent further reading, most notably "The Elements of Typographic Style," "Thinking With Type," "Grid Systems" and "Making and Breaking the Grid."

After lunch, Lou Rosenfeld led with "Search Analytics For Fun and Profit." In a series of painstaking real-world case studies - most notably of my alma mater Michigan State University - Rosenfeld explained how server logs and especially search engine logs offer the keys to a successful site redesign. It's a simple idea that may seem elementary to many developers, but given how infrequently web-development teams actually use this feedback loop effectively, Rosenfeld's techniques struck me as really powerful. You would expect a session like this to show you how users' most popular search terms could serve as the springboard to an overhaul of your navigational systems. But Rosenfeld also delved several levels deeper, showing how much powerful business intelligence can be obtained from inexpensive tools with little or no custom code to support them. Site indices, metadata, search algorithms and the search interface itself - all can be tweaked based the subtle metrics that emerge from careful, detailed session analysis.

Perhaps the most inspiring session was Liz Danzico's "The Seven Lies of Information Architecture," in which the Happy Cog information architect recast the high commandments of IA as guidelines rather than rules. Danzico used copious examples to demonstrate how the most successful sites often bend or break the supposedly unwavering rules of IA. The idea of the magic number - most users can only remember 7 +/- 2 items in their short-term memory at any given time - was the first concept to show cracks under Danzico's microscope. She went on to debunk the holy status of such maxims as "consistency is good," "navigation is necessary," "the shortest path is the best path," "experience must be seamless" and "users should always know where they are." Sometimes, the idiosyncratic nature of her examples suggested that certain guidelines work for most sites and are best broken only for a specific purpose. Other times, especially in her examination of Amazon's and Apple's navigational systems, her case studies suggested that even mainstream sites do and should break the rules. It was Danzico's last rule - the idea that only IAs should do IA work - that she most thoroughly debunked by the end of her session. She argued passionately that site owners, designers, programmers and end users can and should understand the guidelines of information architecture - but, like IAs themselves, they should apply those guidelines judiciously rather than rigidly.

Last up was designer Dan Cederholm, founder of SimpleBits and Cork'd. He constructed an elaborate site prototype, ToupeePal, to demonstrate "Interface Design Juggling," his thesis that great design involves keeping lots of balls in the air at the same time. Delving deeply into typography, microformats and the development of favicons, Cederholm demonstrated that beautiful and useful interfaces can be constructed using the supposedly unsophisticated visual and informational tools already at our disposal. Cederholm cried foul on the idea that web typography sucks because too few cross-platform fonts are available. He argued that the single-font typography of the Itallian Renaissance is some of the most beautiful ever created, then he demonstrated practical techniques for getting similar mileage out of limited existing web fonts. Word-spacing, letter-spacing, line-spacing, color, weight, italicization and other simple tools can all elevate even the most familiar typefaces into the design stratosphere. Likewise, even a tiny 16x16-pixel favicon can provide a powerful branding tool when designed correctly. Cederholm closed with an in-depth look at the "accidental API" of microformats, demonstrating that a even a grassroots open-source movement can add power and value to the web without the support of standards bodies and browser vendors.

Check back tomorrow for coverage of today's sessions, from Eric Meyer's look at the post-IE7 world to Derek Featherstone's talk on accessibility.

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax

Cross-platform widgets: fact or fiction?

Brian Dillard, Wednesday, August 15, 2007 @ 5:30 am

For such a simple idea, widgets (or "gadgets" or "modules" or - ugh - "badges") are ridiculously complicated. Take three basic web technologies (XHTML, CSS and JavaScript), wrap them in a fourth (XML), and you should have a really simple, powerful way of deploying a platform-independent UI for your remote data. Yet between Yahoo Widgets, OS X Dashboard, Google Gadgets, Vista Sidebar, Netvibes Widgets and the umpteen other flavors out there, broad deployment is time- and cost-prohibitive. Pretty much every major implementation is incompatible with the others. Often, a single vender offers multiple overlapping versions of its platform, such as Google Desktop vs. iGoogle and Windows Live vs. Vista Sidebar. I'm all for healthy competition and the innovation it produces, but couldn't each big player at least release a unified API for all of its properties?

Amid all of this chaos, what's a would-be widget author to do? Probably the same things as widget users: weigh the options and pick a side. True, the WC3 is beavering away on a standards spec, but we all know how long that's going to take. By the time anything gets signed off on, the fad will either have died out or, perhaps worse, have become a long-term part of the web ecosystem. Imagine hundreds of thousands of legacy widgets written in proprietary formats, a huge number of which will never get refactored to meet the standards. And that's assuming the various widget platform vendors even agree to sign on. It's easy to imagine Google jumping on board, but much harder to hope the folks in Redmond will follow suit. Who knows about the other players?

True, tools have sprung up to translate certain types of widgets into certain other types. But these are stopgap solutions with often unpredictable results. Even when the widgets work, they often don't look pretty in their new homes. And nobody yet has come close to a write-once, run-anywhere SDK for widgets. Translation is the best option the marketplace has produced.

That said, I'm keeping an eye on UWA, the new Netvibes "Universal Widget API." This is another translation methodology, but instead of a third-party application that performs a one-way port of an existing widget, it's an actual spec for authoring widgets once and then compiling them to the various platforms. Thus far it mainly supports Netvibes itself, iGoogle and Dashboard. But Vista support is on the roadmap, and Yahoo support has been discussed. Best of all, they're planning to open-source it. If this API ends up being halfway as useful as it promises, perhaps it will offer a good middle path while the official standard takes shape.

[Lest I end on a completely hopeful note, here's a somewhat related digression: I'm also often depressed by the way the aforementioned standard web technologies get used in widgets. To a certain extent, pretty much all of the widget platforms force you to develop kludgy code. iGoogle and other Web-based platforms scale their widgets based on the size of the browser window. Some developers spend the time to come up with intelligent liquid layouts, but the limitations of fixed-height iframe wrappers make design compromises inevitable. A lot of the third-party widget-assembly shops just slap together some fixed-width design based on the worst-case scenario and built the entire interface out of a sliced-up PSD file. Forget font-scaling and other basic accessibility considerations. It's like the 640x480 viewport all over again, but in miniature. The more things change...]

• Digg
• Reddit
• del.icio.us

Comments (3)

agile ajax

That’s so 1999

Brian Dillard, Friday, August 3, 2007 @ 12:23 am

Lots of trees (and pixels) have given their lives over the past 10 or 12 years to fuel the endless debate about graceful degradation, progressive enhancement and the separation of style and behavior from content. The web standards movement has gained traction by boiling the argument down to one simple assertion that geeks can sell to suits:

If you're in the business of hawking something - vintage hockey memorabilia, advertising impressions, "Harry Potter and the Deathly Hallows" or even plain old editorial content - then you should probably build web sites that make it as easy as possible for as many people as possible to give you their money...

... even people who can't or won't enable JavaScript in their browser/phone/whatever.

It astounds me that we still have to belabor this point in 2007. But a random sampling of large commercial websites reveals that even the big players haven't yet taken this lesson to heart. United Airlines, Sears, Expedia and Amtrak, for example, fail in various subtle or spectacular ways when you disable JavaScript or employ a user-agent without it.

(If you're using Firefox, just install the Web Developer Toolbar, use the Disable menu to turn off all JavaScript, and load one of these sites.)

When you load United's new(ish) multimillion-dollar booking engine sans JS, you get a search form with empty date dropdowns and a bunch of links and buttons that don't work. Sears.com is even more insidious. With a little bit of work, you can get some products into your cart. But when you click the checkout button, nothing happens.

Once upon a time, most commercial sites would at least use a <noscript> block or a server-side browser sniffer to warn you that their sites required JavaScript to function. That's how Amtrak does it today. So does Expedia:

"To enable great site features that are currently disabled, simply make a few adjustments to your browser settings ...." And what, pray tell, qualifies as a "great site feature"? Apparently, the ability to search for flights at all:

I can understand how a start-up like Kayak - with its innovative Ajax UI - can afford to demand a modern, scriptable browser. That will all change when they have a mature business model. But a travel behemoth like Expedia?

Look at the biggest successes of the eCommerce gold rush. Amazon, eBay, Yahoo and Google just plain work on all sorts of user-agents. Often, they offer separate interfaces optimized for mobile or assistive devices. Disable JavaScript on these sites and you can shop, search and browse to your heart's content. How can a site like Expedia not emulate them? Last time I looked, travel was a low-margin, high-volume business. Even if you're throwing away only 1 percent of your business, that's still a _lot_ of wasted revenue.

I'm also at a loss to explain how what's left of our pathetic national passenger-rail service can afford to squander potential customers by requiring them to use a technology that opens up untold security holes in the browser used by the majority of the planet.

Most places, I'm the biggest JavaScript dork in the room. I'm writing on a blog called Agile Ajax, for god's sake! But I still expect my favorite sites to work when I'm stuck on a Windows machine whose network admin has ratcheted up the security to absurd proportions. When I borrow a pal's iPhone, with its five-second script timeout, I expect to be able to do _something_ on the sites I visit. Ditto when I'm on a tediously slow connection on a laptop overseas.

I don't mean to pick on these sites. Heck, in a former life I worked for one of Expedia's competitors, and our site failures in non-JS environments were often of the silent but deadly variety. Even earlier, I was a contractor at United itself, and I'd sooner page through my junior-high yearbook than look at the still-live JavaScript code I wrote for them. Back when I was at Reflect.com, a now-defunct customized-cosmetics emporium in San Francisco, I used to generate the entire homepage with JavaScript, just because I could. I was having fun learning the language.

That was then, this is now. Jeffrey Zeldman's "Designing With Web Standards" is in its second edition. Any number of blogs, articles and books spell it out for even entry-level developers exactly how they can architect web applications that benefit from all that JavaScripty, Ajaxian goodness without turning away users who can't or won't partake.

We have the tools. We can do it. When we don't, it's a deliberate choice. The next time you're gathering requirements for a consumer eCommerce application, sit down with your client in front of a zippy new Vista PC running IE7 with JavaScript disabled via the security settings. Then try to buy some slippers from Sears, or a hotel room from Expedia, or a ticket from United. I don't think you'll have much trouble selling progressive enhancement as a fundamental part of the solution you're building.

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax

Design? Meet Research.

Alice Toth, Wednesday, May 30, 2007 @ 4:14 pm

A running discussions I have with my mom revolves around a cellphone: I think she should have one; she disagrees. I say it makes sense to carry one in case of emergencies; she says her regular phone is good enough for her. I say her regular phone doesn’t work in the car; she states that you shouldn’t talk and drive. Her logic defies a response.

But what I think she really dislikes about cell phones is that they’re just too complicated to use. When my mom looks at my phone, her first question is, well how would I know how to use it?  A valid point. She is accustomed to a landline -- you pick up the handset and there’s a dial tone (no, don’t even start -- she has no cordless phones). Her phone has raised buttons, not a flat touchpad, and these buttons contain numbers, not icons. (I have to admit, I don’t blame her about the icons. I couldn’t even begin to describe the icon on my phone to pick up a call -- it has no name. You have to train yourself as to its meaning.) What she really needs is a phone designed just for her.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

user experience design

Web Accessibility is Good Business

Alice Toth, Friday, February 23, 2007 @ 9:49 am

Over the last few years, more and more basic services have been moving to the Web (banking, paying bills, canceling utilities, etc.) Whether the move is initiated as a cost-saving device or as a way to make the services more readily available, the fact is that moving every day "life administration" online means accessibility gains in importance.

Web accessibility is a broad topic but in essence it means your pages are accessible by people using a wide range of user-agent software and devices, in addition to the standard web browsers. The foundation for achieving accessibility is separating out the content and structure from the presentation and behavior of a page.

Use semantic markup to structure the document.

Semantic markup provides a framework for explicitly describing things. It is descriptive enough to allow machines to recognize it and make decisions about navigating a page. For example, the use of header tags <h1> allows users of screen readers to scan the headers on a page. Or a <strong> tag allows an oral user agent to apply a different voice for emphasis. An added benefit is that semantic markup still gives the content visual hierarchy even if the external style sheet fails to load.

Use CSS instead of presentational markup.

Style sheets define presentational characteristics. Presentational markup (e.g., <font>) does that as well, but it does not allow a user to adjust the presentation to suit their needs. When presentation is defined in a style sheet, it allows different users to override the author's styles with their own. This way, a visually impaired user can display a large text alternative by defining his or her own user style.

Ideally you want to use external style sheets so the presentation information for the site is held in one place and can be updated quickly.  In addition, external style sheets enable you to have consistency across pages and  implement global changes in just one file.

The Web Accessibility Initiative of the W3C, of course, has extensive guidelines and details on how to achieve web content accessibility. It's worth reviewing and implementing because after all, you want your site to reach the largest possible audience. Web accessibility increases the odds of doing just that

• Digg
• Reddit
• del.icio.us

Comments (0)

user experience design

Degrading Gracefully, a Roundup

Dietrich Kappe, Thursday, September 7, 2006 @ 8:00 am

For those developers who are lucky enough to develop applications for modern browsers and damn IE 5 and those who choose to turn off JavaScript, I have one message: I hate you. At this stage, many Ajax projects are about adding little bits of usability to an existing applications -- an in-place edit here, a search term suggestion there -- without rendering it unusable to its current user base.

The simplest idea is to have just two states: Ajax on or Ajax off. If off, the interface behaves like a normal web application. If on, you get all the bells and whistles. And the world would be a simple place if we just had vanilla and chocolate ice cream. So along comes the idea of degrading gracefully, not just on or off but a stepwise falling off as the browser loses capability. A lot has been written on this topic, so I thought I'd round up some of the best articles and see what they have to offer:

• The Hows and Whys of Degradable Ajax - this article takes the approach of really trying to separate on the browser regular web application development from Ajax. Their method is to design a vanilla web application with post-backs, links, forms and noscript tags. Once the vanilla site is done, all of the events generated by the pages are captured using JavaScript. For example, each link might have an onclick attribute that processed the click event and returned false. It is on top of these captured events that the Ajax version is built. The technique in this article, which was written in late 2005, is pretty ad hoc, doesn't abstract widgets or make use of a framework, and really doubles the work for the developer, requiring him to essentially developed to applications. (Jeremy Keith calls this style of intercepting events of a vanilla web site HIJAX.)
• Graceful Degradation with Prototype, Scriptaculous and Ruby on Rails - this three-part article is also from late 2005, takes more of a framework approach. IDs are assigned to DOM elements that require some sort of Ajax behavior. Rules are defined in JavaScript that use regular expressions to match those IDs to behaviors, such as the effects in Scriptaculous. (Note: I was never able to find part three of this series.)
• CSS: The Tech Ajax Forgot - this article from July of 2006 suggests using CSS to hide Ajax elements until a JavaScript onload event can make them visible by manipulating their styles.
• Open Says Me - this article takes a more architectural approach, dividing a Ruby application into separate modules with advanced, Ajax functionality having its own controller. A cookie and some filters ensure that the more advanced functionality can only be accessed by appropriately capable browsers.
• Introduction to dojo.io.bind - this might be considered cross browser compatibility, but technically the Dojo toolkit degrades gracefully from browsers that support XMLHttpRequest to those that support IFrames, dynamic script insertion, or other more exotic transports.
• Three forms of AJAX: solid, liquid and gas - this short article argues that implementing Ajax at a sub page level gives the best possibility for degrading gracefully.
• Ajax and Accessibility - this white paper from Backbase looks at the issue of degrading gracefully from the perspective of accessibility. One of their suggested approaches is to provide a second user interface that uses no Ajax and is compatible with accessibility technologies such as screen readers.

After spending a good time digging for information on this topic, I am vaguely dissatisfied. I was disappointed not to find more progress since late last year. I know that frameworks such as Tibco GI and Ajax anywhere claim to degrade gracefully, but precious little information is available on how they do that. It's possible that after being top of mind in late 2005, everyone found that it was much more efficient and interesting to focus on pure Ajax for the latest browsers. If you build it they will upgrade, so to speak.

Technorati : accessibility, ajax

• Digg
• Reddit
• del.icio.us

Comments (3)

agile ajax

EU Committed to Accessibility

Sholom Sandalow, Friday, June 16, 2006 @ 1:30 pm

The European Union has called committed itself to providing Internet access to all it's citizens by the year 2010. This is more evidence of the importance of providing quality content which is accessible. You can read the full article here. The decision comes as a result of a few disheartening reports about web accessibility for the disabled. From the CNET news article: "According to recent research, 81 percent of Web sites in the United Kingdom are inaccessible to disabled people, while a separate report found that only 3 percent of European public-sector Web sites met W3C accessibility guidelines." As we as a population grow more dependent on the web, it becomes ever more important to ensure that no one is left behind.

The EU's own site on accessibility policy has a sub area on web accessibility. They mention an initiative known as the European Internet Accessibility Observatory or EIAO. This organization's job is to crawl the web looking for scofflaws -- big brother is crawling.

• Digg
• Reddit
• del.icio.us

Comments (0)

user experience design

Quick, It’s the Feds! Hide the AJAX!

Dietrich Kappe, Thursday, May 18, 2006 @ 9:00 am

I was arguing with a speaker at an SOA conference yesterday about whether AJAX for public facing websites was a bad idea. He kept insisting that if you use AJAX, you will get sued, and that Southwest Airlines had in fact lost a case on accessibility already. His claim was bugging me for the rest of the conference, so after I got back to the office I checked up on it. It turns out Southwest actually won that case. But there are new lawsuits springing up all the time.

It seems that to comply with the ADA and other state laws is onerous, to say the least. The following excerpt is taken from an article published in 2000, a time when the amount of non-accessible mischief one could in the browser was comparatively small:

The British national anthem has been described as a series of curt demands on
Jehovah, but it has nothing on the list of demands placed on Web developers by
the "Web Content Accessibility Guidelines," published by the private but
quasi-official W3 Consortium's Web Accessibility Initiative (which Brewer
directs). "Don't rely on color alone" to convey information. Don't use
navigation methods that require a mouse; some users have motor impairments.
"Until user agents allow users to freeze moving content, avoid movement in
pages." Same with blinking or, worse yet, flickering text (which may cause
seizures in persons with photosensitive epilepsy). Don't use tables for layout
unless you're really trying to render tabular data, and watch out even then
(text readers for the blind have trouble with tables). Don't use block
quotations as a shortcut when all you're trying to do is indent. (For the full
text of the guidelines, see www.w3.org/TR/WAI-WEBCONTENT.)

That's just a sampling. Other sins include "poor color contrast," "lack of
alternative text for imagemap hot-spots...lack of alternative information for
users who cannot access frames or scripts." Don't use auto-redirect or
auto-refresh, or cause links to open in a new window. "Use style sheets to
control layout and presentation"--and if you haven't gotten around to learning
style sheets or you use older page authoring software that doesn't provide for
them, that's your problem. Don't use audio clips on your site unless you
caption them for the deaf, or video clips unless you attach descriptions of
what's going on for the blind.

Now providing alternative, textual ways of doing things is fine if you're talking about entering dates via a choice of a text field or a popup date picker. It's a bit more challenging to do that with direct manipulation interfaces -- certainly with my favorite example, UML, which is a visual representation of non-visual concepts. Yes, you have the ability to transform the model into XML or some other textual form which could then be read by screen access software or printed on a tactile display, but providing a way to manipulate the textual "diagram" would require a whole new user interface. Let me repeat that: fully functional, accessible alternatives for direct manipulation user interfaces would require the development of a whole new user interface. That's cost prohibitive for most businesses. Tactile displays are an option, but they are low-res and expensive. (See here for a presentation on UML for blind programmers.)

Even for sites employing very simple and limited uses of AJAX the news is not good. James Edwards has done some practical tests of screen readers with Javascript, i.e. can they detect changes in the DOM and so on? His conclusion:

I'm forced to conclude that, unless a way can be found to notify screen
readers of updated content, AJAX techniques cannot be considered
accessible, and should not be used on a production site without a truly
equivalent non-script alternative being offered to users up-front.

In the desktop world where RIA's are the norm, there are API's and standards
for integrating screen readers with applications. Maybe each rich web
application should come with an XML feed that accomplished much the
same thing.

Of course this isn't just a dollars and cents or even a legal issue. It is a moral issue as well. My mother-in-law became legally blind as an adult, just a bit too late to learn braille and most of the other tools of which the blind make use. Her tools are the worlds largest magnifying glass and software that reads the text of web pages to her. The number of sites that she just plain can't use has gone up over time, and has really soared in the past 18 months. (If you want to know what that feels like, download the lynx browser -- one of the first web browsers back in the pre-image days. Even sighted, navigating through pages with their reams of sidebar crap is excruciating.)

Yes, she represents a small market. Yes, it's expensive to provide fully functional, accessible alternatives to the RIA's we want to write. But should we shut her out of what goes on online just so we can use our nifty RIA apps? Personally, I don't think there is an effective way to split this baby. Provided that you make use of only limited amounts of AJAX such as autocomplete in forms, you can probably make it work, but when the drag and drop starts flying, and the visual metaphors abound, what can you do?

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax