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
01.20.06
Posted in Web Dev, Accessibility at 9:36 pm by Spencer
Web accessibility is always a Good Thing, but depending on your (or your client’s) context it can also be a Legal Imperative complete with Dire Consequences for failing to toe the mark. Those of us with clients in Britain or Australia, for example, or within the governmental sphere must be especially mindful about accessibility when building sites.
It ain’t exactly fun, but one incredibly useful resource for learning the intricacies of legal accessibility requirements can be found here on UI Access’ accessibility resource links page. (The rest of the site is worth visiting, as well.)
Permalink
