Accessible RWD

This article first appeared in issue 239 of .net magazine – the world's best-selling magazine for web designers and developers.

Responsive web design (RWD) is becoming increasingly popular, which can have an impact on accessibility. If you aren’t familiar with RWD and terms like viewport, check out this .net article first.

People who need to increase the size of things on web pages can benefit from RWD as the site can resize to fit the browser viewport. I say ‘can’, because WebKit currently has a bug where media queries are not triggered by zoom. That means lovely RWD sites like BostonGlobe.com get horizontal scroll bars and overlapping text when zooming on Safari and Chrome. I assume (and hope) this gets fixed soon.

For those people using Firefox, Internet Explorer or Opera, responsive sites work well: zooming in increases everything smoothly and without horizontal scrollbars. In fact, in testing I’ve found people with visual impairments are surprised by how well RWD sites work. The inconsistency of layout can take some getting used to, but people who are always zoomed in probably won’t notice.

Using RWD also makes text sizing widgets anachronistic, as it either duplicates browser functionality exactly, or increases the text size without triggering layout changes.

The default mechanism in all desktop browsers for increasing the size of things is zoom, which essentially increases the size of a pixel. From doing usability testing with people who have visual impairments, they tend to be like everyone else: use the most easy and effective mechanism to get things done. Going into the settings and changing font sizes, or creating your own style sheets simply isn’t used compared to using visible controls or keyboard commands to zoom.

This behaviour could be considered a boon for web developers as you only need to allow for one unit. When ‘text sizing’ was the method people used to adjust sizes on the web, you had to consider both text size and viewport size. That often meant that the layout would squeeze horizontally and text would expand vertically, which media queries do not help with.

If you set both text size and the media queries for the layout in one unit (either pixels or ems) it should behave more predictably. When someone zooms in, everything changes size proportionality, the number of pixels in the viewport decreases, and both text and layout adjust according to your media queries.

Whether you use pixels or ems is a personal choice. I think that pixels is the better bet as browsers have to convert ems to pixels anyway, and different devices set the CSS pixel-density based on the assumed viewing distance.

The story is less settled on mobile devices, as few mobile browsers provide controls over sizing apart from the now standard pinch-zoom. We don’t know if they will go with pixel-based, text-size controls, or nothing. My money is on pixels.

Discover 10 artful and unusual approaches to website navigation at Creative Bloq.