Next year it's in L.A. and I'll be there.

I'm a man of my word.

Go to the web site and move your mouse cursor towards the top-middle of the layout, just near the point where the mouse would exit the viewport. You should see a dark, transparent bar appear with the text "Skip to content". This is it.

It's the first link you'll see if you browse through the page using your tab key (something used quite a lot in screen readers). It will be read by screen readers even if they're using IE or Mozilla as the rendering engine as the link itself is just moved slightly off screen using negative margins.

I use a transparent PNG for the background so that 1) the layout isn't altered when the link appears and 2) we have different 'themes' on the web site, each with its own colors, and by doing this I don't have to create separate rules under each theme's stylesheet for this link.

I didn't have to make the link appear. I could have kept it off screen. But I decided making it appear like this is a nice little reminder to the public that we do actually think about accessibility when it comes to the web site. And it's proven to be a talking point when people I work with discover it. They ask me "what's that" and I explain the whole thing and the usual response is "Cool! Maybe we need to think about that a little too."

A few weeks back Aviv Raff disclosed a vulnerability in IE 7 and 8 that could also be used to install malware on a system.

This continues to prove my point that features like noscript will have to become native to web browsers in future generations. This idea of browser security from an "only approved" approach rather than a "everyone except" approach. This, in turn, will mean users see your web site first without any Flash or Javascript enabled. Will your web site still work? It better, otherwise these people won't bother enabling these features if they can't know to trust your site.

On a side note, I attempted the exploit Aviv Raff detailed on a few of my own computers (as well as those of friends) and immediately noticed that Vista would warn users before any external applications were run. So even if you were browsing an exploited site you remained fairly well protected on Vista (as long as you don't just click "allow" automatically which, I fear, is exactly what Vista users learn to do within their first week of exposure to the OS.

Still, chalk one up for Vista that if your browser fails you still have a chance at keeping yourself protected.

The interface, while seemingly not that different from a stock Ubuntu install, is miles ahead of any other distro I can think of in terms of quality interface. For starters their boot loader is not only styled nicely (not just simple text), but includes a nice help section explaining some of the more popular boot option to include. Ubuntu certainly has help sections to offer in their boot loader, but the way Linux Mint presents theirs just makes it feel miles ahead.

The login screen feels more polished too. It's not really different from Ubuntu in terms of functionality (again, it's really just their own skin applied to GDM, which Ubuntu uses), but it FEELS more polished.

The desktop has the system menu at the bottom of the screen much like Windows. The "start menu" is fairly similar to what you would find in Vista. Except, again, it just feels more polished. I think part of that is that they haven't over-stylized this menu system. It's something that has to be simple and functional. This is something Windows had until Microsoft went style crazy with XP. I also really like how the "start menu" navigation works. I like how, instead of a giant, screen-high list of programs, you get a short list that is scrollable with your mouse wheel. You can get something like this in Vista, sure, but the responsiveness is so much faster with Linux Mint.

It just feels better.

What you have in Linux Mint is the user-friendly package management system of Debian with the user-friendly interface of Ubuntu polished to a level that makes the system absolutely ready to be installed on the desktops of the general public.

Maybe it's not all rosy minty, though.

It's just the interface. That's the only thing about Linux Mint that makes it stand out. All the underlying bits are still the same old Linux complete with all the hoops any Linux desktop user has to jump through.

For example my wireless card isn't natively supported so I had to setup ndiswrapper. There's an app in Linux Mint to handle this, but getting the drivers was a pain in the ass (it's a NetGear, meaning you have to download the Windows install then copy the relevant files over to Linux).

Even once it was working it wouldn't connect to my AP. I'm not sure if this is a driver or Linux Mint issue. It'll connect to non-encrypted networks just fine, but WPA2 seems to create problems. (Not for my Ubuntu install, which connects just fine.)

The stock video driver had some corruption issues on my system. If I tried to drag a window more than a couple inches the screen started to become corrupt and would eventually freeze up entirely. I had to use EnvyNG from the terminal to get the nVidia drivers installed before I had a stable desktop.

And they've gone and mucked with their FireFox 3 package. Instead of the search box using Google directly it goes through their own kind of proxy to give you a Linux Mint kind of Google interface. I don't like that at all and can't find an easy way to remove that "feature" (other than using a different search engine entirely).

Still. This is a distribution worth taking a peek at. If you've got some hardware laying around that you can drop this on and try out I highly recommend giving it a go. Even if it's just downloading the live CD and running off that for a couple hours. It's worth the time.

In the past I thought I could get away with a simple link at the start of the page then use screen-media CSS to hide it. This, however, has proven to be a bad assumption. I've found many screen readers will first render the web site in the same manner as any web browser like IE or Firefox would. The screen reader then goes through the page looking for text to read back to the user. Thus those hidden elements are also hidden from the screen reader.

So what we need to do is include a link that's rendered on screen that allows users to skip to the content.

But that's going to probably just confuse users who aren't aided by a screen reader. And it might not make sense to others who then might complain that valuable "above the fold" space is being wasted on a link they don't need.

Enter The Web Standards Project web site. They do precisely this. Except I hadn't noticed it before today because they simply hide the link by setting the text color of the link to the background color of the page. The link is there. It's rendered. The screen readers will pick it up, but to the visual user it's effectively invisible.

Now their solution places the link along the gutter space at the top of the web site. However some web sites don't really have that kind of gutter space to hide such a link.

So my solution is to use an absolutely positioned element at the top of the HTML document. This removes the element from the flow of the document effectively leaving the layout visually unaltered. I can then position the element wherever I want, including off the page (position-left: -100000px). The link is still there and if you tab through the page you'll find it's the first link your browser hits.

However in some situations I may want to make the link visible as a means of advertising that I care about accessibility. Or maybe the link still provides some functional use to visual users, especially for those web sites with a very tall masthead or maybe for those users on mobile devices that only have a two-inch screen.

One option might be that if you have some gutter space on your web site (say five to ten pixels at the to of the page) you might position the element up some number of pixels so that the bottom N pixels of the element are still visible (but the same color as the background). Then perhaps apply a :hover state in your CSS that moves the element down to the page whenever a user hovers over it. In this case users would see the element whenever their mouse crossed the upper five to ten pixels of your layout. Visual users would find it by accident, but then know it was there. I don't think the popping-out would become an annoyance to users since it's such a small space to activate that they'd be able to easily avoid it.

Another option might be to just keep the link the same color as the background of the web site, but make the color change in hover state. Again, visual users would only discover this link by accident (or via tabbing), but when they find it they would always know it was there. It's not as blatant an advertisement on your web site's focus on accessibility (since the hit space would be so small), but at the very least it'd be something you could at least show/demo for others.

The point is you have options. All of them derived from a simple link and a bit of CSS. It's a small effort and well worth it to help make your web site more accessible to others.

I've done this and have Ubuntu 8.04 running in MS's own VM on my XP desktop. It's very nice. Now I can test in Konqueror (as well as play with various Linux toys that I find invaluable) while maintaining my XP OS for work (and not have to repartition or reboot for that matter).

A couple of notes to share.

I could only boot off the live CD by manually adding the noreplace-paravirt option. I then had to add this option into the bootloader as well after the OS was installed. I find including vga=791 helpful as well, but not required.

In my xorg.conf file I had to add the following to my screen section:

DefaultDepth 16
SubSection "Display"
  Depth 16
  Modes "1280x1024"
EndSubSection

This got me at the intended 1280x1024 resolution I wanted. The color depth is needed because Ubuntu will default to 24 bit color depth which Virtual PC has problems with.

I also added the following to my monitor section:

DisplaySize 338 277

Which changed the DPI of the screen to 96 (X defaults to 75dpi I believe) which makes small text much more readable.

I had to add snd-sb16 on its own line to /etc/modules in order to get sound working. However the sound is very scratchy. From what I've read this is common and there's probably nothing that can be done through module options to improve this. That's unfortunate.

I also had to add options psmouse proto=imps to /etc/modprobe.d/options in order to get the mouse wheel recognized by the OS. With that done I then had to add the following the inputdevice section for my mouse:

Option "Protocol" "ImPS/2"
Option "ZAxisMapping" "4 5"

And now the scroll wheel works in the Ubuntu VM.

Give it a try. Both Virtual PC 2007 and Ubuntu are free downloads and you don't have to worry about mucking with your host OS or partitioning drives.

My setup now is that I have dual monitors and on one I've got the Ubuntu VM in full screen mode and on the other I have my XP desktop.

FYI: To free your mouse from the VM all you need to do is press the RIGHT ALT KEY. It must be the right one, the left alt key won't work.

I had an anchor within a web page. It was an empty anchor, but nonetheless I decided to set it with a style of display:none; so that some random browser doesn't add an extra line of whitespace to the document where the anchor is.

But as it turns out, by hiding the anchor the bookmark is removed from the document. So URLs like index.htm#bookmark would no longer jump to the bookmark within the page. Once the anchor was displayed again the bookmark would work.

Now if I really cared about browsers getting silly and adding space where there shouldn't be any I could always apply a style of line-height: 0;. (visibility:hidden; doesn't work because the space generate by the element is still there even if the content is hidden.) But I didn't bother replacing the style with something new, I just removed the original CSS. I figure I was being just a little too anal there.

The point: setting display:none; on anchors will remove their bookmark capability.

* html #content-column,
*:first-child+html #content-column {
margin-left: -1px;
}

This is wrong. The correct CSS should be:

* html #content-column {
margin-left: -1px;
}
*:first-child+html #content-column {
margin-left: -1px;
}

The reson being that IE 5 doesn't like the *:first-child+html IE7 hack and will ignore the entire rule set. So you have to keep them separated.

If you have Windows XP and install SP3 you will be locked into IE7. You will not be able to downgrade to IE6.

Now I'm willing to bet within a few weeks of SP3's release we'll see instructions on how to get IE6 up and running. At the same time I don't see this as an entirely bad thing. IE7 is certainly better than IE6 in terms of standards compliance. But I'm not a fan of locking users in like this.

I wonder, though, why you're locked in. Is IE7 some how integral to SP3? I thought Microsoft was suppose to separate its browser from its OS. If they're integrated again that might break certain judgements made in the EU.

But now we've got higher resolution screens. Screens that are 15 inches in physical size but support up to 1280x1024 in resolution. At that resolution things look very tiny and are almost unreadable on a 15 inch screen.

The solution is to increase the DPI. In doing so Windows will increase the size of the fonts and other window objects (buttons, bars, etc) making letters at 1280x1024 @ 120 dpi look the same as letters at 1024x768 @ 96 dpi. The added benefit is that fonts will have an increased resolution, meaning more space to draw it, meaning they'll look stronger, crisper, and in general a whole lot better.

However, images still don't scale. A 190 pixel wide image is still 190 pixels wide. At 1024x768 it will eat up 10% of the screen's width, while at 1280x1024 it'll eat up only 7%. This means user interfaces that use images, icons, video, etc. may wind up looking odd or (worst case) breaking entirely under a DPI different from the one it was designed at.

This includes web pages.

Thus Microsoft created something I've seen unofficially called active scaling. It's a little known feature that's been around since IE 6.0 which, when enabled, will resize images to fix the same physical space on screen as they would have at a lower DPI. The math is [image resolution] * ( 120 / 90 ). So in the case of a 190 pixel wide image you'd get 190 * 1.25 = 237.5 pixels wide.

Uh oh.

A decimal point.

IE does not do well with decimal points.

And this time IS NO DIFFERENT!

Two users contacted me about the Bridgewater State College web site not loading properly. The body of the page was being pushed down below the left-hand column. They sent me screenshots and it was immediately apparent they had done something to increase their system font sizes.

However I notice the edges of the images were blurry or jagged. It became obvious there was something more that just increased font sizes at work here.

Through some luck I was able to track the source of the problem to a rounding bug in IE related to active scaling.

Since I've had more than my fair share of rounding bugs in IE I knew immediately what the fix for it was. Simply add a -1px margin to the opposing side of any floated element. Meaning if you've got an element floating right, you set -1px to the left-margin of that box. Or if it's left floated, -1px margin to the right side of the box.

Here's a simple CSS hack that targets IE for this purpose:

* html #content-column,
*:first-child+html #content-column {
  margin-left: -1px;
}

Obviously replace #content-column with your element's selector and change margin-left to margin-right as needed.

These rounding bugs have been with IE since it's creation. They are something Microsoft has known about for years, and yet they are either unable or unwilling to fix them. I believe they are part of a larger issue, related to all the hasLayout bullshit. I think the rendering engine for IE needs a complete rewrite. But Microsoft won't do that. They haven't yet, why start now? I think the reason for this is because they don't care. Why waste resources resolving a bug that only a handful of web developers are annoyed by? Web developers have been working around IE for years, they can keep working around IE.

I wish we, as web developers, could simply say "Fuck IE!"; to leave these bugs rather than hack around them. Tell our users to simply use a different browser because IE is so poor.

But we can't.

If we do this we're out of a job. IE still has the majority share of the browser user base. And why? Because it comes free with the most installed desktop OS on the planet. If we don't work around it our web site become ugly or even inaccessible to the majority of the internet population. This is simply bad business.

And I fear any attempt to educate users about the problematic Internet Explorer will fall on deaf ears. The only thing that will rid us of IE is the same thing that rid us of Netscape 4: time. A lot of time.

Once we got a template that Institutional Communications (the new name for the Public Affairs dept) was happy with it was handed off to me to convert into something usable. IE/Mac users will not have a great experience (still working on that), but it should be good back to IE 5.0. There are lots of areas where I see improvements being made over the next year. Besides compatibility I see adding some extra style-switching bits to the left of the font-size/search bar at the top right such as picking what font to use for the base of the layout. I also see going through the CSS and trying to greatly compact it to cut down on the amount of data people have to download.

I've already started doing that with the images. Originally many of the "brand images" were 300-400k in size. I've cut a lot of that down to well under 100k per image. A lot of the second-level pages still need to be re-compressed and I'll eventually get to them. Right now there's still a lot of back-end coding to work on and that's my primary focus for the next few weeks.

I was thinking about producing a version to post on my site for the world to use, but decided fairly quickly that would be a bad idea. It's a design that is certainly wholly unique to BSC and it should probably stay that way for at least a little while.

We opened a demo version to people on-campus for a few weeks prior to going live. In that span of time we really haven't had much in the way of negative feedback. The actually day we rolled it out into production we had virtually zero feedback. This, in my opinion, was a good sign. It's rare that you'll hear about the good things you do, but you'll always hear (very loudly) about the bad things you do. The calm of the roll-out seems to indicate we've got a layout people like.

There are some things I don't like, such as color and typographical choices in some parts of the web site, but I am not alone in creating nor maintaining this web site and so it can't be only about what I think is best.

I still believe it's not a bad idea to stay away from using Calibri in web sites (even though we use it for most of the headings). The size differences between Calibri and Arial mean people who don't support Calibri will have a much different experience on your web site.

Well just wanted to post a note about that (it's turned into a novel).

Have fun!

I keep saying. Let's say it one more time. Embedded web browser tech (like flash, javascript, java, etc) IS BAD. It just adds more complexity to what should be a very simple application. More complexity leads to a greater number of points to attack your computer.

This is one more case for users to, by default, not enable Flash on their browser unless viewing a trusted web site. If we reach that day where such practice is common (and the more Flash vulns that get released, the closer we get) then web sites that rely on Flash will be UNUSABLE unless a user trusts the site. But how can the user learn that the site is trustworthy if they can't even see it?

Stay away from designing your entire web site in Flash. You're just setting yourself up for some seriously problems in a few years when web browser security finally gets taken seriously.

I would love to hear any feedback you have. Either here or via e-mail.

--

Found a fix for Netscape 6 not working with horizontal menus. Seems setting the height to 100% whenever an anchor inside an LI is hovered will get Netscape 6 to not hide the menu items as you mouse over them. Thus I've updated Ruthsarian Menus with the fix. It's nothing big, but if you're curious the fix can be found at the bottom of the stylesheet.

--

Downloaded iCab 4 and gave it a go. It looks to be a very solid browser. I ran it by the new Comic layout and everything worked great, including the dropdown menus. This shouldn't be a surprise since it worked in iCab 3; I guess I'm just jaded from working with IE.

--

Allow me to direct you to BTreeHugger's Blog, specifically his CSS category. You will find a ton of great information, but best of all is his maintaining of a CSS mastergrid where virtually all known CSS hacks are listed in a table against what browsers they work with. It's an amazing resource that every CSS developer should have bookmarked.

--

And while taking a break from developing your CSS, might I suggest some great reading? The Gargoyles comic. It continues where the series left off and let me tell you that the story has really come on strong with the last couple issues (#7 & #8). The first few issues were a lot of reintroductions to make sure people knew who was who. Now we're into meeting new clans and new enemies. And the writing is all done by Greg Weisman, the series co-creator. In his spare time Greg is also writing, story editing, and producing the new television series The Spectacular Spider-Man.

Pick it up today!

So here it is, my latest creation: Comic.

The layout explains most of what the layout is about. But to put it briefly, this layout is about conserving horizontal space for content and not navigation. It's also a showcase for style switching.

I realize the vertical toolbox on the right-side could just as easily be a horizontal piece perhaps placed above the layout at the very top of the page or under the masthead. I liked the idea of making it a vertical toolbar though for a couple reasons. One is it makes the layout feel almost like various popular graphics programs that have vertical toolboxes. The other is I get a sick pleasure in the irony of preaching vertical space conservation and then wasting about 2ems worth with that silly thing.

Getting the buttons to scale with the changing font size of the page was actually a bit tricky. Turns out most browsers set input buttons to a fixed text size that doesn't scale as you scale the font-size of any of the button's parent elements (e.g. the BODY). So you have to explicitly set font-size:1em to input elements. Then it will scale.

The font selection buttons have different font sizes. So instead of saying "width:1.6em" for all three, each one has a different width scaled up or down, depending on the font size for that button, so they'll all be the same rendered size. Check the CSS.

It's surprisinglycompatible, even Mac/IE 5.0 works great with this layout. Netscape 6 doesn't like horizontally centered dropdown menus so I'll need to fix that, but it's a ruthsarian menus issue not a comic issue.

No packaged download yet (although you'll see there's a spot to put a link to one as soon as I'm ready). But if you want to play around with it I'm sure most of you can figure out where the various bits are and how to download them.

So give it a go. Put it through its paces. Let me know what you think or what you experience.

Anyways, I've been working on a redesign for Bridgewater State College and the roll-out happens two weeks from today. Of course I'll be tweaking the hell out of it every day up until launch because... well nothing's ever really finished when it comes to a web site, is it?

We started taking feedback on the design based on a preview that's available to anyone browsing from on-campus. The topic of accessibility came up from one user's comments with regards to screen readers and so I set about revisiting some concepts I had developed early on for the design when it comes to screen readers.

First thing's first: "skip links" (skip to nav, skip to content) that are hidden with screen media only stylesheets DO NOT NECESSARILY WORK. As it turns out screen readers do.. amazingly... just that. They read the screen. So if your user has, say, IE 7 or Firefox rendering the page, those screen media elements are being applied and the skip links are hidden.

Specialty applications that browse websites for visually impaired users will probably pick these links up, but the point is not all screen readers will!

The result is to either show these links or make sure your site is easy to navigate for blind users. A simple test here is to just use the tab key and see in what order links are accessed.

Originally the layout I had designed was source-ordered. But after this simple tab-test I found that the navigation elements were the last thing to be accessed. This means a user with a screen reader and Firefox wouldn't see the navigational elements of the website until they got to the very end. Not at all a good thing.

So I've removed the source ordering. And, honestly, doing that feels better from a semantic standpoint as well. Index before content - like books.

Yes, I could have used the TABINDEX property, but it just wouldn't be feasible with how the template is used and how department managers update the web site.

Anyways, the point here is that source-ordered layouts might not be the most accessible thing in the world.

--

CSS-based drop-down menus are another problem. Try accessing your drop-down menu using just your tab key. YOU CAN'T! Unless your mouse is set to automatically position itself over a link you've selected using tab the link never enters the hover state and so all those :HOVER pseudoclass rules are ignored.

What about :FOCUS?

That works, for the first link. You tab over to the link and you see the drop-down menu. But as soon as you hit tab again to go to the first link in the sub-menu your menu disappears. Why? Because the link no longer has focus, a sub-menu link does. And, unlike with :HOVER, if you use :FOCUS on a block element and one of its children has focus, that parent block element, for whatever reason, is not considered to have focus.

This, I think, is a major flaw with current web browsers. If a child element has focus, so should its parent. Just like :HOVER. If this were how browsers worked then using :FOCUS would make CSS-based drop-down menus accessible for blind users with screen readers.

For now I have two options. Either display content in the drop-down menus outside of the menu or make sure each sub-menu option is accessible through the page its parent links to.