456 Berea Street

Break

Roger Johansson — 2009-06-19T08:55:24+01:00

It’s summer here in Sweden, and that means it’s time for my annual break from work and anything even remotely related to it, including this blog.

I’ll be back in August.

Posted in Life.

Page zoom does not mean the end of flexibility

Roger Johansson — 2009-06-18T19:17:42+01:00

The latest versions of most browsers support – and default to – full page zooming instead of just increasing text size. Some argue that this means you no longer need to think about what happens when users increase (or, to a lesser degree, decrease) text size, and that there is no longer a need for fluid or elastic layouts or using other units than pixels for font sizing.

The thought may be tempting, but I don't quite agree, for much the same reasons as Zoe Mickley Gillenwater gives in Why browser zoom shouldn’t kill flexible layouts, where she argues that full page zoom does not solve all the problems that liquid and elastic layouts solve.

Another reason for making sure your design is flexible is that on most websites you have to take varying amounts of content into account, so your design needs to be robust enough to handle that. And if you work with multilingual websites, the same content will take up a different amount of space depending on the language. Some languages have mostly short words, others have really, really long words. Full page zoom does not change that.

Posted in Accessibility, CSS, Usability.

Accessibility improvements in Mac OS X Snow Leopard

Roger Johansson — 2009-06-17T19:24:40+01:00

Apple recently announced that Mac OS X 10.6, a.k.a. Snow Leopard, will ship in September this year. I’m looking forward to it for several reasons, one of them being the accessibility improvements it will bring.

According to Apple’s Mac OS X Accessibility page, Snow Leopard has plenty of accessibility news, several of which will not only help people with disabilities:

VoiceOver trackpad gestures let you control VoiceOver from the trackpad
Improved Braille support means built-in support for even more Braille displays
Finally, full VoiceOver support for HTML tables
The rotor lets you use the trackpad to move through text as if you were turning a dial
Quick Nav makes it easier to control the computer using just one hand
Auto web spots interpret the visual design of web sites to figure out important locations on the page
Custom labels let you manually assign labels to unlabelled or badly labelled form controls
More detailed customisation lets you configure VoiceOver to better suit you

Lots of good news, though I would have liked to see ”Full WAI-ARIA support” on the list as well.

Posted in Accessibility, Apple, Mac.

Do you think a WCAG 2.0 technique can be improved? Let the W3C know.

Roger Johansson — 2009-06-16T20:25:32+01:00

While going through Web Content Accessibility Guidelines (WCAG) 2.0, I have noted that some of the Techniques for WCAG 2.0 could be improved, at least in my opinion.

In some cases it’s a simple typo, in other cases the technique doesn’t describe what I would consider current best practice. The good thing is that the technique documents aren’t set in stone like the main WCAG 2.0 document is.

If you have suggestions for improvement to a WCAG 2.0 technique (or any other WCAG 2.0 document), the WAI web site has a page with Instructions for Commenting on WCAG 2.0 Documents.

I haven’t done so yet, but I hope to be able to find time to go through the techniques and send in my feedback.

Posted in Accessibility.

Using the Web with a refreshable Braille display

Roger Johansson — 2009-06-11T20:50:49+01:00

Chances are that you have either seen someone use a screen reader to access the Web. You may even have tried one yourself. Braille displays, however, are not as commonly seen, and since you need more than just software to use one it just isn’t feasible for most sighted Web professionals to actually try one. Not to mention the need to learn Braille to be able to read anything.

So watching a video of someone using a refreshable Braille display to read with their fingertips may be as close as you get. Roger Hudson has posted one such video in Refreshable Braille and the Web, and I suggest you watch it. The more we all know about assistive technology and how people use it, the better.

Posted in Accessibility.

Enabling keyboard navigation in Mac OS X Web browsers

Roger Johansson — 2009-06-09T15:50:51+01:00

I like using the keyboard to navigate websites. It is often more efficient and comfortable than having to reach for the mouse and position the cursor just right. Another reason I have for using the keyboard is that it lets me check that aspect of accessibility on the sites we build at work.

One problem is that, for some strange reason, Mac OS X web browsers do not have full keyboard navigation enabled by default. They do support keyboard navigation, but you need to enable it. In some cases it’s very easy, in others it requires a bit more work.

Since I am asked about this every now and then I have written this summary of how to enable full keyboard navigation in some web browsers for Mac OS X.

Safari

Choose Safari > Preferences.
Click Advanced.
By default, the Tab key just focuses form controls – you need to use Option-Tab to focus links as well. To change this, check the checkbox labelled Press Tab to highlight each item on a webpage.

Firefox

Choose Apple menu > System Preferences.
Click Keyboard & Mouse
Click Keyboard Shortcuts.
Below “Full keyboard access”, check the radio button labelled All controls.
Close System Preferences and open Firefox.
Type about:config in the Firefox location bar, press enter and click the “I’ll be careful, I promise!” button.
Look for a setting called accessibility.tabfocus. Most likely it isn’t there, but if it is, double-click it and change its value to 7. Skip the next steps.
If there is no accessibility.tabfocus setting, right-click anywhere in the list and choose New > String.
In the “New string value” dialog that opens, enter accessibility.tabfocus and click OK.
Enter 7 in the “Enter string value” dialog and click OK.

You may need to refresh any pages that were open in other tabs before you opened about:config for the changes to take effect.

It is worth noting that sometimes you don’t have to go through steps 6-10 to enable keyboard navigation in Firefox. It seems a bit strange, but if I create a new user profile in Firefox 3, keyboard navigation works without further configuration. If I create a new Mac OS X user, however, keyboard navigation does not work until I add accessibility.tabfocus in about.config. Why? No idea.

Opera

Choose Opera > Preferences.
Click Advanced.
Select Shortcuts in the list of settings.
Check the “Enable single-key shortcuts” checkbox.

In Opera you don’t keyboard navigate quite the same way as in other browsers. The Tab key only works with form controls. To navigate links you use the Q and A keys to step backwards and forwards through the links on the page. You can also use headings to navigate by pressing the W and S keys to step to the previous or next heading. In addition to this, Opera has something called Spatial navigation which lets you use the Shift key and the arrow keys to move around the page.

Camino

Choose Camino > Preferences.
Click Web Features.
From the “Tab selects” menu, choose All form controls and links.

OmniWeb

Choose OmniWeb > Preferences.
Click General.
Next to “Keyboard Navigation”, check the radio button labelled Tab key selects links and form controls.

Start loving your keyboard

Now that you know how to enable full keyboard navigation in most Mac OS X web browsers, try it out if you haven’t already – you may find yourself liking it. Even if you don’t, you’ll be able to check that you do not create accessibility problems for people who cannot use a mouse and rely on their keyboard to navigate the Web.

Posted in Accessibility, Browsers, Mac.

Help screen reader users by giving data tables a summary

Roger Johansson — 2009-06-05T13:57:56+01:00

When sighted users encounter a data table, they can scan it to get an understanding of the data it contains. They can quickly skip from the first row to the last and from one column to another and so on.

For people using a screen reader or other non-visual browser, this is a much more time-consuming task since they read the table cell by cell, row by row, and have to more or less keep all of it in memory.

To help users of non-visual browsers understand and navigate data tables, you can use the summary attribute to describe their structure. The summary attribute is not displayed in graphical browsers, so the information you put there should be written for non-visual users.

Describing a table with a summary attribute is particularly useful for more complex tables. For simple tables it may not be necessary as enough info may be provided in the caption element.

Find and highlight HTML elements with FireFinder for FireBug

Roger Johansson — 2009-06-01T22:11:39+01:00

A Firefox extension (for Firebug) that I’ve been trying out a bit lately is FireFinder. It lets you quickly find HTML elements that match a CSS selector or XPath expression.

It may not sound like much, but it can be really helpful. Want to find all img elements on a page? Open FireFinder, type img and hit enter, and FireFinder highlights all images for you. Want to find any linked images? Enter a img instead. Want to highlight images that do not have an alt attribute? Try img:not([alt]). And so on. Excellent!

FireFinder is yet another very useful tool created by Robert Nyman. For more info check out Robert’s blog post Firefinder for Firebug - an extension to quickly find elements matching your CSS selectors or XPath expressions.

Posted in CSS, Productivity.

Cufón and screen readers

Roger Johansson — 2009-05-28T19:40:28+01:00

Cufón has been talked about a lot recently, and it looks like a potential alternative to static images or sIFR in situations when you absolutely must use a typeface that is not “web-safe”.

I say potential alternative because in its current state there are a couple of issues that prevent me from using it: text rendered with Cufón can’t (easily) be copied and it causes problems in some screen readers.

Looking at Cufón’s Known bugs and issues it seems as if the text selection problem is being worked on, so I’ll leave it at that.

The screen reader problem is more troubling though. It seems to be caused by each word in text rendered by Cufón being a separate span element. This makes several screen readers (at least VoiceOver, FireVox, ORCA, Window-Eyes, and Opera Voice) Read. The. Text. As. If. Each. Word. Was. Separated. By. A. Full. Stop.

Even worse, in some cases the screen reader will stop after reading the first word of a Cufón-replaced sentence. A screen reader user navigating by headings on a site that uses Cufón for headings may not realise this and miss all but the first word of each heading.

Browsing the Cufón API I found a way to avoid this problem – setting the separate option to 'none'. This way Cufón does not wrap each word in a separate span element. The catch is that, as far as I can tell, doing so makes it impossible for the text to wrap to multiple lines, so you can only use it if you know for sure that the text will fit on a single line.

A valid question you may be asking yourself is if screen readers really should be pausing after each span element. I'm not sure. I think it's reasonable that screen readers somehow convey span elements and other inline elements to the user. I'm not sure what the "correct" behaviour should be, and there may be better ways than pausing.

In the case of Cufón the span elements are meaningless and could (should) be ignored, but other times inline elements are there for a reason. It's probably hard for a screen reader to guess which it is, though I suppose span elements could be safely ignored most of the time since they have no inherent semantic meaning.

Anyone know of a solution to this problem, or know more about why some screen readers pause after inline elements? Please let me know.

Posted in Accessibility, Typography.

W3C online course: An Introduction to W3C's Mobile Web Best Practices

Roger Johansson — 2009-05-25T18:46:11+01:00

If you’re building websites or web applications that are completely or partially targeted to people using mobile phones to access the Internet, you may be aware of the W3C Recommendation Mobile Web Best Practices.

In case you aren’t familiar with the document, or if you have read it but would like a more hands-on explanation of the best practices it contains, you might want to spend € 99 and a couple of hours per week for 9 weeks on Introduction to W3C's Mobile Web Best Practices. It’s an online course starting June 1 that will help Web designers and content producers already familiar with the desktop world to become familiar with the Web as delivered on mobile devices.

More details are available in the Course Description. Looks like a good intro if you aren’t already aware of how designing and developing for the Mobile Web differs from creating stuff for desktop computers.

Posted in Mobile Web, Web Standards.