You can view the slides on SlideShare, or download the slides here:

CSS3: Using media queries to improve the web site experience (PDF, 2.4 mb)

Here are several links to related resources, some of which are in the slides plus many that were not but which I recommend and think you’ll find useful.

Media query articles, tutorials, and tools

• “Essential considerations for crafting quality media queries” by me
• Excerpt of Chapter 6 of Stunning CSS3 on media queries by me
• “Design for a Target Experience First” by Nathan C. Ford
• The Goldilocks Approach by Front design agency
• “21 top tools for responsive web design” by Denise Jacobs for .net Magazine
• “Responsive Web Design Guidelines and Tutorials” by Smashing Magazine
• “An introduction to meta viewport and @viewport” by Andrea Bovens for Dev.Opera
• “Why images appear blurry on mobile devices” by Christopher Cohen

Dealing with IE 6-8 support

• Respond script by Scott Jehl
• css3-mediaqueries.js script by Wouter van der Graaf
• “Windows mobile media queries” by Jeremy Keith
• “Targeting mobile-optimized CSS at Windows Phone 7” by IE Mobile Team

Fluid/liquid layout

• Flexible Web Design: Creating Liquid and Elastic Layouts with CSS book by me
• “70+ essential resources for creating liquid and elastic layouts” by me

Media query inspiration

• Mediaqueri.es gallery
• My media query inspiration bookmarks on delicious and Gimmebar
• My liquid layout inspiration bookmarks on delicious and Gimmebar
• “Examples of flexible layouts with CSS3 media queries” by me

Related Posts:

• Essential considerations for crafting quality media queries
• There’s already a book on responsive web design. Want to win it?
• Examples of flexible layouts with CSS3 media queries
• Adobe MAX slides and resources
• Web Directions USA slides and resources

You can view the slides on SlideShare, or download the slides here:

Web Accessibility (PDF, 2 mb)

Here are several links to related resources, some of which are in the slides plus many that were not but which I recommend and think you’ll find useful.

Top sites on accessibility

These are my favorite sites to read to learn accessibility techniques and news on developments in technology like HTML5 and screen readers. I highly recommend subscribing to the RSS feeds of these.

• WebAIM
• Accessible Culture
• The Paciello Group Blog
• Yahoo! Accessibility Lab’s Library

WCAG 2.0

• “How to Meet WCAG 2.0” customizable quick reference from the W3C
• “WebAIM’s WCAG 2.0 Checklist“

WAI-ARIA

• ARIA portal on Mozilla Developer Network
• “Videos of Screen Readers Using ARIA, Updated” by me

HTML5 and accessibility

• HTML5accessibility.com created by The Paciello Group
• “JAWS, IE and Headings in HTML5” by Jason Kiss, Accessible Culture

CSS and accessibility

• “Clip your hidden content for better accessibility” by Theirry Koblentz on Yahoo! Accessibility Lab’s Library
• “CSS in Action: Invisible Content Just for Screen Reader Users” by WebAIM
• “Better for Accessibility” by Derek Featherstone

Creating accessible content

• “Text alternatives for images: a decision tree” by 4Syllables
• “Accessibility for web writers” article series by 4Syllables
• “Using the HTML title attribute” by Steve Faulkner, The Paciello Group
• “HTML5 Accessibility Chops: form control labeling” by Steve Faulkner, The Paciello Group
• “Making Compact Forms More Accessible” by Mike Brittain on A List Apart
• “‘Skip Navigation’ Links” by WebAIM
• “Detecting if images are disabled in browsers” by Steve Faulkner, The Paciello Group
• “Accessible JavaScript: Beyond the Mouse” by James Edward on Sitepoint
• Black Widow Web Design’s Color Contrast Analyser tells you if contrast is too high for people with dyslexia
• Color Tools links to a bunch of traditional color contrast analyzer tools

Screen readers

• NVDA: free, Windows
• VoiceOver: included on Mac and iOS
• JAWS: free trial version
• Window-Eyes: free trial version
• “Screen Reader User Survey #3 Results” by WebAIM

Related Posts:

• Videos of screen readers using ARIA, updated
• A few links: CSS and accessibility
• Videos of screen readers using ARIA
• Media queries presentation at indieconf
• CSS3 book launch event

@media screen and (max-width:500px) {
}

There are some additional little syntax details, but this is basically all you need to know to actually make a media query work. Once you memorize this short, simple syntax and the various media features that are available, you could technically say that you know how to use media queries. But knowing how to use media queries effectively requires a whole lot more considerations than just where to put an @ or {.

Designing web layouts with media queries is a process. You need to keep them in mind from the very beginning and make decisions at several points about how to integrate them in ways that will make the most sense for your site. There are very few always-right or always-wrong answers. What type of media query set-up would work best will depend on your site, your users, and your own capabilities and experience. But I wanted to cover the pros and cons of some of the essential considerations that go into crafting robust media query-driven layouts. These considerations include whether to:

• Make the media queries embedded or external
• Overlap or stack your media queries
• Make mobile or desktop styles the default
• Use conditional comments or JavaScript to add support for IE 8 and earlier versions

This article is just as much for me as it is for you—it can be hard to keep track of all the different configuration variations you can use! Hopefully I’ll be able to make the pros and cons of the various approaches clearer so you can use this article to guide your decisions when you start a project involving media queries.

How to include your media queries: embedded vs. external

There are two ways to include media queries in your site: embed them within a style sheet or include them in a call to a separate, external sheet.

Here’s what an embedded media query looks like (pretend that we’re inside a style sheet):

body {
    background: gray;
}
@media all and (max-width:500px) {
    body {
        background: blue;
    }
}

For an external media query, simply extend the existing media part of the link element or @import rule:

<link href="narrow.css" rel="stylesheet" media="only screen and (max-width:500px)">

@import url(narrow.css) only screen and (max-width:500px);

Browsers that don’t support media queries won’t download these sheets, but browsers that do will download them all, regardless of whether they’re needed or not for the current viewing scenario. (The background images inside the currently-not-needed sheets won’t download, however.) On the one hand, this makes sense—the user could change his or her orientation or window size, and those alternate styles would suddenly need to be called into action. On the other hand, Greg Rewis found that even if you create a sheet that it seems like a device could never possibly use, such as a sheet for a max-width of 700 pixels never being needed by an iPad with its 768 x 1024 resolution, the device will download it anyway. But Chris Coyier pointed out to me that you could have an iframe in a page, for instance, that might need to use that smaller style sheet—so on the third hand, I guess this behavior is logical and unavoidable, if not perfect.

The pros and cons

* I’ll go into the details of both of these approaches to dealing with old versions of IE later on in this article, so sit tight if this IE stuff doesn’t make sense just yet.

The bottom line

In most situations, I think that embedded is the better way to go. I’ve never been a fan of separating out styles into separate sheets because I find it harder to keep things organized and easier to forget those extra sheets when debugging or updating. Plus, it adds extra HTTP requests, which are more expensive in terms of performance than having a single sheet that’s larger in file size. Because media-query-supporting browsers will download those extra sheets even they don’t currently need them, the smaller file size that you gain by separating the media queries into their own sheets is really only a benefit to browsers that don’t support media queries, as they won’t download those extra media query sheets.

But again—and this is the last time I’m saying this, but it applies to everything in this article—the best approach depends on your project.

How to use the cascade: overlapping vs. stacked

Regardless of whether you make your media queries embedded or external, you also need to decide whether you want them to overlap, bringing the cascade and specificity into play, or whether you want to “stack” them so only one media query applies at once.

Here’s what overlapping media queries look like (this example is embedded, but the same could be done with external sheets):

body {
    background: gray;
    font-family: sans-serif;
}
@media all and (min-width:500px) {
    body {
        background: blue;
        font-family: serif;
    }
}
@media all and (min-width:700px) {
    body {
        background: red;
        color: white;
    }
}

Do you see how these media queries are not mutually exclusive? Both apply to windows greater than 700 pixels wide. If my viewport was 800 pixels wide, for instance, it would meet both the minimum width of 500 pixels and the minimum width of 700 pixels and apply the styles from both media queries. I’d have a red background with white text in a serif font.

When you overlap your media queries, the cascade and specificity come into play when determining which rules to use. For instance, if I used the same exact media queries containing the same exact CSS, but changed their order so that the min-width:700px one was first, I’d get different results:

body {
    background: gray;
    font-family: sans-serif;
}
@media all and (min-width:700px) {
    body {
        background: red;
        color: white;
    }
}
@media all and (min-width:500px) {
    body {
        background: blue;
        font-family: serif;
    }
}

Now my 800-pixel-wide viewport would have a blue background instead of red—the rule that comes later with the same specificity wins.

Instead of overlapping your media queries, you can stack or isolate them so that each is mutually exclusive:

body {
    background: gray;
    font-family: sans-serif;
}
@media all and (min-width:500px) and (max-width:699px) {
    body {
        background: blue;
        font-family: serif;
    }
}
@media all and (min-width:700px) {
    body {
        background: red;
        color: white;
        font-family: serif;
    }
}

Now only one of these media queries can apply at a time: the first applies in viewports between 500 and 699 pixels, and the second applies at 700 pixels and up. This means you don’t have to worry about cascade or specificity any more, but you do have to repeat any styles that you want to apply in both situations, such as font-family:serif in this example. On the other hand, you don’t have to override styles from earlier media queries that you don’t want to apply in the later media queries. So neither setup always leads to more or fewer lines of CSS.

Whether you overlap or stack also has an impact on which assets get downloaded in WebKit browsers. If you have multiple media queries that apply to the same situation (such as the 500px and 700px media queries both applying to the 800px viewport example above), WebKit-based browsers will download all the images in all of them, regardless of whether a later media query overrides one of the images in an earlier one. (This also happens with the styles outside any media queries, by the way.) This doesn’t happen if the media queries are stacked; in this case, WebKit will only download the images called for in the single, currently applicable one. (But again, it will download any images outside the media queries too, even if later overridden.) This handy information is from Greg’s “CSS3 Media Queries? Download Answers” and Cloud Four’s “Media Query Image Download Test.”

The pros and cons

The bottom line

I think overlapping media queries is more often than not the most efficient way to go. Most sites don’t have radically different looks between media queries—sure, the layout might appear very different, but things like the typography, colors, and various visual effects are usually the same. Because of this, I’ve found that in most cases you’ll end up writing a lot more lines of CSS if you stack your media queries and don’t get to take advantage of the cascade. (Hooray for the cascade!)

However, if you do happen to have a site that has very different styles in each media query, stacking may be more efficient than overlapping. Also, because of WebKit’s downloading behavior, if you’re switching a lot of images between media queries, it may be wise to stack those queries instead of overlapping them, even if that means more lines of CSS and more chance of forgetting to update a rule inside multiple queries.

Which styles to make the “default”: mobile vs. desktop

While it’s possible to put all of your styles inside media queries, you’ll almost never see this, as browsers that don’t support media queries will get no styles whatsoever. What usually happens is that a chunk of styles sit outside media queries, either inside your single style sheet or in their own style sheet using a standard @import call or link, and these essentially become your “default” or starting styles. You then layer on one or more media queries to form alternate styles for different scenarios.

Media queries aren’t just for creating different layouts for different screen sizes, but let’s face it, that’s their primary use right now—and a dang good one. So that’s what I’m focusing on here: whether to make the small-screen styles the default or whether to make wider-screen styles the default. A few caveats, however:

• For ease of writing, I’m just going to refer to the smaller-screen styles as “mobile” and the wider-screen styles as “desktop,” even though mobile styles might be viewed on desktop devices and vice versa, and even though not all mobile devices support media queries.
• Also keep in mind that even though I’m simplifying it to two options for ease of discussion, you can have multiple media queries for each of these scenarios (such as 320px, 480px, and 600px “mobile” styles and 760px, 960px, and 1200px “desktop” styles), and any of these could be your default. You don’t have to make one extreme or the other the default.
• Finally, I’m specifically talking about which styles you make the default in the CSS itself, not about which version of the layout you first design for when coming up with wireframes, comps, and what-have-you. In a certain project, it may make the most sense to plan for the desktop design first, but when it comes time to build the media queries, make the mobile styles first. Nathan C. Ford talks about this in “Design for a Target Experience First.”

OK, are we all good? Good. Moving on.

Once again, WebKit’s downloading behavior is a big factor here. If you make the desktop styles the default and then override some of its assets in a mobile media query, either by setting new background images or setting elements that contain background or foreground images to display:none, Safari on iOS will still download the overridden or hidden desktop assets. The reverse is true: when mobile styles are the default, desktop Safari and Chrome will download all the mobile assets, even if overridden or hidden by the desktop styles.

This behavior isn’t “wrong,” by the way. It’s common for browsers to download assets that are set to display:none, as it allows the content to be preloaded and ready-to-go if later revealed by a script, such as a hover effect over text that reveals a thumbnail image. WebKit doesn’t discriminate between situations where the currently hidden image might be needed later, such as if the user can and does resizes her viewport, or if it will never, ever be called into play.

If the downloading of the unneeded image is problematic in your case, there are a few ways to work around it:

• Cloud Four’s test page shows that if you set an image as a background on a div, and then instead of hiding the div you hide the div’s parent element, WebKit won’t download the image.
• You could simply choose to make your default styles neither mobile or desktop—just restrict them to basic text formatting, colors, and the like. Introduce layout and images only inside media queries.
• There are a variety of ways to use scripting to control what gets downloaded when. Read “Combining media queries and JavaScript” by Peter-Paul Koch for the general idea behind this, as well as “Responsive IMGs Part 2 — In-depth Look at Techniques” by Jason Grigsby for a discussion of a whole bunch of scripting techniques to load images on an as-needed basis.

These solutions won’t work with all sites, but they are options in some cases.

The pros and cons

The bottom line

In most cases, I would advocate making the mobile styles the default, as it allows old mobile browsers to see the correct mobile styles. Yes, desktop IE 8 and earlier will also see those mobile styles, but this is an easy to fix with some JavaScript—a much more quick and straightforward process than getting your mobile styles to apply to non-media-query-supporting mobile browsers when you make desktop the default. Also, the fact that mobile devices won’t have to download any of the assets you call in the media-query-desktop styles is a big plus, as mobile devices are more likely (but definitely not guaranteed) to have slower connections and more limited bandwidth than desktop devices. I’ve made mobile styles the default in the last two sites I worked on, and I anticipate this being my go-to method going forward.

While mobile-first design, as it’s been dubbed by Luke Wroblewski, has become quite popular, and I too will sing its praises, I don’t agree with those who say it’s the only viable way to craft media queries. Desktop-default has a fair share of merit too, as you can see in its pros list above. It’s a great way to retrofit an existing site, since you can add on a chunk of mobile styles instead of having to rewrite all the CSS from scratch. It’s also a great way to get your feet wet with media queries. Designing mobile-first is a big shift in both your mindset and design process, so sticking to desktop-first might be best on your first foray into creating a site utilizing media queries. In Chapter 6 of my book Stunning CSS3, I take a desktop-default approach, as I think this is an easier way to first learn media queries. The default styles are targeted towards a size that most desktop users will see, with styles for both wider and narrower versions layered on. This means that even if I didn’t use JavaScript to fix IE 8 and earlier, or if the JavaScript doesn’t load, users will still see a layout that will work well for the majority of desktop viewport sizes—just the same as they would before we had media queries as an option. Media queries are used as progressive enhancement, not a requirement.

How to deal with IE 8 and earlier versions: conditional comments vs. JavaScript

Speaking of IE, you probably know that Internet Explorer 8 and earlier versions don’t support media queries. Since these browsers are likely a big chunk of your audience, I suspect you’ll want to figure out a way to get your media queries to work in IE 8 and earlier. You have a couple options: use conditional comments to feed separate media query sheets to different versions of IE or use a pre-fab script to make media queries magically work in IE.

To use conditional comments, you’ll vary your approach based on which set of styles, mobile or desktop, are your default. In either case, you’ll need to have your media queries separated into external sheets, not embedded in a single sheet along with your default styles.

If desktop styles are the default and you want to use conditional comments, you don’t need to really worry about desktop versions of IE 8 and earlier—they’ll get the desktop styles automatically. Sure, they won’t get any variations on those desktop styles that you might have included to better fit every particular viewport size, but if you’re using media queries as progressive enhancement, this isn’t likely to be a problem. Sure, it’s not ideal if an IE user with an 1100-pixel viewport sees the default 700-960-pixel styles instead of the 960-and-up media query, but it shouldn’t be a deal-breaker—the layout they see isn’t likely to look broken or be unusable. They shouldn’t know anything is “wrong.” So there’s nothing extra that has to be done for desktop IE 8 and earlier in this desktop-default scenario.

But the default desktop styles have a much bigger impact in the mobile version of IE used on Windows Phone 7. Luckily you can target it using a conditional comment and feed it your mobile-specific sheet:

<link rel="stylesheet" href="global.css" media="all">
<link rel="stylesheet" href="mobile.css" media="all and (max-width: 700px)">
<!--[if IEMobile 7]>
<link rel="stylesheet" href="mobile.css" media="all">
<![endif]-->

If mobile styles are your default, the situation is basically reversed: mobile-IE is fine without any extra work, but you have to feed desktop-IE the desktop styles using conditional comments. Again, we’re in luck when it comes to conditional comment syntax: it’s possible to craft a conditonal comment that targets IE 8 and earlier—which includes the version of IE on Windows Phone 7—but then also explicitly excludes mobile-IE:

<link rel="stylesheet" href="global.css" media="all">
<link rel="stylesheet" href="desktop.css" media="all and (min-width: 700px)">
<!--[if (lt IE 9)&(!IEMobile 7)]>
<link rel="stylesheet" href="desktop.css" media="all">
<![endif]-->

I learned about this handy conditional comment trick from Jeremy Keith’s article “Windows mobile media queries.” That Jeremy is one clever guy.

Both of these conditional comment variations don’t actually make media queries work in IE—they basically feed an alternate, static layout to IE, not based on viewport size or anything other than IE version number and platform, without any ability to switch dynamically between states. If you need more robust media queries support in IE 8 and earlier, or if you want to be able to embed your media queries in a single sheet, you can instead simply link to a ready-to-use script that detects your media queries and makes them work in non-supporting browsers. There are currently two such scripts:

• Respond by Scott Jehl: This script is much smaller than the other, and when you resize your window, it makes the changes appear right away without any lag. It’s main downside is that it only supports the min-width and max-width media features (the only ones I tend to use anyway!). Also, I found it triggered some totally obscure IE bug in a layout I was working on recently. But in general, I don’t have any problems with this script and highly recommend it.
• css3-mediaqueries.js by Wouter van der Graaf: This script is bigger and slower than Respond, but it does support more media features and may be less buggy in some scenarios. It’s not my first choice, but it’s a great option too.

Both of these scripts will work in non-IE browsers too, by the way. If you want to limit them to IE so others don’t have to take the HTTP hit, hide the script call in a conditional comment:

<!--[if (lt IE 9)&(!IEMobile 7)]>
<script src="respond.min.js"></script>
<![endif]-->

The pros and cons

The bottom line

Plugging in a little script takes no effort whatsoever, so if you’re using embedded media queries, why not use one of the JavaScripts? For the small percentage of people using IE 8 and earlier with JavaScript turned off, I’m not concerned about them simply seeing the default styles; if mobile is default, they’ll get simple but readable and clean, and if desktop is default, it will probably look just right anyway!

Summing it all up

By now you’ve seen that there are lots of important decisions that go into how you set up your media queries for maximum efficiency, robustness, and ease of use. These decisions include whether to:

• Make the media queries embedded or external
• Overlap or stack your media queries
• Make mobile or desktop styles the default
• Use conditional comments or JavaScript to add support for IE 8 and earlier versions

Hopefully I’ve given you the information you need to make those decisions easier.

There are lots of other decisions you’ll need to make along the way that I haven’t covered, such as:

• Which media features to use (Use max-width or max-device-width? Use orientation? That sort of thing.)
• Which dimensions to target, aka the breaking points in the design
• Which units to use for those breaking points (Pixels or ems?)

Don’t let all these decisions scare you off using media queries. Just know that, like any design technique, you can go about it with careful consideration or you can just quickly slap some sloppy media queries on your site. Think through the pros and cons of your media query configuration so that your media queries don’t just work, but work well.

Related Posts:

• Media queries presentation at indieconf
• Examples of flexible layouts with CSS3 media queries
• Bug fixes for removing the inner shadow on iOS inputs
• There’s already a book on responsive web design. Want to win it?
• IE 7 button text redraw bug

I’ve been doing a lot of investigation into WAI-ARIA for work recently, mainly revolving around educating other developers. I’ve found a lot of great demos of pages and widgets that use ARIA, but not too many videos of screen readers using said widgets. This is a shame, because it’s often hard to understand the impact of ARIA without hearing how a screen reader announces the content both without and with ARIA in place, and not many people have or know how to use screen readers. I can certainly show developers who are accessibility-newbies the ARIA demos, but their accessibility benefits aren’t that clear without a recording of a screen reader using them and their non-ARIA counterparts.

Nevertheless, I was able to find a few videos of screen readers using ARIA-enhanced widgets, as well as other uses of ARIA, and I wanted to share the links here. I’m willing to bet there are more out there—it’s just hard to find them, since simply searching for “aria” on YouTube will get you a bunch of videos of people singing opera, not screen readers! So if you know of others, please let us know in the comments.

Live regions

This video, though longer than it needs to be, is great because it shows a page without and then with ARIA live regions enabled, as well as the difference between “polite” and “rude” notifications.

Here’s a less clear but much shorter demo of live regions. Every time text is added to the log text box, the entire contents of the box are read out by the screen reader automatically:

And here’s the shortest of them all: a demo of how a screen reader would announce how many characters are remaining for your Tweet when typing one on Twitter—if Twitter were to actually implement live regions:

[Update 10/21/11] Another practical example of how to put live regions to use, this time on Yahoo!’s site for real. The video doesn’t mention ARIA live regions explicitly, but that’s how they’re getting the search results suggestions to be read out automatically.

Landmark roles

Lucica Ibanescu tested a page with and without ARIA landmark roles and recorded NVDA, JAWS, and Window-Eyes using both versions. Here’s the version with the ARIA landmarks:

Here’s how the landmarks on Flickr’s site are read:

Nomensa has a nice, simple demo of how landmarks are read on their own site:

Widgets

Aaron Gustafson has a video of his great TabInterface tabs widget being read by NVDA.

The Yahoo! User Interface (YUI) Library used to have video demos of all their ARIA-enhanced widgets online, but for some reason they’ve disappeared. However, I found someone else’s recording of YUI’s drop-down menu widget, seen here being read by NVDA:

You can also see how JAWS reads this menu. This same person posted a video of a different Yahoo drop-down menu widget that doesn’t use ARIA, so you can compare the two experiences with and without ARIA.

Similarly, here’s the ARIA version of YUI’s tabs:

Compare this to the experience with the older YUI tabs that don’t use ARIA.

Miscellaneous

Here’s a video of an extremely simple but very helpful use of ARIA: adding aria-describedby to “more” links so that the text that’s read out for each makes more sense out of context, such as when tabbing through the page or reading a list of links by themselves.

Here’s how the same page sounded before using aria-describedby:

You can see the code that produced this change in the article Easy Fixes to Common Accessibility Problems by Todd Kloots on the Yahoo! Accessibility blog.

Another quick and useful ARIA trick involves using aria-labelledby to label a form text field with the content of a select field rather than the label element, as seen here:

The code for this is fully described in the article “Create Dynamic Form Labels with ARIA” by Ted Drake on the Yahoo! Accessibility blog.

Here’s another video from Yahoo! showing how to use role="img" and aria-label to make a CSS background image be treated like a foreground image by a screen reader:

Any more?

If you know of any other videos of screen readers using ARIA-enhanced pages, please let me know in the comments. I’ll update this page with any videos you share plus new ones that come out over time that I happen to stumble across.

Related Posts:

• Videos of screen readers using ARIA
• Web accessibility presentation and resources
• A few links: CSS and accessibility
• Media queries presentation at indieconf
• CSS3 book launch event

“Screen readers, list items and list-style:none“

Roger found that some screen readers won’t announce list items if list-style:none is set on the list. (They will announce the list as a whole, just not the individual list items.) This very common bit of CSS visually represses the list markers, of course, but (probably?) shouldn’t change the spoken output. Unfortunately, this falls squarely into the “good to know, but what do you want me to do about it?” camp. Just keep it in mind, and hopefully the offending screen readers will fix this behavior soon.

“Using display:table has semantic effects in some screen readers“

Same sort of thing, only with display:table. NVDA in Firefox as well as the ORCA screen reader incorrectly announce elements that you’ve set to display:table as actual, semantic tables. This might be an area where you do have other options than using display:table (as opposed to list-style:none, where there are no alternatives if you don’t want markers), so this screen reader quirk is a little more helpful to know. I wouldn’t consider this a deal-breaker, but if you can easily avoid it, I say why not? If you can’t really avoid it, I wouldn’t sweat it, but again, keep it in mind.

“Styling button elements to look like links“

This is a useful CSS snippet for when you want something to look like a link (plain text) but act like a button (initiate an action other than taking someone to a new page). Roger points out, of course, that it would be better if the design were changed so that things that act like buttons look like buttons, but this is a good option when you can’t convince those darn designers to change things! (I’m allowed to jokingly complain about designers since I am one.)

Related Posts:

• Web accessibility presentation and resources
• Videos of screen readers using ARIA, updated
• Videos of screen readers using ARIA
• Media queries presentation at indieconf
• IE 7 button text redraw bug

I’m working on some styled buttons, created with the <button> element and some pretty basic CSS. In IE 7, if you scroll down the page so that the buttons move out of the viewport, then scroll back up to reveal them again, you’ll see lines of missing pixels drawn across the text of the buttons. It varies each time you scroll, so sometimes you won’t see any lines, and occasionally the entire text will disappear. The lines appear most often with the buttons with the largest text, but I think this is mainly just due to there being more pixels there to draw lines through, increasing the likelihood that IE 7 can screw it up. Hovering over the buttons or refreshing the page restores the text.

You can see a screenshot of the bug below, and view the bug live in IE 7 in my test page.

The buttons in IE 7 have lines drawn through their text, as if little strips of the text were erased.

I found a blog post that said that adding a one-pixel transparent border fixed the bug. I tried this and found that it does indeed fix the bug, but only if you remove either background-color or font-size. Both of those properties trigger the bug to begin with, and the border fix seems to only have enough power to fix one of the triggers, not both. I can’t remove either of those properties, so the border fix is a no-go. (Plus, the border does not actually show as transparent when I tested it, which makes it a deal-breaker anyway.)

Through experimenting, I found that removing overflow:visible also solves the bug. Unfortunately, that brings back the excess padding button bug that IE 7 and IE 6 suffer from. Setting overflow:visible seems to be the only fix for this bug, so this too is a property I can’t remove.

I of course tried the standard fixes of adding zoom:1 and position:relative, but neither of these, either together or separately, had any effect on the buttons.

I’ve tried so many things and I’m out of ideas. Can anyone help?

Related Posts:

• Bug fixes for removing the inner shadow on iOS inputs
• Media queries presentation at indieconf
• Essential considerations for crafting quality media queries
• A few links: CSS and accessibility
• There’s already a book on responsive web design. Want to win it?

Sounds like an easy fix, right? But if you didn’t read the comments on Trent’s article, you might have missed two important bugs* connected to using -webkit-appearance to remove the inner shadow:

1. If you use caret, it removes not just the inner shadow but also the borders on desktop versions of Safari and Chrome (as well as the beta version of the WebKit-based browser on the TouchPad tablet).
2. If you use none, it removes the inner shadow and leaves borders alone, but it disables focus styles on iPad.

In the case of the missing focus, I haven’t been able to confirm this myself; I don’t have an iPad, but the people I’ve asked to test it for me (thanks Josh!) have said the focus styles do show up, even when -webkit-appearance: none is set. Perhaps it’s a case of the version of iOS in use, perhaps the person who reported this bug in the comments to Trent’s article was simply having a problem with his individual machine, or perhaps there was something else in the CSS that was truly responsible for the problem. So it’s still not clear to me whether the second bug I listed above is really present. Do any of you iPad users have a problem seeing the red outline on focus in my test page?

If both of these bugs are truly present, they severely limit the circumstances in which -webkit-appearance can be used to remove inputs’ inner shadows. Luckily, we can use a background image instead of -webkit-appearance to remove the shadow. But what if you don’t want any background image to show? Simple—make the background image invisible. Some smart people on Stack Overflow suggested a couple ways to do just that:

1. Tile a transparent GIF as the background image.
2. Add a CSS3 gradient that runs from transparent white to transparent white.

I think the gradient option is ideal because it doesn’t require an extra hit to the server to retrieve the transparent GIF. And there’s no need to worry about lack of browser support, since the only browsers we want to apply the gradient are Safari on iOS.

Here’s what the CSS would look like for the gradient:

background-image:-webkit-gradient(linear, 0% 0%, 0% 100%, from(hsla(0,0%,100%,0)), to(hsla(0,0%,100%,0)));
background-image:-webkit-linear-gradient(hsla(0,0%,100%,0), hsla(0,0%,100%,0));

The first background-image declaration, using the -webkit-gradient function, is what will actually work in Safari on iOS today. The second declaration using -webkit-linear-gradient is there for future compatibility; WebKit has recently updated its gradient syntax to match the W3C specification. These syntax changes are in nightly builds and will make it into live versions of Safari and Chrome sometime soon, and you want your CSS to be prepared.

Most of this is not new information—it’s almost all in Trent’s article and comments and the Stack Overflow page. But I wanted to put it all together in one place, clearly explained, for easy reference. Hope it helps you out!

*I don’t actually know that these are true bugs. But they sure seem like bugs to me, and in any case, they certainly need some working around!

Related Posts:

• Media queries presentation at indieconf
• Essential considerations for crafting quality media queries
• A few links: CSS and accessibility
• There’s already a book on responsive web design. Want to win it?
• Free samples of Stunning CSS3

From a technical standpoint, creating liquid designs with media queries is not that complicated, in theory. But doing so requires a sometimes huge shift in mindset and design process, and this is where brief online articles on the topic fall a little short, simply due to the nature of their publication medium. What we really need is a whole book on responsive web design, covering all its intricacies. Ethan Marcotte is working on one, and I can’t wait to get my hands on it when it comes out later this year.

But it turns out that there’s already a book on responsive web design. OK, technically, it’s more like 1.2 books. My first book, Flexible Web Design: Creating Liquid and Elastic Layouts with CSS, is the only book out there that’s entirely devoted to designing and building robust and attractive web sites that adapt to the user’s viewing preferences. It includes not only detailed instructions on how to create the CSS for the layouts, but also how to make the images within them flexible and how to design them from the comp stage with flexibility baked in. All you need to add to any of the layouts you learn about in Flexible Web Design to make them “responsive” is media queries—and I cover those fully in chapter 6 of my new book Stunning CSS3: A Project-based Guide to the Latest in CSS. Put them together, and you have a detailed, comprehensive guide on how to create awesome responsive web designs.

I want everyone to start making responsive web designs, so I want to give away a bundle of both my books. Actually, I want to give away two bundles. So two people will get a copy each of Flexible Web Design and Stunning CSS3.

To win, I’m not going to ask you to follow me on Twitter (though I would really like it if you would) and retweet some canned message about this giveaway (though you’re certainly welcome to tweet about this). All you have to do to win my books is leave a comment on this post. Any comment will do, though I’d love to hear your thoughts on flexible design, media queries, CSS3, or anything relevant to the work we all do.

I’ll pick two commenters at random on Saturday, February 26, at 8am Eastern US time. Good luck!

In the meantime, you can learn more about my books and download free samples at their respective web sites: Flexible Web Design: Creating Liquid and Elastic Layouts with CSS and Stunning CSS3: A Project-based Guide to the Latest in CSS.

Update 2/28/11:

The winners, picked with a random number generator, are Chris Hawkins (comment 16) and Todd C (comment 33). Congrats guys! I’ll be in touch about sending your books.

Related Posts:

• Media queries presentation at indieconf
• Free samples of Stunning CSS3
• Examples of flexible layouts with CSS3 media queries
• Announcing my new book, Stunning CSS3
• Essential considerations for crafting quality media queries

1. If something electrical isn’t working, turning it off then on again is a good way to fix it.
2. Pregnancy affects every piece and function of your body, not just the parts you would expect.
3. People don’t wear silver clothes and use jetpacks in the future (which is now, of course), sadly.
4. Having someone sincerely compliment your child feels even better than a compliment to yourself, surprisingly.
5. It feels immensely satisfying to peel sunburned skin.
6. When I say my name on the phone (ZO-ee), people often think I’m saying Ellie.
7. When you get an unexpected sum of money, you will usually get an unexpected car or home repair right afterwards, which seems like a bummer, until you realize you’ve been blessed to have that money to take care of it in the first place.
8. It doesn’t feel good to over-eat.
9. People often don’t do what’s in their best interest (see above).
10. I hate yoga and yoga hates me.
11. Cheese is not overrated.
12. Chocolate chip cookies are extremely common, yet it’s sadly very difficult to find excellent ones.
13. When excellent chocolate chip cookies cannot be had, mediocre chocolate chip cookies are still hard to resist.
14. People follow the rules, even when it would be more fun or beneficial not to, an impressive amount of the time.
15. Time flies when you’re having fun.
16. It’s OK to kill thousands of people in a movie, but don’t you dare kill the dog. (Unless the whole point of the movie is killing the dog, aka Old Yeller.)
17. The zombie apocalypse is inevitable.
18. When you call a customer service phone number, the automated phone recording will make you input your member number. But when you finally get to a real person, they’ll ask you for it again.
19. Do a job that you love.
20. A less-nice house is worth the shorter commute.
21. You can do it yourself, but paying someone else to do it is more enjoyable.
22. The tiniest amount of mustard can be detected, and it ruins an entire dish.
23. Harry Conick Jr is a serial killer. Just wait. It’ll come out. You’ll see.
24. When you have extra money, spend it on trips and activities, not stuff. When you’re an old lady, you won’t reminisce about the beautiful couch you once had, but you will think about how much fun you had at Yellowstone. (I learned this one from my paternal grandma, through my mom.)
25. You could be angry, but wouldn’t it be more pleasant to be happy?
26. Everything at Kohl’s is always on sale, regardless of whether it’s marked on sale or not.
27. I’ll eat anything once. Almost anything.
28. When coming up with a time estimate for a project, figure out what it would take, then double it. Or triple it.
29. Some people are reliably unreliable.
30. It sounds so trite, but it really is all about love.

Related Posts:

• I’m on Twitter now. Yes, finally.
• A new addition

I’ve been doing a lot of investigation into WAI-ARIA for work recently, mainly revolving around educating other developers. I’ve found a lot of great demos of pages and widgets that use ARIA, but not too many videos of screen readers using said widgets. This is a shame, because it’s often hard to understand the impact of ARIA without hearing how a screen reader announces the content both without and with ARIA in place, and not many people have or know how to use screen readers. I can certainly show developers who are accessibility-newbies the ARIA demos, but their accessibility benefits aren’t that clear without a recording of a screen reader using them and their non-ARIA counterparts.

Nevertheless, I was able to find a few videos of screen readers using ARIA, and I wanted to share the links here. I’m willing to bet there are more out there—it’s just hard to find them, since simply searching for “aria” on YouTube will get you a bunch of videos of people singing opera, not screen readers! So if you know of others, please let us know in the comments.

This first video is the best, as it shows a page without and then with ARIA live regions enabled, as well as the difference between polite and rude notifications.

ARIA Live Regions Screen Reader Demo

YUI has ARIA versions of several of their widgets, and each has a video of a screen reader using it:

• YUI 3 Beta 1 ARIA Menu Button
• YUI 3 Beta 1 ARIA Tabview
• YUI 3 Beta 1 ARIA Toolbar
• ARIA-enabled Alert dialog
• Example Page Using YUI Grids And ARIA Landmark Roles
• Menu Button Using The “activedescendant” Property
• Screen reader accessible Menu Button
• Menu Button Using Roaming TabIndex Technique
• YUI MenuNav Node Plugin using ARIA
• Using the Carousel ARIA Plugin
• Using the Menu ARIA Plugin
• Using the Container ARIA Plugin
• Using the Button ARIA Plugin

Unfortunately none of the YUI videos demonstrate what the user would hear were it not for the addition of ARIA, but they’re interesting nonetheless.

Update 2/17/11:

A couple comments pointed me to some additional videos of screen readers using ARIA.

Lucica Ibanescu tested a page with and without ARIA landmark roles and recorded NVDA, JAWS, and Window-Eyes using both versions. Here’s the version with the ARIA landmarks:

Aaron Gustafson also has a video of his great TabInterface widget being read by NVDA.

Related Posts:

• Videos of screen readers using ARIA, updated
• Web accessibility presentation and resources
• A few links: CSS and accessibility
• Media queries presentation at indieconf
• CSS3 book launch event