Well, browser manufacturers have caught on to this. Following in Opera’s footsteps, IE and Firefox are now implementing zoom as the default method of resizing text.

If this is the case, then do we still need to code layouts in ems or can we go back to using pixels? I’m currently coding a new layout for this site and I’ve decided to code it in pixels. It’s so much easier not to have to do grid calculation in ems and worry about what the current font size is. My grid unit is 24px. That’s it. Much better.

So, do you think it’s still worth it to code layouts in em’s? The non-zoom font resizing functions are still there. Will people prefer to use them over zooming?

Creating a semantic FAQ page with definition lists and advanced CSS, Part 1

and

Creating a semantic FAQ page with definition lists and advanced CSS, Part 2

The first part goes over the structuring and presentation of a long Frequently Asked Questions page. The second part demonstrates two ways of creating navigation for the page. I hope you find them useful, and do let me know if you have any comments or questions.

Liam has also been releasing a lot of articles about standards, including What’s the Difference Between Usability and Accessibility? and Future Proofing Using Standards.

Please, stop making your font sizes so miniscule that nobody can read them properly! I could increase my font size in my browser (zoom in in Opera) but you shouldn’t have to make me do that. It’s annoying and I’m lazy. For many sites I’ve even had to build user stylesheets just so I don’t have to keep increasing the font size every time I visit. My opinion is that font sizes should always be set just a little bit smaller than the browser default size (between 80-90% of normal, depending on the typeface. Both of the examples linked above use Trebuchet, which needs to be bigger). This works well for a normal range of screen resolutions. If people like them larger or smaller they can change their browser preferences.

Even the W3C agrees with me.

So quit it

(Just as I was posting this I came across a post on YouMoz demonstrating that when tested, page views actually increased when the font size was set a little larger. This site was targetting seniors but I think the same could be true for other age groups as well.)

Here’s a screenshot for those of you who don’t have Cambria and Calibri installed (I can’t get the names of those two straight!). Check out his typography stylesheet too. I don’t think I’ve ever seen such an interesting set of font specifications in a stylesheet before. So many elements are very specifically defined, with many more options than what designers normally include. He’s also got a very different set of fonts listed for various elements. His main body font list is Cambria, “Hoefler Text”, Baskerville, “Palatino Linotype”, Garamond, “Lucida Fax”, Georgia, “Book Antiqua”, serif.  Hmmmm…. interesting.

Unfortunately, it doesn’t look quite as good on my Linux computer where the first available font is Georgia. It still looks nice though – classic typographic principles at work.

His header also works perfectly with the rest of the design even though it is using different typefaces. Brilliant! (although I do think the home page has a few problems…)

Anyway, I don’t necessarily think that typography is the most important thing, but it can really make (or break) a design, as we see here. Do you know of any other examples of outstanding web typography?

Also note that this code was posted in 2006 and may not be compatible with current versions of WordPress.

I thought I’d document this just for my own info and in case anyone else is looking to do the same thing.

Default title format

The default wordpress titles look like this:

Home page: Blog Name (and that’s it)
Category Pages: Blog Name » Category
Archive Pages & individual posts: Blog Name » Blog Archive » Post Title

I wanted to reverse this for a few reasons. Firstly because it’s good for people that have a lot of tabs open and can only read the first part of the title. Secondly, it might be better for SEO and actual reading of SERP’s. Thirdly, because I just like it better that way.

My preferred format

This is how I like my title tags:

Home page: Blog Name – description
Category Pages: Category Name – Blog Name
Archive Pages: Post Title – Blog Name

The default code

The default code is in the header.php theme include and looks like this:

<title>< ?php bloginfo('name'); ?> < ?php if ( is_single() ) { ?> »
Blog Archive < ?php } ?> < ?php wp_title(); ?></title>


Step 1: Add conditional for home page

There are a couple of things I had to do. First, put in a conditional so that it generates different title tag for the home page. Then get rid of those » characters.

I started with a modification I found in this article on Perfecting Your WordPress Title Tags. This puts in a description for the home page and takes out the “Blog Archive” bit:

<title>
< ?php if (is_home()) { ?>
< ?php bloginfo('name'); ?> » < ?php bloginfo('description'); ?>
< ?php } else { ?>
< ?php wp_title(); ?> » < ?php bloginfo('name'); ?>
< ?php } ?>
</title>


If it’s the home page, put in the blog name and description. Otherwise, just use the title and blog name. The first problem I had with this is that when I copied the code it put in curly quotes around the php attributes which caused an error message. Make sure those are straight.

Step 2: Remove » separators

That still has the » characters so I replaced those with hyphens (when choosing a title separator, think about how a screen reader would read it. » reads “right double angle bracket”. No good. I used to like | but that is read as “vertical bar”. Also no good. A plain old dash or colon work best).

<title>
< ?php if (is_home()) { ?>
< ?php bloginfo('name'); ?> - < ?php bloginfo('description'); ?>
< ?php } else { ?>
< ?php wp_title(); ?> - < ?php bloginfo('name'); ?>
< ?php } ?>
</title>


Step 3: Arrange separators properly

The problem I had after this is that the »’s are built into the title. So I ended up with titles that looked like this: » Fixing my wordpress title tags – MeganJack.com. To remove those I had to consult this post on wordpress accessibility hacks. Scroll down about half way to find the part about Removing superluous fluff from being read aloud. There is a solution to removing the other » from the title tag: simply put a $sep=’blah’ value into wp_title().

The problem with this is that in that example the author did not rearrange the order of the title bits. The defined separator automatically goes in before the title text. So I just took it out altogether and entered in my dash between the title and the blog name.

The Optimal Title plugin solves this problem by changing the position of the separator to after rather than before the title. I thought about using it but decided it’s not worth cluttering things up with another plugin since my solution works fine.

Final Solution

Now my code looks like this:

<title>
< ?php if ( is_home() ) { ?>< ?php bloginfo('name'); ?> - < ?php bloginfo('description'); ?>
< ?php } else { ?>< ?php wp_title($sep = ''); ?> - < ?php bloginfo('name'); ?>
< ?php } ?>
</title>


If it’s the home page, put in the blog name then the blog description (my tagline). For all other pages, put in the title then the blog name, seaprated by a dash. That works for the category pages too. Perrrrrrfect

Update 16/12/2007: Added headings to clarify sections, inserted note about the optimal title plugin.

P.S. I am now in the process of removing the rel=nofollow from comment links. I think it’s kind of rude for people to do that to their commenters. Same with discussion forums. You’re doing me a favour by participating on my blog, the least I could do is give you a followable link (pathetic link value as it is!). Askimet catches most of the spam here so I’m not worried about that. We’ll see though

Update 16/12/2007: My current dofollow plugin only removes the nofollow for commenters who have already posted at least 3 times. If I’ve let a few of your comments stay up then you’re probably cool

I was quite excited about this conference when I first heard about it because Joe Clark was to be the keynote speaker. Unfortunately Joe wasn’t able to make it but luckily Derek Featherstone was there to
fill in

Quick overview and key insights

One of Derek’s main messages was to think about accessibility in terms of people – not technologies or legislation. So instead of thinking about how a screen reader would handle your page, you could think about how a blind human being would browser your sites. Every disabled person is different and has unique needs. Many of us tend to think of accessibility only in terms of blind users, but what about people who just have low vision and need larger fonts? What about people who can’t use a mouse?

I also learned about some of the other assistive technologies that people use. As in the previous example, most of us tend to think that the only type of assistive technology we need to accommodate is screen readers. There are also screen magnifiers for people with low vision, a variety of alternate input devices, and voice recognition software which allows people with limited or no use of their hands and arms to use a computer. Voice Recognition software allows a user to read out the title of a link they want to click on, for example, and the software directs the web browser to follow that link. Problems can arise here if the alt attribute on a graphic link doesn’t match the text it displays.

Come to think of it, I imagine they couldn’t handle links on non-text graphics at all. Take, for example, the common use of a logo as a link back to the home page. Normally this has become so ubiquitous that people don’t include a separate link back to the home page. But, how does anyone know what that alt text says so they can speak it into their voice recognition software? They don’t, so alternate links are needed in every case.

Session: Podcasting

This session was given by two profs who have experimented with podcasting in the classroom. They recorded their lectures and put them up online. You can record directly to iPod with the iTalk plug-in and a clip-on mic. One of the things they pointed out here is that audio recordings are really helpful for people with learning disabilities. So if someone has problems concentrating in the classroom they can listen to the audio again later. I’ve also read that people with learning disabilities often find an audio alternative for text content to be helpful.

Now, obviously, anyone who is deaf or severely hearing impaired would need to have a text alternative if it was necessary.

Session: Web Accessibility Testing Techniques & Strategies

This was given by Derek Featherstone again. He emphasized that you need to know what you are testing and who you are testing with. There are three types of testing: expert opinion, technical test with assistive technologies, and an actual user test. Ideally you’d be able to do continuous and iterative testing with actual users but this is rarely done.

Instead, he suggested a team testing approach with a facilitator, user, and a developer. The facilitator would guide the test, the user attempts to perform the requested actions, and the developer checks the code while the test is going on to find out what is causing the problems.

There are a lot of tools available for testing accessibility. I was thrilled to see Derek demonstrate some of the accessibility features available in Opera. One of the things he showed was the superior keyboard functionality in Opera. People who can’t use a mouse (either because they can’t see the pointer or because they can’t physically move it very well) can use keyboard shortcuts to navigate through key elements on a page. In Opera you can use the a key to navigate between links only. Or you can press “h” to navigate between headers. Yet another reason to structure your page properly!

There is also an accessibility toolbar available for Opera. I haven’t had a chance to check this out yet. It will not be possible to run this in addition to the web developer toolbar for Opera since both are using the view menu. I think it might be possible to run parts of both of them by using custom buttons. I’ll post again about this if I get a chance to try it.

A Screen Reader in Action

This was during a session on the CMS we’re using here at the University, presented by Andrea Chapell – one of the system admins, and Kate Hano – an actual blind user. She was a grad student who had a lot of problems using the instructor tools in the CMS.

Anyway, the best part of the presentation was when she actually showed us what the screen reader sounds like. I had heard one before, briefly, but this time it was even more enlightening In this case she was using JAWS. A few key points:

• It reads everything, including punctuation. The CMS was using | often to separate links, which JAWS would read as “vertical bar”. So, stop using those.
• It starts a page by stating the number of links and headings – another reason to structure your page properly.
• It will preface a links and by reading “link – some other website”. The same happens with headings (“heading level 2 – This is the title of a section”)
• If you have a bare URL, it will attempt to read out the letters so you will hear h t t p colon slash slash w w w dot … etc! At least it doesn’t try to read it as a word! But that’s a good reason not to post bare URL’s. They don’t have much meaning for less knowledgeable sighted users either.
• Screen readers generally go very fast – much faster than you would normally speak. I have heard others go faster than JAWS did in this demonstration. There are settings for users to adjust how fast the speech is.

I highly recommend trying a screen reader if you get a chance. It provides a lot more information about how blind users hear the web than what you could read on a website or in a book.

Adopting New Technologies with Accessibility in Mind

This was a general overview presentation by Jesse Rodgers and Antonia Palmer, both of UW. They talked mainly about multimedia technologies and how to make them accessible. This is pretty basic accessibility – if people can’t see it, provide a text alternative, if people can’t hear it, provide a transcript. The added benefits of text alternatives is that it makes the content searchable. And when it’s searchable it’s more useful to sighted/hearing people and to search engines.

One thing that was mentioned on the topic of mobile and handheld devices is the problems they case for people with motor difficulties and low/no vision. That reminds me of my dad who has one of those little tiny cell phones. His problem is that his fingers are really big and he has trouble pushing one button at a time (goddammit!)

Summary

I am now inspired to look over my sites and try to make improvements for accessibility. Today I’ve been frantically going through the site I maintain at work to get rid of all the vertical bars. I’ve also read up on improving alt attributes and found lots of other great accessibility information. More reading to do!