01.30.10
Posted in Web Dev, Reference, Accessibility at 6:45 pm by Spencer
As a professional web developer, it’s shocking to me how many clients (usually but not always marketing droids) still insist that any and all links pointing off-site — or even to other sections of a large site — must open in a new window. More shocking is how many of them actually think it’s a great idea that benefits both them and the user. Nearly 13 years after the advent of HTML frames made opening new windows from a link all too easy, and after fully a decade of ongoing pleas and indoctrination from usability and accessibility gurus, I can’t believe how frequently I have to re-fight this battle and educate misguided clients on the folly of this “strategy.”
For typical users, gratuitous new windows are only slightly less annoying than sites and pages that forcibly resize your browser window. If I wanted a new damn window, I’d have used “open in new tab” or “open in a new window” my own damn self! I know how to use a back button, and I know how to use bookmarks. Forcing new windows on your visitors is amateur hour. It’s arrogant, it’s insulting, and it’s very 1997.
It’s much worse for users relying on assistive technologies, including (but not limited to) screen readers, for whom new windows and pop-ups can severely hamper the ability to navigate your oh-so-self-important site.
Now, what do you do when you encounter a painful stimulus? You avoid it, of course, and probably quietly curse whoever caused your pointless pain. At that moment, your site becomes associated with annoyance. Is that really what you want? I’m guessing not.
In my considered judgment, new windows (or pop-ups if you absolutely must) are only justified — even advisable — when linking to digital media: PDFs, MS Word or RTF files, video, audio, and the like. Other than that, forget it. Don’t insult — or cripple — your users.
Following below, for future reference, are a number of the hundreds of specifications, studies, and articles which hammer home the point.
Do not open new windows - a dire user experience
http://www.simiusweb.ie/news/2009_11_10_why_not_open_new_windows.htm
Rebuts the main reasons people think they need to open new windows, and explains why it is such a terrible idea. (With supporting links from accessibility and usability experts…as early as 1999.)
“Opening new windows creates frustration, anger and leads to users leaving your site and ultimately a loss of business.”
“…Breaking news: users know how to use the back button. …[U]sers are not stupid.”
“There are solid business and technical reasons for not opening new windows. There is little or nothing in the way of an argument in favor of them.”
W3C Web Content Accessibility Guidelines (WCAG) 1.0
http://www.w3.org/TR/WCAG10/#gl-interim-accessibility
Checkpoint 10.1: “Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user.”
WCAG 2.0 - Success Criterion 3.2.5: Change on Request: Changes of context are initiated only by user request or [if] a mechanism is available to turn off such changes. (Level AAA)
http://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-no-extreme-changes-context.html
WCAG 2.0 - F22: Failure of Success Criterion 3.2.5 due to opening windows that are not requested by the user
http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F22
“Beware of opening links in a new window”
http://www.webcredible.co.uk/user-friendly-resources/web-usability/new-browser-windows.shtml
“Dive Into Accessibility: 30 days to a more accessible web site. Day 16: Not opening new windows.”
http://diveintoaccessibility.org/day_16_not_opening_new_windows.html
“Avoid forcing to open in a new window”
http://www.webnauts.net/new-window.html
“Radical changes of focus in a GUI environment are extremely disorienting to blind users who are navigating by screen reader, and thus can be considered discrimination against the visually impaired.”
“Links to New Windows, Pop-ups, Other Frames, or External Web Sites”
http://www.webaim.org/techniques/hypertext/hypertext_links.php#new_window
Permalink
11.06.08
Posted in Web Dev, Nifty Links, AJAX, PHP, Reference, What I'm Reading, Browsers, JavaScript, Accessibility at 8:29 pm by Spencer
On Nov. 3, 2008, the W3C’s Web Content Accessibility Guidelines (WCAG) Working Group published Web Content Accessibility Guidelines 2.0 as a Proposed Recommendation.
WCAG defines how to make Web sites, Web applications, and other Web content accessible to people with disabilities. “Proposed Recommendation” means that the technical material of WCAG 2.0 is complete and it has been implemented in real sites. This is the last step before WCAG 2.0 becomes the official standard.
The WCAG Working Group is welcoming final comments on WCAG 2.0 through 2 December 2008, less than a month away.
I highly recommend that every single person in the web business read this stuff carefully. If you have something constructive to contribute to the discussion, now is the time.
WCAG 2.0 will supersede WCAG 1.0, which has been the operative accessibility standard since 1999. There are some important changes to the standard that all coders, IAs, and designers should take note of, and it’s worth noting that there have been periods of considerable controversy during WCAG 2.0’s adoption process.
Current official working drafts of WCAG 2.0 primer documents:
Read the official announcement. Check the latest changes and status of WCAG 2.0.
Permalink
06.01.06
Posted in Web Dev, Reference, What I'm Reading, Accessibility at 9:49 pm by Spencer
Required Reading. In another new article from A List Apart, Joe Clark writes a thorough but blistering and dismaying review of the W3C’s long-awaited new iteration of Web Content Accessibility Guidelines, aptly entitled To Hell With WCAG 2. (The article includes links to all the primary documents.)
To quote some summarizing comments (with bold emphases added):
In an effort to be all things to all web content, the fundamentals of WCAG 2 are nearly impossible for a working standards-compliant developer to understand. WCAG 2 backtracks on basics of responsible web development that are well accepted by standardistas. WCAG 2 is not enough of an improvement and was not worth the wait.
…A lot of loose ends have been tidied up, and many low-priority guidelines are now pretty solid. The problem here is that standardistas already knew what to do to cover the same territory as those low-priority guidelines. Where WCAG 2 breaks down is in the big stuff. Curiously, though, and perhaps due to meticulous editing over the years, the big stuff is well camouflaged and, to an uninformed reader, WCAG 2 seems reasonable. It isn’t, and you as a working standards-compliant developer are going to find it next to impossible to implement WCAG 2.
…WCAG 2 will be unusable by real-world developers, especially standards-compliant developers. It is too vague and counterfactual to be a reliable basis for government regulation. It leaves too many loopholes for developers on the hunt for them. WCAG 2 is a failure, and not even a noble one at that.
While reading the article, I nearly wept. Over the last few months, in part because of a client highly sensitized to accessibility issues (which is good), I have spent a great deal of effort educating myself about accessibility issues and best practices. The touchstone for suches has been WCAG 1.0 — now seven years old. This standards document serves as a mutual enforcement device: my client can use it to remind me of what I need to do, and I can use it to remind my client of what is reasonable (and possible) to expect.
And that means WCAG 2.0 will be the new touchstone. Unfortunately, it’s difficult-at-best to understand, impossible to comply with, and — incredibly — does not even include the most rudimentary demands of valid HTML and (hello!) plain language.
And that means that WCAG 2.0 will not achieve its primary function:Â improving web accessibility by providing clear, practical (i.e. real-world), and achievable standards for creating web sites and content.
This is a huge issue that is not merely semantic because in many countries — such as Britain and, oh, the entire European Union — a site that is not accessible faces potentially devastating lawsuits or other legal action. This is not a hypothetical — just ask Target.com, subject of a huge legal judgement on precisely this point. And, again, a key standards touchstone are the standards put forth by the W3C — an international body that defines stuff like, oh, the HTTP protocol itself.
Stay tuned, and keep aware of emerging developments. This is a very big deal.
Permalink
02.13.06
Posted in Web Dev, AJAX, Reference at 8:17 pm by Spencer
Okay, it’s a little old (November last — so not that old, tho these days it’s all relative), but I only recently came across it and man do it kick but.
eDevil (aka Saddam Azad, 18 year old Bangladeshi code whiz) has compiled an exhaustive roundup of JavaScript libraries, providing info, download and (gasp!) documentation links for a huge number of libraries, Ajax toolkits, and a few good tricks to boot.
And while you’re there, you may also want to visit his similarly thorough posting of Ruby on Rails resources.
Permalink
01.17.06
Posted in Web Dev, Reference at 8:58 pm by Spencer
If you have a valid Seattle Public Library card, you can get free online access to books from O’Reilly, Peachpit, AdobePress, Macromedia Press, New Riders, Microsoft Press, and many more.
Just go to http://webpac.spl.org/rpa/webauth.exe?rs=stb and log in.
The King County Library System also offers a similar service.
Online books / eBooks: http://catalog.kcls.org/search/dElectronic+book+collection./
delectronic+book+collection/-2%2C-1%2C0%2CB/
exact&FF=delectronic+book+collection&1%2C3855%2C
Databases: http://search3.webfeat.org/kclsmain.html
Permalink
01.04.06
Posted in Web Dev, Reference at 9:56 pm by Spencer
sIFR and Anchors Can Be Friends! Marc over at the Crossroads blog (basically consisting of only the one post) provides an excellent article on issues affecting link accessibility and how to modify the standard sIFR Javascript and ActionScript to fix it. Great work.
Note, of course, that this pertains to accessibility for links in a sIFR context. One of the great boons of sIFR (aside from eliminating hours of boring Photoshopping) is that ascii text treated with it is 100% accessible. Er, except the link thing, to some extent.
Note: Well, that’s what I get for going off half-cocked. Turns out the anchor hack fails miserably in Firefox 1.5 — the sIFR-ized text has a tendency to disappear entirely (sometimes) in that browser. I’ll investigate further to see if I can jimmy the whosis. But meanwhile, caveat emptor and (always) test thoroughly before going live, kids.
Marc’s contribution makes a fine companion to Marko Dugonjic’s excellent two-color sIFR hack, so’s you can have more than one color in a block of sIFR-ized text. For that you’ll need the first article and the second part, which includes some more standards-compliant optimizations.
Note: A couple drawbacks to the 2-color hack are worth mentioning. Foremost, the second color must be encoded into the Flash file itself (via one of the ActionScript files). Changing your site palette will thus mean re-encoding the sIFR. (I’ve not tried hacking the hack to see if it can be repurposed to, say, a CSS class, tho I’m not optimistic since it relies on dynamically swapping in an olde school FONT COLOR=”foo” tag.) Also, integrating the hack is kinda cumbersome in a couple ways. One, it was created for an earlier version of sIFR, and so the “find this and replace it with that” stuff in many cases no longer explicitly applies — which means putting on your reverse engineering hat. Two, part two of the article is revisions to the previous revisions — which means you gotta reverse engineer the changes twice.
Both of these hacks are officially sanctioned included in the sIFR documentation wikki, but is not officially sanctioned by the creators of sIFR. (See comments, below.) I’m also pleased to report that the wiki appears to have been fixed and will now talk to you even outside of bankers’ hours. Hooray! (Or boo…that means I don’t have any excuses when working late or on the weekend.)
(If you don’t know about sIFR, then get thee to the official sIFR site right quick.)
Permalink
