Taking the cue from the thread titled
(The second last post by Poppa)

Is it a bad idea to use the target attribute to open documents in a new window?
During projects at uni the tutor often mentioned designing for folks who have JavaScript disabled. The tutor's school of thought is "target as many users as you can".

While the IT Manager where I work part-time chooses to ignore folks with JavaScript disabled. His school of thought is they are the in-significant few and not work the troble catering too.

any thoughts on this?

cheers!

[poppa]

My opinion is that you only open links in new windows if they point to a file type that opens in another application - like PDF:s, office documents and so on. The reason is as follows:

Most people use maximized windows - it's only we geeks who doesn't. When a link is opened in a new window from a maximized window the new window will also be maximized thus many people won't notice a new window was opened. The far most used function in a browser is the back button. When a new window is opened a new history session is started which means that there will be no activated back button when the user tries to go back to the previous page and since the person might not have notices a new window was opened it can cause some frustration (especially to blind people who uses screen readers opening links in new windows can lead to the only way for them to get back to where they were at the first place is to kill the browser and start all over again).

I think the reason people want to open links in new windows is because they are afraid to lose the visitor. But that's uncalled for I think. If you have good content the user is interested in she will come back - most likely via the back button in the browser. Opening new windows is NOT the right way to keep visitors at your site.

I said you should open links that will open in another (embedded) application in a new window. The reason to this is:

When, lets say a PDF, is opened it will, on Windows at least, open in an embedded instance of Acrobat Reader. Most users will notice the PDF is opened in Acrobat but they will not notice that it's embedded in the browser and thus they will close the window when done which means they will have to start all over again to get back to the page that opened the PDF. I have studied this behavior myself when sneaking behind the backs of my colleagues here at work and this is also something that has been studied in more scientifically valid manners.

Although, there are times when you should open a link in a new window, and when so happens you should notify the user the user about it in one way or another - I always set the title attribute of the link to something like: "This link will open in a new window", for example if there's a form on the page that the user might have filled in but not posted and you have a link to, lets say, a user agreement. I would be very annoying if you clicked on the link and all your filled in data got lost

Okey, so that's the theory behind my opinion which is quite strict to the guidelines of accessibility.

Last: In the cases when I need to open a link in a new window I use JavaScript to do so just so that my pages will validate. If the user doesn't have JS enabled the link will still work so there's no harm done.

Since the cases are rare when I open new windows I usually go by this technique:

<a href="my.xml" onclick="window.open('my.xml'); return false" title="This link will open in a new window">Go to the other page</a> 

[Codemonkey]

You've made some strong points and I completely agree with you.

I can think of some cases that justify opening pages in a new window, for example when the user enters a parallel flow. An example could be the visitor came in on some landing page through Google, encounters a list of pamphlets that can be required through some form and the landing page directs the visitor to a new window just for the form. It's not so much about avoiding losing the customer as much as keeping the customer in his main flow and a minor subflow at the same time for convenience. In such a case I agree a hint 'opens a new window' should be added.

It's just something from the top of my head and I'm not saying this is the best way to go from a user experience point of view, but it could happen.

Here's how I've treated _blank to avoid w3c validation errors:

<a href="/somelink.html" onclick="this.target = '_blank'" title="This link will open in a new window">some tekst</a> 

Yes this only works with javascript turned on, but there's no way around this if you really want your pages validated using _blank. That it, unless the new window was meant as popup, in which case you should look into popupdivs, which if kept simple can be done entirely with CSS.

[poppa]

I agree back at you Codemonkey!

That onclick="this.target = '_blank'" was a smart thing! I haven't thought about that one!

As a side note to the fact that most people close the window when a document is embedded in another application within the browser: If you've used a Mac you know that when you close a window you don't kill the application. The application is still running although no visible instance exists. I would guess this is due to the same user behavior as I mentioned above: When a user closes the window it necessarily doesn't mean she wants to quit the application, she just wants to get rid of the window. I know I behave in this way in many cases without thinking about it.

.

[Andy-M]

Just want to add as well, from a tracking point of view, your stats may not show where the hits from a certain page are coming from. It's useful to know if lots of people are accessing a certain page frequently but have to go through another page on your site first.

[force10x]

Thank you all for posting.

Some really strong arguments 'against' opening new windows. I do agree with most of all that is said and I do make conscious efforts to code keeping usability and accessibility in mind. But for those rare occasions where in I would like to direct the user to another url for relevant content or have additional information on a microsite I prefer to lead the user to a new user.
I generally indicate that clicking the link would open a new window.

Is it a good thing to do this using Javascript? or can one assume that users with javascript disabled are far and few and can be ignored?

and when is it "safe" or "appropriate" to open links in a new window?

[Codemonkey]

It depends on the device the website is being visited from, but for desktop browsers, Javascript requirements can be ignored as far as I'm concerned. At the same time, realize some browsers go out of their way to avoid having windows opened through the use of Javascript (popup blockers).

Anyway unless validation is really important to you, use target="_blank", since that will guarantee the window won't be blocked since it was initiated by the user itself and at the same time you're fail-safe for people without Javascript enabled.

[mrsnrub007]

To address the original question: yes, it's a bad idea to use target="_blank" to open new windows.

For starters, it's deprecated and invalid in XHTML, if that's your chosen doctype. While it's true that most browsers will still handle invalid target attributes, that's only because they're designed to cope with bad markup in the name of backwards compatibility. Just because it works doesn't make it right. You shouldn't have to rely on a browser's built-in error handling, and you won't have to if you ensure your markup is as valid as you can make it. That means not using invalid attributes. When you assign a doctype, you're informing user-agents that your document follows a specific set of rules. If you then deliberately and flagrantly break those rules, your doctype is a lie.

Of course, some of the rules are kind of dumb (e.g., class is an invalid attribute for the root element in XHTML, for no apparent reason) and sometimes breaking them is beyond our control (lots of poorly-made CMSes churn out unescaped ampersands in URL query strings). But as an author, you should do your best to adhere to the rules whenever possible, and only break them if you have a really good reason and if that violation does minimal damage.

So let's think for a minute about what the target attribute actually does: it's intended for use within framesets, to specify in which frame the linked resource should appear. If the target attribute's value references an unknown or non-existent frame, then user-agents should create a new window to display the resource. That's a fallback behavior to prevent the loss of the original frame, and NOT because generating new windows is a built-in function of the anchor element, or an intended behavior for activated links. When you use the target attribute to spawn new windows, you're exploiting a browser's mechanism for recovery from your malformed markup. So even in a frameset, target="_blank" is still wrong and misuses a failsafe that wasn't designed for that purpose. It's a bad habit that needs to be broken. Stop hurting the web.

Opening links in new windows (or tabs, if that's what the user prefers) is a modification of the link's standard behavior. Behavioral modifications should be handled with a scripting language, not a markup language. End of discussion. Only use the target attribute to target frames or iframes (and declare a Frameset doctype if you must use frames/iframes). If you really want links to generate new windows, JavaScript is the only responsible method.

So if you're using JavaScript to alter the behavior of a link (or any other DOM manipulations and enhancements), you should still ensure graceful degradation when JavaScript isn't available. This means a real link with a real href that leads to a real resource. If your links open in new windows, you should clearly indicate that so the user can decide whether they want to click it or not. It's just the Right Thing To Do.

One quick and dirty approach:

<a href="http://example.com" onclick="window.open(this.href);return false;" 
title="This external link will open in a new window">example.com</a>

Even better would be avoiding inline event handlers and adding that behavior with a bit of DOM scripting. This is the snippet I use with jQuery, but you can do the same with any other library, or you can roll your own function:

<a href="http://example.com" rel="external">example.com</a>

<script type="text/javascript">// <![CDATA[
$(document).ready(function(){
  $("a[rel='external']").attr("title", "This external link will open in a new window").click(function() {
    window.open(this.href);
    return false;
  });
});
// ]]></script>

The rel attribute accurately describes the link's destination, so you're adding meaningful metadata as well as providing a hook to differentiate those links from others. You can also style those links differently, either with an attribute selector or by using the same script to append a class to those links (you could also include that class inline and use it as the script hook, but rel is more meaningful than class in this case). You can do something similar to identify links to non-HTML resources (PDFs, mp3s, etc.).

Users without JavaScript should never be "ignored," but they can expect a diminished experience without all the bells and whistles. Functional links are neither a bell nor a whistle; they're the very fabric of the web. Breaking links is never an option. This means saying no to the "javascript:" pseudoprotocol or dead fragment identifiers in hrefs; links must be real links. If your link only works with JavaScript -- if it triggers some action on the page rather than linking to another resource or another section of the same document -- you should generate those anchors in the DOM with JavaScript in the first place. Then you won't have a bunch of fake broken links when scripting isn't available.

A lot of people who turn off JavaScript are savvy users who know what they're doing, and are thus the kind of users you'll annoy because they'll recognize what you've done wrong. Some are disabled people who turn off scripting in an effort to route around the obstacles put in place by irresponsible web developers (the type who like to make links open in new windows, for example), so deliberately ignoring them is tantamount to discrimination. Some people disable JavaScript to prevent nasty things like popups, popunders, drive-by spyware installs, third-party tracking cookies, and yes, links opening in new windows. Those people may be deeply annoyed when your targeted links still open new windows after they've taken pains to prevent that. So ultimately, most of your visitors who disable JavaScript have done so for a reason, and by choosing to ignore them you're knowingly turning away their business simply because you can't be bothered to accommodate their preferences.

If your window-spawning links are enhanced with JavaScript in a way that degrades gracefully, there's no way anyone can possibly complain -- not even your IT manager. Don't ask for permission. Just do it right because it's your job to do it right. If those links are helpfully labeled, you're giving people the choice to use that link however they prefer to use it -- in a new window, in a new tab, in the same window, copy and paste the URL, bookmark the URL, or not visit it at all if they feel that strongly. By not shutting people out, you're inviting more people in. Everybody wins.

Of course, the major caveat is that all of this depends on the nature of the site and the users you're aiming to satisfy. Some super-fancy web apps just can't be done without scripting. If your users are an enclosed group (like an intranet) you have a bit more power to dictate technical requirements. Every project and every site will be a little bit different, but there are still fundamental guiding principles that apply universally.

The twin principles of progressive enhancement and graceful degradation (combined with proper use of markup and responsible attention to accessibility) will not hold you back in any way. It doesn't demand very much extra effort at all, but it does demand a bit more planning and forethought. But the benefits outweigh the costs, and your users will thank you.

[poppa]

(for you that rocks) I salute you mrsnrub007. (To paraphrase AC/DC )

[Codemonkey]

Great post mrsnrub007, let me put that up front.

However, it's not all as absolute as you portrait and there's a flaw in your assumption.

There is a complete market for web applications that do need windows; intranet applications. Not everything is about resources pointing to resources, SEO optimization and degradable user experiences. Web applications outside of the Internet or that simply aren't interested in those properties.

Quote: Originally Posted by mrsnrub007

[..] most of your visitors who disable JavaScript [..] you're knowingly turning away their business [..]

Though by definition you wouldn't want that, but sadly, this cannot be generalized in the real world as the business simply doesn't care; a simple matter of statistics. From my experiences it's not uncommon for a client not to care about Firefox users all together. Ofcourse it depends on the target audience, but for example insurance companies don't care about this niche.

The only incentive you have in these cases to invest extra time is because you feel better yourself, not because it is a business requirement. This is a major problem if you're working in a team project, where most developers haven't even heard of graceful degradation before. Especially in those cases it is very hard to get it 'right', because there are no resources to get everyone on the same line, but at the same time they will be annoyed if you do things 'differently'. It's the same problem with making business realize documenting code properly is a good thing.

Only if you're a freelancer, strong willed and with the proper knowledge ready, are you in a position to make things the way it should (wink@nutrox).

Quote: Originally Posted by mrsnrub007

So even in a frameset, target="_blank" is still wrong and misuses a failsafe that wasn't designed for that purpose.

Are you speaking from a Semantic Web point of view or from a 'stick to standards' point of view? In the first case, I completely agree. In case of the latter, _blank is definitely part of the latest HTML specification and is 'intended as-is'. Ofcourse there's a reason XHTML doesn't support it anymore, which at least is a prime example of progressive insight.

But it doesn't take away the fact that some flows should be taken care of in an alternative window, or whatever the interpreting context decides is right for target _blank or rel external. Whatever the application demands (intranet?) or the business wants is what rules as long as technology provides the means. You can't get back to your client with "I'm sorry, we can't do what you want us to do for lots of money. It would break the standards we need to meet, to not hurt the web event though valid by a recently outdated standard that browsers widely support". It just doesn't fly. Mr. Science and Mr. Idealism have always driven in Mr. Commercial's car.

Besides, a pamphlet request form in a new window doesn't hurt the web in any sense; the user came to the form through a SEO optimized landing page as a matter of fact.

Quote: Originally Posted by mrsnrub007

[..]Behavioral modifications should be handled with a scripting language, not a markup language. End of discussion.

No it isn't. Although applicable to XHTML in the general sense, the statement itself is flawed. There is room for interpretation of what makes (X)HTML a pure markup language.

Especially XHTML is derived from XML and is actually a meta markup language with a predefined specification of what meta information should be interpreted how by the various contexts (devices). As such, it is entirely possible for XHTML in the future to contain markup for behavior (HTML5!), if not only for certain devices that don't necessarily support scripting, but do support basic behavior the same way it supports basic representation of semantic tags like <strong> (most commonly through bold style) and <em> (most commonly through italic style).

Markup is simply that: markup, and although evolved from graphical printing background, there's nothing that says markups can't be interpreted as directives for behavior as well. The idea of keeping scripts (behavior) seperate from the structural-intended markup is actually a workaround for the lack of markup specification in XHTML and is not defined anywhere as official standard. The same goes for CSS and that is an ongoing battle of what belongs where. Wrapper divs anyone? How about wrapper attributes like 'rel='external'? It's all compensation regarding the real problem: the XHTML lacks in this department, but it is too complex to actually specify behavior. It's taken W3C and consorts long enough to realize we need markup for <footer>, <content>, and <dialog> (HTML5!).

[mrsnrub007]

There is a complete market for web applications that do need windows; intranet applications. Not everything is about resources pointing to resources, SEO optimization and degradable user experiences. Web applications outside of the Internet or that simply aren't interested in those properties.

I specifically mentioned intranets and web apps as potential exceptions to the rule. I specifically did not mention SEO, since I honestly don't care about SEO (that's a subject for another rant).

A link points to a resource. It's what links are. If you just need a clickable widget to trigger a scripted response, but without linking to a resource, then you can use JavaScript to generate any arbitrary element you like and attach an onclick event handler. There's no harm in that.

Though by definition you wouldn't want that, but sadly, this cannot be generalized in the real world as the business simply doesn't care; a simple matter of statistics. From my experiences it's not uncommon for a client not to care about Firefox users all together. Ofcourse it depends on the target audience, but for example insurance companies don't care about this niche.

Then, with all due respect, f__k the insurance companies. I don't care if my clients don't care, *I* care and I'm going to do it right because it's the right way to do it. If your web page doesn't work in Firefox, your web page is broken (that's a figurative "you", not you specifically). If a coder can't be bothered to test his pages and ensure they work in Firefox, then he's incompetent and needs to be drummed out of our industry.

The only incentive you have in these cases to invest extra time is because you feel better yourself, not because it is a business requirement.

It's not a business requirement, it's a technical requirement. It's the way it should be built. Anything less is shoddy workmanship.

This is a major problem if you're working in a team project, where most developers haven't even heard of graceful degradation before. Especially in those cases it is very hard to get it 'right', because there are no resources to get everyone on the same line, but at the same time they will be annoyed if you do things 'differently'.

You're absolutely right, it's very challenging and frustrating to be a professional in a team of incompetent and lazy hackers who don't know what they're doing. I've been there, and eventually I gave up evangelizing and just did it the right way because it needed to be done right. I could have half-assed it and kludged together some steaming pile of inaccessible, poorly-made crap chock full of nested tables and font tags and spacer gifs, and my bosses never would have noticed (at least until the customer complaints and lawsuits started rolling in). But I take pride in my work, so I do it as best as I can. I don't want to hurt the web because I love the web.

Are you speaking from a Semantic Web point of view or from a 'stick to standards' point of view?

I'm speaking from a "know your craft" point of view. The target attribute is for framesets. If you use it outside a frameset, you're wrong. Now perhaps you're happy to be wrong, and lots of people are. We certainly all did things wrong for a long time because we didn't know any better or had no other options. But if you do know better and you're aware of the better options, yet you continue to do it wrong, well then I'm afraid I just can't fathom your thought process and I have to assume you're incompetent and need to be drummed out of our industry. (Again, this is a figurative "you" and not aimed at any individual in this thread. I'm frothing hyperbole here.)

In case of the latter, _blank is definitely part of the latest HTML specification and is 'intended as-is'.

I stand corrected: "_blank" is indeed a pre-defined value for the target attribute in the HTML 4.01 spec, with the recommended behavior of generating a new browser window. It's defined in the section on targeting frames (http://www.w3.org/TR/html401/types.h...e-frame-target). So it's for use in combination with a frameset, and with a frameset doctype. It's deprecated in XHTML because all frames are deprecated in XHTML.

But it doesn't take away the fact that some flows should be taken care of in an alternative window, or whatever the interpreting context decides is right for target _blank or rel external.

You're absolutely right. I've made links open in new windows plenty of times, and there are numerous cases where it makes sense (external links, for example). There's nothing inherently wrong with it, apart from some of the problems that can result. So new windows should be opened responsibly and in accordance with best practices of accessibility, usability, interoperability, and a few other -ilities I could probably think of.

You can't get back to your client with "I'm sorry, we can't do what you want us to do for lots of money. It would break the standards we need to meet, to not hurt the web event though valid by a recently outdated standard that browsers widely support". It just doesn't fly.

Perhaps not, but you can certainly offer your expert opinion and suggest a better alternative if your boss asks you to execute a Very Bad Idea. That's usually part of a developer's job. It's also part of a developer's job to come up with technical solutions to meet business requirements. If some marketroid is telling you to use the target attribute instead of a JavaScript alternative, that's gotta be the most technically knowledgeable marketroid I've ever heard of. Usually they just say "this link should open in a new window" and leave it to you to decide how to make that happen.

As such, it is entirely possible for XHTML in the future to contain markup for behavior (HTML5!),

HTML5 and XHTML2 are unfinished, so they're not really applicable right now. At some time in the future someone may come up with a structural/behavioral hybrid language, but it's not available now. Right now, today, the target attribute shouldn't be used to generate new windows, unless you're working with frames with the appropriate doctype.

Markup is simply that: markup, and although evolved from graphical printing background, there's nothing that says markups can't be interpreted as directives for behavior as well. The idea of keeping scripts (behavior) seperate from the structural-intended markup is actually a workaround for the lack of markup specification in XHTML and is not defined anywhere as official standard.

Markup languages outline the structure of a document, not its behavior or presentation. Even so, some bits of behavior and presentation are bound to creep into it (inline event handlers, for example). But as a preferred best practice, such non-structural, non-semantic markup should be avoided in favor of scripts and style sheets that are more suited to the task.

Similarly, some elements do carry some implicit presentational traits. Strong and em should be visually emphasized, block-level paragraphs and list items should appear on their own lines, and so on. But that's secondary to the element's structural and semantic meaning; to emphasize text (strong and em) or delineate one or more sentences encompassing a single thought or idea (a paragraph) or indicate a single item in a group of related items (a list). While machines can read tags just fine, human beings rely on some visual structure to make text readable and understandable. We need some visual cue that the previous paragraph has ended and a new one is beginning, so a p element definitely needs some presentational touches to make any sense to a sighted human reader.

An unsighted reader has different needs, of course, and screen-reading software will pause between paragraphs to let the listener know that one thought had ended and a new one is about to begin (that's one more reason paragraphs should be marked up as paragraphs, and the old <br><br> hack hurts the web). But I digress.

The same goes for CSS and that is an ongoing battle of what belongs where.

A fair point. There's been plenty of debate over the :hover pseudoclass, which is essentially behavioral and arguably has no place in CSS. Personally, I feel that affecting the presentation of a hovered link is within the bailiwick of CSS, and using a script to detect a mouseover event and restyle those hovered links just seems like a lot of silly overkill. But I can sympathize with those on the other side of the fence, and I'd never use the :hover psuedoclass to trigger the display of a dropdown menu, for example. That type of document manipulation is undeniably behavioral, so JavaScript is the better choice.

Which brings me back to my original point. Generating a new window in response to a user action (activating a link) is absolutely a behavioral enhancement on top of the link's typical, expected behavior (opening the resource in the current window). That's what JavaScript does best, it's what JavaScript is designed to do, and so JavaScript is the better option.

If your boss has his head so far up his ass that he still wants links opening in new windows, even when scripting is disabled, even after you've explained to him why that's a Very Bad Idea, then you're better off finding another job working for a less-stupid boss.

target="_blank" works, but it's a hack. Don't do it.

[Codemonkey]

Quote: Originally Posted by mrsnrub007

"Markup languages outline the structure of a document, not its behavior or presentation. Even so, some bits of behavior and presentation are bound to creep into it (inline event handlers, for example). But as a preferred best practice, such non-structural, non-semantic markup should be avoided in favor of scripts and style sheets that are more suited to the task.

Similarly [..]"

Hence my remark:

Quote: Originally Posted by Codemonkey

"Although applicable to XHTML in the general sense, [..], There is room for interpretation of what makes (X)HTML a pure markup language."

As you noted, as bits creep in, XHTML is not a pure markup language. It's somewhat of a hybrid markup language, a meta markup language with a specification that limits wat meta information can be provided. And extending that concept, there's nothing prohibiting adding meta info about behavior as well. Currently HTML5 promises to provide tags for sound for example or dialog boxes. This is only a next step towards a full hybrid markup language I suspect, though as you mentioned this is far from final still. It all comes down to the definition of a Semantic Web.

I'm going to leave it at that. I don't intend for this to result in a quote war

[mrsnrub007]

And inline event handlers are widely decried as behavioral markup that we should avoid. They crept in for the same reason font crept in: because people wanted them and had no other options (until the DOM and ECMAScript were standardized) and now it's time for them to start creeping out. Inline events are still valid, but are sloppy so don't do it if you don't have to. Inline styles are valid, but are sloppy so don't do it if you don't have to. Mixing the layers is a Very Bad Idea. I don't want a hybrid markup language. Separation is good. Adding MORE behavior to HTML would be a step in the wrong direction after we've fought so hard to get HTML cleaned up. Markup is for structure.

[Andy-M]

Just wanted to add that most users don't want to open a new window just to see something. If they wanted to open a new window, there's always right clicking on a link and "Open in New Window" (or new tab).

Forcing the user to open a new browser window to open a link just takes away more control from the user. And given that the shift in "Web 2.0" seems to be going more into giving the user more control, I'd say opening a new window is a bad idea in general. The only exceptions would be something like opening a new window to display a full size image from a thumbnail. If you are to adhere to XHTML 1.0 Strict, you'll have to use JS for it to validate properly. However there are always other options to a pop-up window still.

Strategically, I'd avoid using new windows still.

[Nutrox]

Whoa, intense thread guys. I think it moved away from the original target="_blank" question a while ago but I just want to throw my thoughts into to bubbling pot.

I don't think we (as developers) should dictate how links are launched, that decision should be made by the user. Most modern browsers allow users to dictate how links are launched (in a new window, the same window, a new tab, etc)... that is how it should be I think. However, developers should be free to develop a site how they see fit, so if a developer does want external links to open in a window then that is cool but the functionality for that should be handled entirely by JavaScript (this includes NOT using the <a type="external">...</a> technique). You can listen for Mouse clicks events, check the host name in the URI of any links that are clicked, then cancel the event and launch the link in a new window if needed.

I agree with mrsnrub007 about the inline styles and events. Style, structure, and logic should be kept as separated as possible. I don't think wrapper-divs are a bad thing, they only become wrappers when told to do so by CSS. The same thing can be said when Anchors (etc) are displayed as block elements instead of inline elements, as long as it is the CSS dictating that behaviour then it isn't a problem IMO.

I disagree with mrsnrub007 about the SEO thing though "since I honestly don't care about SEO"... not a smart thing for any developer to say really is it.

[mrsnrub007]

A rel attribute that describes the link's destination (or rather its relationship to the current document) is a sound enhancement, but I'll admit it's also a shortcut to adding behavior. It's a convenient hook so the script can isolate those links and distinguish them from others. Checking the domain is equally effective and probably less intrusive.

And to wander even further off topic for a bit, it's true I don't care about SEO. I'd rather optimize content for people, not for robots. Google is not my audience. A search engine leads people to the content. If the content is worth finding and is structured with clean, meaningful markup, then search engines can do their job and we shouldn't have to resort to trickery. I don't employ overt SEO tactics because gaming the system only damages the system. It's unfortunate that an entire cottage industry has sprung up around exploiting search technology to promote certain content above its actual relevance.

Imagine a world with no SEO and only useful content cradled in semantic richness... a world where search engines don't have to filter through heaps of spam to pluck the relevant morsels from a vast sea of mostly-garbage... oh to dream the impossible dream...

[Nutrox]

I understand where you are coming from now, when you said SEO in your previous thread I thought you meant SEO period. Semantics is SEO though, if you get the site semantics right then your site is optimised for search engines and is also people/browser friendly. A lot of people are greedy though and don't care about anything other than filling their pockets with cash, that is reason why SEO/Email and everything else around the web has been exploited and corrupted as much as it has.

Greed and (something I probably shouldn't mention here) are cancers, they are the sole reason for all of the sh-ite in the world, past and present.

How's that for off-topic.

[Codemonkey]

Indeed, I was puzzled a little bit myself about mrsnrub007's comment regarding SEO. I agree SEO is achieved when a page is semantically meaningful and it seems we're all on the same line on that one. Especially Google has admitted its algorithms is geared towards interpreting a page the way its visitors would. Elements such as meta-description and meta-keywords have lost most of their meaning, since content with semantic markup is much more indicative.

It's a grey area however when you consider SEO optimization from a marketing point of view, layering a page with keyword upon keyword in an attempt to beat the competition. That's one of the reasons, if not the Reason, why all search results in are seeded with commercial outlets...

Quote: Originally Posted by Nutrox

I don't think wrapper-divs are a bad thing, they only become wrappers when told to do so by CSS

Actually, they only become useful wrappers when told by CSS. Meanwhile they are structural markups without meaning. For a screen reader or any other device that doesn't support CSS it is simply put redundant as it clutters the structure and doesn't add any semantic value. They are used as a workaround for the lack of proper HTML+CSS integration (or CSS capabilities to begin with, fingers crossed for CSS3).

[Nutrox]

Quote: Originally Posted by Codemonkey

Actually, they only become useful wrappers when told by CSS. Meanwhile they are structural markups without meaning. For a screen reader or any other device that doesn't support CSS it is simply put redundant as it clutters the structure and doesn't add any semantic value. They are used as a workaround for the lack of proper HTML+CSS integration (or CSS capabilities to begin with, fingers crossed for CSS3).

I have to be honest and say that screen readers are the last thing on my mind when I'm putting together a site. One thing I always test myself with though is the "no CSS and/or JS support" situation, I turn-off the CSS and JS and make sure the page contents are still ordered correctly and are still readable/useable. Turning of CSS and JS is also a good indication of what Googlebot will see while reading the page.

Taking screen readers out of the equation for a moment, I still don't think wrapper divs (used when needed) are a bad thing, they don't effect semantics at all.

<body>
    <div id="header">...100% wide header...</div>
    <div id="content">
        ...760px wide centered content...
    </div>
    <div id="footer">...100% wide footer...</div>
</body>

If you know of an easy way to get the content centered in that example without using the #content div (wrapper) then please let me know. Not even CSS3 can help us with that one.

[mrsnrub007]

A div is a content division. They're semantically neutral, but not entirely meaningless. A div says "these bits go together and are separate from those other bits." So if you think of them in those terms, divs can be quite meaningful and do add real structure to a document; they group related elements together and distinguish one portion of content from another. That's really what they're for. The fact that they're also conveniently stylable containers is just gravy. But the Buddha nature of a div is a content organization device, not a page layout device.

[Codemonkey]

Agreed, but we're not talking divs here, we're talking wrapper divs specifically. That's different story.

Quote: Originally Posted by Nutrox

I have to be honest and say that screen readers are the last thing on my mind when I'm putting together a site. One thing I always test myself with though is the "no CSS and/or JS support" situation, I turn-off the CSS and JS and make sure the page contents are still ordered correctly and are still readable/useable. Turning of CSS and JS is also a good indication of what Googlebot will see while reading the page.

Taking screen readers out of the equation for a moment, I still don't think wrapper divs (used when needed) are a bad thing, they don't effect semantics at all.

<body>
    <div id="header">...100% wide header...</div>
    <div id="content">
        ...760px wide centered content...
    </div>
    <div id="footer">...100% wide footer...</div>
</body>

If you know of an easy way to get the content centered in that example without using the #content div (wrapper) then please let me know. Not even CSS3 can help us with that one.

You're absolutely right, and I'm doing exactly the same as you are. I was just pointing out the limits of XHTML to creating a pure semantic page. It's not possible if you need CSS and behavior. The fact you need 'wrapper' elements and 'hooks' merely proves the fact (X)HTML was never intended to be able to do all those things, that it is a malformed evolution of what it used to be when it still supported <font> et all. CSS 3 and HTML5, XHTML2 are attempts of 'getting there' and it is not enough by a longshot; the internet as a HTML platform has been stalled for a decade by browser wars and IE's influence, though that's a rant for another day. In that sense, I regard wrapper divs bad; out of place fixes to the real, hidden problem.

It is in fact the very (X)HTML specification itself that is hurting the web as people are grasping for half-baked solutions to get a web 2.0 application done, because, really, 'knowing your craft' has become an academic sideshow that few people are able to master, yet is one of the most accessible arena's.

[force10x]

I didn't expect this thread to get so interesting. This sure has helped me learn a lot more than I expected. Thank you all for your contribution.

Now, coming back to the original post.

The target="_blank" point taken.
Thank you mrsnrub007 (I forget if its mr. snrub007 or mrs. nrub007 )
I now know where this attribute comes from...frame sets....now why didn't I think of that

I, too, am working for an Insurance Broking company. The website utilises JavaScript as a major part of the code, along with ASP (now moving to ASP.NET). User with JavaScript disabled are re-directed to another page that asks them to enable JavaScript to navigate/use the website.
The IT Manager tells me that it doesn't matter if a "few" users cant get in just cause they don't have JavaScript enabled on the browser.

My point, is that user with JavaScript turned off, could be the CEO of a company looking for insurance for his 10,000 employees. And if he can't get in, we are probably loosing good business.

So how can we (I) code with JavaScript keeping in mind that there could be users with JavaScript disabled. Specially when it comes to forms or showing relevant content using JavaScript.

I know for forms, one option is to have sever side validation. But then, is this feasible?

Are there examples of websites where the site looks and works as good with JavaScript turned off? Graceful degradation is is called I think.

A good explanation of the DIV tag above. This was the case with Tables as well. Tables were used to style pages earlier, please excuse my ignorance, but aren't we doing the same with DIVs now?
This means we are basically using elements that are meant for structuring content to make pretty layouts. for example a div within a div 'wrapper', like the few three-column css layouts out there.

Till date I have never considered screen readers. But going forward, I do want to design websites that, as mrsnrub007 put is, "do not discriminate against folks with disabilities".

[Nutrox]

Quote: Originally Posted by force10x

...
Till date I have never considered screen readers. But going forward, I do want to design websites that, as mrsnrub007 put is, "do not discriminate against folks with disabilities".

The thing is, it isn't always possible or practical to develop a site that can be accessed by everyone with a disability. I don't have a problem with people who have disabilities, a long-time friend of mine is wheelchair bound, but a line needs to be drawn somewhere. Is a website such as YouTube, or any other video-heavy site, discriminating against people who are blind or partially sighted? No.

Quote: Originally Posted by force10x

...So how can we (I) code with JavaScript keeping in mind that there could be users with JavaScript disabled. Specially when it comes to forms or showing relevant content using JavaScript.

You don't develop the site in such a way that it relies on JavaScript being enabled, you develop the site with JavaScript in the back of your mind and then add the JavaScript goodness once the site can be used without it. For example, you get a server-side script to validate forms when they are submitted, but if JavaScript is enabled you can use a XMLHttpRequest object (i.e. AJAX) to pass the form data to the server-side script and then get JavaScript to update the HTML when it receives the response.

Another example, if you need to toggle certain content (show/hide) then you use a link with a URI such as "?hide=updates" which will hide the content if JavaScript isn't available (yes it requires a page reload but you need to compromise). If JavaScript is available then it can prevent that link from opening and show/hide the HTML element based on the URI query (i.e. "updates" would be the ID of an HTML element).

I'm doing a lot of this on the new version of my site (will be online this week) so I will let you know when it is up and running and you can have a look at the source code etc.

[enkriptid]

I'm doing a lot of this on the new version of my site (will be online this week) so I will let you know when it is up and running and you can have a look at the source code etc.

ill be looking at that too if you dont mind

[mrsnrub007]

Like Nutrox said, the best approach is to first build it as if JavaScript were absent and make it at least functional. Then add scripted enhancements on top of that. How far you take it will depend on the site and on the audience, but basic bells and whistles like collapsing menus can degrade totally gracefully (the menu could be open by default and collapsed by JS when it's available). The unscripted page doesn't need to be exactly the same. It doesn't even need to be pretty. It just needs to work.

Also note that a great many screen-reader users *do* have JavaScript enabled, and that's actually one of the reasons you should always indicate that a link will open in a new window. People who use screen-readers tend to browse maximized, and may not be aware that a new window has opened on top of the previous one. If you just give them a warning then they at least know to expect it (plus it's just polite). The JavaScript + screen-reader conundrum is one of the big accessibility obstacles with Ajax, since it may not be obvious that something on the page has changed and a screen-reader will just keep on reading. But on the whole, screen readers cope with JavaScript fairly well.

No site can be made accessible to ALL disabled people, simply because of the vast range of disabilities out there. But you can follow a few basic principles and at least make it reasonably accessible to a lot more people, and you can try to avoid introducing unnecessary obstacles (those that are easily avoided, anyway). YouTube doesn't provide captioning or audio descriptions for all their videos because that's just not possible with user-generated content (at least until someone develops the technology to automatically [and accurately] transcribe a video). Nobody can fault YouTube for that, and I doubt many blind people are especially upset over it.

It's also not possible to deliver the exact same experience to disabled people. By definition, their senses and abilities are different from the unimpaired average. Their entire experience of LIFE is different, so their experience of a website will be different too. They'll naturally have to work a bit harder to do some of the things most of us take for granted, but if you can minimize the obstacles you'll make it a bit easier on them. Or at least less hard.

The best we can do as developers is to become aware of how different people experience our sites, and keep that awareness in mind when we make our decisions. Just as you should always consider your audience anyway, learn to consider some segments of your audience that you might not have thought about before.

So a few basic principles:

* Any images that are meaningful content should have a (brief) descriptive text alternative in an alt attribute. The value of the alt attribute should serve to replace the image as if the image didn't exist (imagine describing it to someone over the phone in 15 words or less). If it's a picture of text (like a logo), then the alt should be that text. If the image is a link, the alt should be the link phrase ("Add to cart", "Buy Now", "Search").

* If an image is purely decorative, meaning it's just for show and isn't needed to understand the rest of the page, then it should have an empty alt attribute (alt=""). This effectively "hides" the image from screen readers, as if the image isn't there. That's far preferable to some robot voice reading out "corner" or "bar" or, even worse, just shouting "GRAPHIC" or reading out the source URI if there's no alt attribute. It's required in XHTML anyway.

* Lots of presentational images are better handled as backgrounds in CSS. That little envelope icon next to the "Email this to a friend" link doesn't need to be part of the document. Leave the link as regular text and use CSS to add the icon.

* Don't refer to images in your copy that a user may not be able to see ("click the blue button to continue"), at least not for anything vital to using the site. That's more of a copywriting issue than a code or design issue, but still something to think about.

* Millions of people are colorblind, so don't rely exclusively on color to communicate important information, like "Required fields are red, optional fields are green." That's not helpful at all if you can't distinguish between those colors, so indicate required fields some other way.

* Plan the tabbing order of links and forms, since lots of people navigate with a keyboard (even perfectly-abled people who just prefer it over a mouse).

* Death to the wretched "click here" link, which is utterly meaningless out of context. Some screen reader users will tab through links on the page to navigate, so they may not hear the text before or after a link. The link text should ideally be descriptive of what the link does or where it leads. "<a>Email this to a friend</a>" is useful, "<a>click here</a> to email this to a friend" is useless.

* Use title attributes on links to provide a bit more context about what the link does or where it leads (<a href="/blog/" title="Read my online journal">my blog</a>).

* Be sure your layout doesn't break horribly when the text is enlarged. Text shouldn't overlap other text, or overflow a container onto a background of the same color (e.g. white text in a black box that flows out of the box onto a white page when it's bumped up a notch or two).

* Don't use tables for layout.

* When you do use tables for tabular data, structure them well using thead, th, scope, cols and colgroups, summary, etc.

* Use fieldsets and label elements in forms.

* Include skip links, but don't hide them. Most screen readers will provide a summary of the page headings (if you've used them well) and can jump to any part of the page that way, so skip links aren't only for the blind. They're most useful to keyboard users who don't want to tab through a bunch of links to get to the content. If you hide skip links, you're hiding them from the people who can most benefit from them. If you must hide them, position them off-screen but position them back on-screen on :focus and :active, so they at least show up when tabbing through links.

* If you need to hide any vital content, avoid display:none because most screen readers won't read it. Position it off left instead ({position:absolute; left:-999em;}).

That's just a few things off the top of my head. But the point is that it's not really a ton of extra effort to build accessible websites, it's just a little extra thought. And thinking is free. You don't have to bend over backwards and you don't have to compromise your design or your code. Just be aware of the issues and fold those considerations into your process.

There are plenty of resources online if you want to learn more about web accessibility. Pick up "Building Accessible Websites" by Joe Clark for oodles of good info. It'll change the way you think. "DOM Scripting" by Jeremy Keith is a bit of a beginner's JavaScript book, but it's an excellent guide to the principles of progressive enhancement and graceful degradation.

Also just start thinking more about how disabled people experience the sites you build. Spend an evening watching TV with the volume turned down and closed captioning turned on. If you have a DVD that includes an audio description track, listen to it some time (28 Weeks Later has a really good description track). Unplug your mouse and see if you can get around the web without it for a while.

Of course, to be *really* serious about accessibility you'd need to do real testing with real disabled people, but that's usually not an option. Very few companies employ full-time accessibility experts (I think Google has two, out of 20,000 of employees, but don't quote me on that). So it's usually up to the lowly cube-dwelling coders to take personal responsibility for building in at least some fundamental accessibility. It makes the web a better place, and it's just the right thing to do.

[Codemonkey]

All good tips mrsnrub

I'd like to add that title isn't strictly for hyperlinks, but can be used on all tags including img's, headers, paragraphs, tables what have you... Just to provide some more context and hints however the device likes to treat them (browsers may display them as tooltips for example).

[force10x]

funny, I didn't get any notification of these replies
Anyway, this is an awesome thread. Just printed out the entire thread so I can have a good read.

this is a fantastic beginners guide to developing user friendly websites :-)

Have started reading on JavaScript. hope I can pick up some coding best practices soon.

I generally use 'alt' attributes to describe what the image is all about and the 'title' attribute for hyperlinks so users know where they are being taken.

regarding the "Don't use tables for layouts", well I don't, but for argument sake, we do use Div's for layout, right? then why not tables? as mrsnrub007 mentioned "nature of a div is a content organization device, not a page layout device. "

the same goes for tables. Using a "hybrid" of both tables and CSS can make life so much easy to develop, maintain and address cross-browser issues.

Or again, the reason for avoiding tables-for-layout is accessibility and screen readers?

Thanks again everyone. :-)

[poppa]

Quote: Originally Posted by force10x

[...]
Or again, the reason for avoiding tables-for-layout is accessibility and screen readers?

Primarily yes! The reason is that a screen reader will tell the user in what column in which row the focus is. In practice the user can "tab" its way through the table and therefore it becomes rather annoying if the screen reader says something like "A:1 -> corner.gif" and so on.

Another reason is that a table bases layout is fixed. It's harder, on an redesign for instance, to put the right column to the left and vice versa. And also: Table based layouts tend to become more verbose. It takes more amount of HTML to create a three column layout with TABLE tags than with DIV tags (in general).

[force10x]

hmm...that makes sense.