Essential considerations for crafting quality media queries

CSS3 media queries are dead simple, in terms of their syntax. You’ve got an @media directive, a media type (which you already know from good ol’ CSS 2, like screen, print, all, etc.) and one or more media features (the characteristics we’re testing against). That’s it:

@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:

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.


Videos of screen readers using ARIA, updated

My previous post “Videos of screen readers using ARIA” needed a good updating: I’d found several more applicable videos and some of the original videos had disappeared from the web, leaving the links to them broken. This article includes all the content from that original post that’s still online plus all the new stuff I’ve found, organized by topic this time.

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.

A few links: CSS and accessibility

The blog 456 Berea Street by Roger Johansson is one of my favorite sites for useful information on web standards topics presented in a really clearly written and succinct way. He’s had some great articles recently related to the intersection of CSS and accessibility that I thought were worth sharing.

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.)