<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
	<title>Johansson, Roger</title>	<link>http://tc.eserver.org/authors/Johansson,_Roger</link>
	<description>A bibliography of works by Johansson, Roger in the field of technical communication.</description>
	<language>en-us</language>
	<copyright>Copyright (c) 2005-08 by the EServer. All rights reserved.</copyright>
	<managingEditor>tclib-editorial@eserver.org (TC Library Editorial Board)</managingEditor>
	<webMaster>webmaster@eserver.org (Geoffrey Sauer)</webMaster>
	<image>
		<url>http://tc.eserver.org/images/newlogo.gif</url>
		<title>Johansson, Roger</title>
		<link>http://tc.eserver.org/dir/Johansson,_Roger</link>
	</image>
	<item>
		<title>HTML 5 and the Summary Attribute</title>
		<link>http://tc.eserver.org/35392.html</link>
		<guid>http://tc.eserver.org/35392.html</guid>
		<description>As I wrote in Help screen reader users by giving data tables a summary, the summary attribute on the table element can be used to provide information that helps non-sighted users understand data tables. The current draft of HTML 5 requires that validators display a warning if they encounter a summary attribute, since it is now an &apos;obsolete but conforming feature.&apos;</description>
	</item>
	<item>
		<title>Styling Form Controls with CSS, Revisited</title>
		<link>http://tc.eserver.org/34259.html</link>
		<guid>http://tc.eserver.org/34259.html</guid>
		<description>Attempting to use CSS to make form controls look similar across browsers and operating systems in an exercise in futility. It simply cannot be done. Because of all this I spent way too much time creating a total of 224 screenshots showing the effects of various CSS rules applied to form controls.</description>
	</item>
	<item>
		<title>Developing With Web Standards</title>
		<link>http://tc.eserver.org/32946.html</link>
		<guid>http://tc.eserver.org/32946.html</guid>
		<description>This document attempts to explain how and why using web standards will let you build websites in a way that saves time and money for developers and provides a better experience for visitors. Also discussed are other methods, guidelines and best practices that will help produce high-quality websites that are accessible and usable to as many people and browsing devices as possible.</description>
	</item>
	<item>
		<title>Accessible Expanding and Collapsing Menu</title>
		<link>http://tc.eserver.org/32496.html</link>
		<guid>http://tc.eserver.org/32496.html</guid>
		<description>A website’s navigation should, in my opinion, be visible and straightforward, not hidden away like this or in flyout/dropdown menus. But...</description>
	</item>
	<item>
		<title>Creating Bulletproof Graphic Link Buttons With CSS</title>
		<link>http://tc.eserver.org/32499.html</link>
		<guid>http://tc.eserver.org/32499.html</guid>
		<description>A CSS problem I have been wrestling with lately is how to create a bulletproof shrinkwrapping graphic button. By that I mean an image-based button that will expand and contract to fit the amount of text it contains. It is a very useful technique for CMS-driven sites that allow the client to change the text that is displayed on buttons, as well as for multilingual sites.</description>
	</item>
	<item>
		<title>Use Only Block-Level Elements in Blockquotes</title>
		<link>http://tc.eserver.org/32500.html</link>
		<guid>http://tc.eserver.org/32500.html</guid>
		<description>The blockquote element is not allowed to have text or inline elements as direct descendants. Only block-level (and in HTML 4.01 Strict, script) elements are allowed unless you use a Transitional Doctype, in which case both block-level and inline elements are allowed. But there are plenty of sites that use a Strict Doctype and still have blockquote elements that contain inline elements.</description>
	</item>
	<item>
		<title>Another Look at HTML 5</title>
		<link>http://tc.eserver.org/32501.html</link>
		<guid>http://tc.eserver.org/32501.html</guid>
		<description>It has become evident to me that some of my previous comments about HTML 5 and what is going on in the HTML Working Group are the result of misunderstanding and overreacting on my part. I no longer think things are quite as bad.</description>
	</item>
	<item>
		<title>Help Keep Accessibility and Semantics in HTML</title>
		<link>http://tc.eserver.org/32503.html</link>
		<guid>http://tc.eserver.org/32503.html</guid>
		<description>If you think accessibility and semantics are important and should be improved in the next version of HTML, you need to act.</description>
	</item>
	<item>
		<title>How to Prevent HTML Tables from Becoming Too Wide</title>
		<link>http://tc.eserver.org/32504.html</link>
		<guid>http://tc.eserver.org/32504.html</guid>
		<description>The layout model of tables differ from that of block level elements in that they will normally expand beyond their specified width to make their contents fit. At first that may sound like a good thing – and it often is – but it makes it possible for oversized content to make text unreadable or completely break a site’s layout, especially in Internet Explorer.</description>
	</item>
	<item>
		<title>Unobtrusive and Keyboard Accessible Connected Select Boxes</title>
		<link>http://tc.eserver.org/32506.html</link>
		<guid>http://tc.eserver.org/32506.html</guid>
		<description>Any web developer who has created a reasonably complex form is probably aware of the concept of multiple select elements that are connected – choosing something from one select box either makes a new select box appear or changes the options of one that is already visible.</description>
	</item>
	<item>
		<title>Guidelines for Creating Better Markup</title>
		<link>http://tc.eserver.org/32507.html</link>
		<guid>http://tc.eserver.org/32507.html</guid>
		<description>I’ve mentioned several times here that I feel writing markup (or any other code, for that matter) is a craft. I take pride in writing as lean and clean code as possible. From the looks of things there aren’t a whole lot of other Web professionals that feel that way, but we do exist.</description>
	</item>
	<item>
		<title>Lame Excuses for Not Being a Web Professional</title>
		<link>http://tc.eserver.org/32509.html</link>
		<guid>http://tc.eserver.org/32509.html</guid>
		<description>Excuses that may be valid in some circumstances are too often used to cover up somebody’s lack of knowledge about modern Web design or development.</description>
	</item>
	<item>
		<title>Failed vs. Unfailed Redesigns of Newspaper Websites</title>
		<link>http://tc.eserver.org/32510.html</link>
		<guid>http://tc.eserver.org/32510.html</guid>
		<description>A comparison of the redesigned websites of two Swedish newspapers, GP.se and HD.se, that were both launched in late 2006.</description>
	</item>
	<item>
		<title>Internet Explorer and the CSS Box Model</title>
		<link>http://tc.eserver.org/32424.html</link>
		<guid>http://tc.eserver.org/32424.html</guid>
		<description>One of the differences between Internet Explorer and standards compliant Web browsers that cause a lot of trouble for CSS beginners is the CSS box model. Since the box model is what browsers use to calculate an element’s total width and height, it is quite understandable that different browsers producing different results can be both confusing and frustrating.</description>
	</item>
	<item>
		<title>Multiple Form Labels and Screen Readers</title>
		<link>http://tc.eserver.org/32425.html</link>
		<guid>http://tc.eserver.org/32425.html</guid>
		<description>Just about every website needs some forms. Sometimes there are many of them, sometimes just a single contact form. Regardless of their number, they need to be usable and accessible, which can sometimes be a little more work than it would be if theory and practice aligned a little better.</description>
	</item>
	<item>
		<title>Specify a Maximum Width for Em-Based Layouts</title>
		<link>http://tc.eserver.org/32439.html</link>
		<guid>http://tc.eserver.org/32439.html</guid>
		<description>One technique that can easily make reading a site a lot more uncomfortable is using an elastic, or em-based, layout such as the one I use here (and talk about a bit more in detail in Fixed or fluid width? Elastic!) without specifying a maximum width in another unit.</description>
	</item>
	<item>
		<title>Looking for Open Source CMS and Portal Software Options</title>
		<link>http://tc.eserver.org/32440.html</link>
		<guid>http://tc.eserver.org/32440.html</guid>
		<description>I find choosing a CMS incredibly difficult, and evaluating them is very time consuming and often frustrating. There are hundreds of options, one worse than the other. To date I have never come across a CMS that doesn’t have serious flaws. Even if a CMS looks good at a glance, once you start digging deeper you will always encounter problems with usability, accessibility, and front-end code.</description>
	</item>
	<item>
		<title>Helping Others Understand Web Accessibility</title>
		<link>http://tc.eserver.org/32441.html</link>
		<guid>http://tc.eserver.org/32441.html</guid>
		<description>When I hold workshops for people who want to learn more about web standards and accessibility, I often notice that the attendants really have tried to improve their accessibility knowledge. But they get overwhelmed when they go to the official documentation from the W3C and try to understand it.</description>
	</item>
	<item>
		<title>Overdoing Accessibility</title>
		<link>http://tc.eserver.org/32445.html</link>
		<guid>http://tc.eserver.org/32445.html</guid>
		<description>Sometimes when people first learn about Web accessibility they look for quick ways of improving the sites they build. This often leads to misuse or overuse of certain HTML features that are meant to aid accessibility, but when used wrongly have no effect and can actually have the opposite effect by making the page less accessible and less usable.</description>
	</item>
	<item>
		<title>Accessibility is Part of Your Job</title>
		<link>http://tc.eserver.org/32446.html</link>
		<guid>http://tc.eserver.org/32446.html</guid>
		<description>Accessibility is one of the fundamentals of the Web, so how people who claim to be passionate about the Web and say that they deliver high quality can choose to ignore it is beyond me.</description>
	</item>
	<item>
		<title>Choosing a JavaScript Framework</title>
		<link>http://tc.eserver.org/32447.html</link>
		<guid>http://tc.eserver.org/32447.html</guid>
		<description>once you’ve decided that using a JavaScript framework is appropriate for the task you’re faced with, it can be hard to choose the one that is right for you. And to make things worse, what is right for you may not be right for your co-workers.</description>
	</item>
	<item>
		<title>Choose an Accessible Image Replacement Method</title>
		<link>http://tc.eserver.org/32449.html</link>
		<guid>http://tc.eserver.org/32449.html</guid>
		<description>The technique of using CSS to replace normal HTML text, mostly for headings, with a background image in order to achieve a particular look has been talked about many, many times since early 2003.Several different image replacement methods have been proposed, each with their pros and cons. Some methods create accessibility problems, while others place restrictions on the type of image you can use or force you to use extraneous markup. No method that I am aware of is perfect.</description>
	</item>
	<item>
		<title>The Rules of Unobtrusive JavaScript</title>
		<link>http://tc.eserver.org/32450.html</link>
		<guid>http://tc.eserver.org/32450.html</guid>
		<description>One of the most important things to keep in mind when writing JavaScript for the Web is to make it unobtrusive, since You cannot rely on JavaScript being available.Sadly, there are many developers who do not seem to spend any energy at all on considering how to do that. Instead they choose to blindly forge ahead and assume that everybody who comes visiting will have full support for JavaScript and use a mouse.</description>
	</item>
	<item>
		<title>Manual for Apple VoiceOver in Mac OS X 10.5 Leopard</title>
		<link>http://tc.eserver.org/32451.html</link>
		<guid>http://tc.eserver.org/32451.html</guid>
		<description>Apple’s screen reader, VoiceOver, comes bundled with Mac OS X (yes, it’s free) and has received a number of updates in Mac OS X 10.5 Leopard. The updates include a new voice, Braille support, and improved navigation and searching.</description>
	</item>
	<item>
		<title>Does Advanced Search Sound Too Advanced?</title>
		<link>http://tc.eserver.org/32452.html</link>
		<guid>http://tc.eserver.org/32452.html</guid>
		<description>Should advanced search be called something else to sound more friendly and inviting, and would it make more people to use it when they need to?</description>
	</item>
	<item>
		<title>Use the Label Element to Make Your HTML Forms Accessible</title>
		<link>http://tc.eserver.org/32453.html</link>
		<guid>http://tc.eserver.org/32453.html</guid>
		<description>There are plenty of articles and tutorials that describe how to create accessible HTML forms out there. Despite that it is common to come across forms that do not use a single label element and forms that use label elements but do so incorrectly.</description>
	</item>
	<item>
		<title>Keep Browser Lock-Out a Thing of the Past</title>
		<link>http://tc.eserver.org/32454.html</link>
		<guid>http://tc.eserver.org/32454.html</guid>
		<description>Browser sniffing and deliberately preventing people using a so-called unsupported browser from entering a site is a thing from the past that we do not need these days.</description>
	</item>
	<item>
		<title>Screen Readers Sometimes Ignore display:none</title>
		<link>http://tc.eserver.org/32455.html</link>
		<guid>http://tc.eserver.org/32455.html</guid>
		<description>Using display:none does not always hide content from screen readers like JAWS and Window-Eyes, but there is a workaround.</description>
	</item>
	<item>
		<title>The W3C Process May Be Slow, But Browser Vendors are Slower</title>
		<link>http://tc.eserver.org/32456.html</link>
		<guid>http://tc.eserver.org/32456.html</guid>
		<description>Don’t blame the W3C for being slow when the real problem is browser vendors not implementing existing specifications fully and properly.</description>
	</item>
	<item>
		<title>POSH: Plain Old Semantic HTML</title>
		<link>http://tc.eserver.org/32459.html</link>
		<guid>http://tc.eserver.org/32459.html</guid>
		<description>POSH, in case you haven’t heard of it already, is short for “Plain Old Semantic HTML”, and is obviously much quicker and easier to say than “valid, semantic, accessible, well-structured HTML”. Unfortunately POSH - semantic markup - is also something most people building websites or creating content for the Web have yet to discover.</description>
	</item>
	<item>
		<title>Autopopulating Text Input Fields with JavaScript</title>
		<link>http://tc.eserver.org/32460.html</link>
		<guid>http://tc.eserver.org/32460.html</guid>
		<description>Few people will argue against the need to explain to users what they are supposed to enter into text input fields. One common workaround when no label can be displayed is to put some placeholder text in the text field and let that act as the label.This approach works reasonably well, but it burdens the user with having to clear the input before entering their own text, which can lead to frustration and mistakes. An approach that avoids that is using JavaScript to clear the input when it receives focus. Since that won’t work when JavaScript support is missing, JavaScript should be used to insert the placeholder text as well.</description>
	</item>
	<item>
		<title>Helping Your Client Maintain Markup Quality</title>
		<link>http://tc.eserver.org/32462.html</link>
		<guid>http://tc.eserver.org/32462.html</guid>
		<description>One thing that is particularly frustrating with caring about Web standards and accessibility is what often happens after your work is done and a site is handed over to the client.</description>
	</item>
	<item>
		<title>The Resurrection of Downloadable Web Fonts</title>
		<link>http://tc.eserver.org/32463.html</link>
		<guid>http://tc.eserver.org/32463.html</guid>
		<description>Despite it being in the CSS 2 specification from 1998, downloadable fonts specified with the @font-face at-rule never caught on. The main reason was that Microsoft and Netscape chose to support different font formats, neither of which was in wide use. However, that may be about to change. As reported in Downloadable Fonts, recent nightly builds of Apple WebKit (not the normal nightly build but a feature branch) support @font-face rules with TrueType fonts. The browser will download the font file you specify and use the typeface it contains just like any other.</description>
	</item>
	<item>
		<title>Choosing the Right Doctype for Your HTML Documents</title>
		<link>http://tc.eserver.org/32465.html</link>
		<guid>http://tc.eserver.org/32465.html</guid>
		<description>In this article I will look at the doctype in a lot more detail, showing what it does and how it helps you validate your HTML, how to choose a doctype for your document, and the XML declaration, which you’ll rarely need, but will sometimes come across.</description>
	</item>
	<item>
		<title>The Dilemma of Comments</title>
		<link>http://tc.eserver.org/32467.html</link>
		<guid>http://tc.eserver.org/32467.html</guid>
		<description>Abuse has made me seriously consider – several times – disabling comments. I’m ambivalent about it. On the one hand it would make writing and publishing much easier. Write something, proofread it, publish.</description>
	</item>
	<item>
		<title>How to Create an Unobtrusive Print this Page Link With JavaScript</title>
		<link>http://tc.eserver.org/32468.html</link>
		<guid>http://tc.eserver.org/32468.html</guid>
		<description>When a client requests that I duplicate functionality that should be (and is) handled by web browsers, I always try to avoid doing it by explaining why I believe it is better to leave such functionality to the browser. Most of the time I succed, but occasionally I don’t.</description>
	</item>
	<item>
		<title>Can the alt Attribute Be Omitted Without Hurting Accessibility?</title>
		<link>http://tc.eserver.org/32469.html</link>
		<guid>http://tc.eserver.org/32469.html</guid>
		<description>In the current editor’s draft of the HTML 5 specification, the alt attribute for images is no longer required. I am not convinced that this is a good idea.</description>
	</item>
	<item>
		<title>Are We Designers or Developers?</title>
		<link>http://tc.eserver.org/32470.html</link>
		<guid>http://tc.eserver.org/32470.html</guid>
		<description>On the about page of this site I used to call myself a “developer/designer/occasional writer”. It’s a bit confusing, and I still find it hard to know what to answer when someone asks me what I do for a living. Am I a Web designer? A Web developer? A Web programmer? All of them? Neither? It really is a difficult question to give a simple answer to.</description>
	</item>
	<item>
		<title>Why Standards Still Matter</title>
		<link>http://tc.eserver.org/31960.html</link>
		<guid>http://tc.eserver.org/31960.html</guid>
		<description>The last couple of years may have seen an increase in the level of interest and action around web standards. But it still isn’t filtering down to the mainstream.</description>
	</item>
	<atom:link href="http://tc.eserver.org/authors/Johansson,_Roger.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>