Using some CSS voodoo, you can display a text link’s URL in parenthesis after the link text. This would be very useful for printer style sheets, where you can’t see where the links are pointing when the page is printed out.

Here’s an example of what you’d see on the screen:

I wrote an blog post about printer style sheets a while ago.

And here’s what you’d see on the printed page:

I wrote an blog post about printer stylesheets (http://www.clearcrystalmedia.com/gc/green-printer-style-sheet/) a while ago.

Here’s the CSS code, which I would definitely use some specificity on. (I added a reference to #content as an example of using a selector for specificity. We wouldn’t want to have images in our navigation with parenthesis!)

#content a:after {
    content: " (" attr(href) ")";
}

This trick appears to work in all browsers except for Internet Explorer versions 6 and 7.

Technorati Tags: Accessibility, ccm, chris peters, clear crystal media, css, html, polymorphism, tip, tips, web design

The pains of using a screen reader

Worst case, you’re using a screen reader to browse the Web. You have low vision or blindness, so you have your computer read all of the text on web pages aloud. If you’ve never tried using a screen reader, I’d suggest downloading JAWS and trying to surf the web. It’s painful and inefficient. If you already hate computers, you’ll hate them even more.

To overcome the need to listen to every word on the page, users usually have the screen reader read only the links on the page to figure out what their options are for navigation.

Now imagine running through the scenario of using a screen reader when the page’s content looks like this:

To learn more about Wookiees, click here.

We absolutely love Wookiee hair, so we’ve listed our favorite Wookiee brushes here.

Click here to order some Wookiee ice cream.

The screen reader would read it like so. Imagine the frustration:

Link: click here. Link: here. Link: click here.

If you decide to ignore support for screen readers in spite of that scenario, beware. Even users that can see often look for that blue underlined text instead of reading everything in context. Regardless of sight ability, users that sense that they want to go somewhere else immediately start looking for links. In this case, no one cares about what you’ve written.

Please save everyone time by restructuring the example content so that the link text describes where the link points to:

Learn more about Wookiees.

We absolutely love Wookiee hair, so we’ve listed our favorite Wookiee brushes.

Order some Wookiee ice cream.

What’s great is that SEO encourages content writers to follow this practice. The text you have in a link describes to search engines what the next page is about, so Google uses this link text to determine what keywords the page should rank for. Don’t underestimate the blue underlined text’s ability to let the user know that they want to click it.

Headers are important, too

When a user with low vision is on a page containing the information they need, it’s still painful to listen to the screen reader read everything on the page. So the user will often toggle through the page’s headers, much like they do with links. This helps them find the part of the page they want access to faster.

It just so happens that Google places more value on the text contained within page headers. So that means that search marketers are ahead of the game here as well, knowing that header text should be keyword rich.

Headers should do a good job of summarizing their sections, so be sure to use words that visitors understand. (Also known as key words! Sound familiar?)

Don’t use obtrusive technologies

Search marketers know the importance of not using JavaScript, images, Flash, and other “non-readable” content to convey your message. If you regularly embed text into images on your site, you have both SEO and accessibility problems.

Computers can’t read graphics, so screen readers and search engines can’t read graphics either. If you absolutely must put content within images, JavaScript, or Flash, learn how to provide a text alternative for each situation. It will improve your SEO and also the experience for screen reader users.

I covered how to write effective alternative texts a couple years ago. Recommended reading!

Overall user experience revisited

Let’s not forget that your sites’ visitors with disabilities benefit from the same SEO improvements that everyone else does. Because browsing a web site takes disabled users even more time, they want to consume content that speaks to them in their own words. They want to find your site quickly in Google. They don’t want to spend time listening to a screen reader’s inhuman voice, let alone deciphering your confusing message.

Remember, this is yet another reason to bring in cookies and elaborate gifts for your search marketer.

SEO is related to these disciplines in becoming the ultimate warrior in web mastery:

• The experience involved with searching for information
• Accessibility
• Web site usability
• Information Architecture

We’ll take a look at each one this week. The links above will become active once I’ve covered the topic.

Photo Credit: Wizard’s Duel by Cayusa. Some rights reserved.

You probably know people who have low vision

I thought about this in depth after watching a friend’s father read a restaurant menu that had small font. He kept adjusting the distance between his eyes and the menu to try focusing better. He was a little younger than 50 years old.

A few weeks before, I had watched my own father have the same struggle at that same restaurant. He eventually gave up and had to have my mom choose something for him.

I can’t imagine what it’s like for these guys to try reading 8 point Verdana on their monitors. I doubt they appreciate having daily eye exams at their computers.

The usability expert’s take

Webreakstuff commented on Jakob Nielsen’s Top Ten Web Design Mistakes of 2005 a couple years ago. The number 1 usability mistake of 2005, according to Nielsen, was illegible font sizes. Two-thirds of users studied complained about font sizes being too small or frozen from being resized.

What’s worse, we can assume that most people probably don’t know that you can increase font size using browser controls, let alone knowing how to do it.

Screen resolutions are increasing, but web sites’ font sizes aren’t

Currently, the most used monitor resolution is 1024 x 768. Sites like Yahoo! and Apple have responded by widening their sites’ layouts. But it’s been rare to find sites that have increased their font sizes along with it. (To be fair to Yahoo!, their site layout scales very well when you resize the text using your browser’s controls.)

The sad thing is that these sites are using this new space to add complexity to their layouts. Designs are becoming busier, not bigger.

Don’t bastardize the web as a medium

I know where this comes from. Graphic designers are taught how to design for print in school. They are used to doing page layout for magazines and newspapers, which naturally have higher resolutions and have fixed dimensions. If you use the equivalent of 8 point Verdana for your web site font, you can fit content in easier and make everything look like a magazine layout.

The problem is that web users want to control their own destiny. They want to resize their fonts, and they don’t care about the designer’s control over the layout’s look. They have their monitor, not someone else’s. So be flexible. Learn to compromise the look of your pages so that your visitors can use whatever their investment in computing will allow them to.

We developers should ask ourselves which tags we should use on our HTML forms. HTML forms are a crucial part of developing a web application, so why not form good habits in marking them up?

Technorati Tags:
accessibility, usability, html, web, xhtml, css, webdesign

As I’ve gotten better with XHTML and CSS, I’ve become more interested in figuring out which tag to use for each element on a web page. HTML tags were designed to describe information, not necessarily to dictate how to display information.

We developers should ask ourselves which tags we should use on our HTML forms. HTML forms are a crucial part of developing a web application, so why not form good habits in marking them up?

Technorati Tags:
accessibility, usability, html, web, xhtml, css, webdesign

XHTML is the king of accessibility

If you go to Google Labs’ new Accessible Search, you’ll notice that they are considering the adoption of the XHTML Transitional doctype. If you view the HTML source for any of Google’s other pages, you’ll see that they don’t usually declare any kind of doctype or follow any kind of standards-based authoring practice.

I’ll venture to say that the developers at Google are pretty smart people. If they use XHTML on a product that they label as “accessible,” we should probably be using it ourselves if accessibility is a priority.

How most of us mark up forms

A simple form that you commonly see on the Web is coded like this:

<form action="action.cfm" method="post">
    <p>
        <strong>Your Name</strong><br />
        <input type="text" name="yourName" />
    </p>
    <p>
        <strong>Gender<br />
        <input type="radio" name="gender" value="M" />
        Male<br />
        <input type="radio" name="gender" value="F" />
        Female
    </p>
    <p>
        <input type="submit" value="Submit" />
    </p>
</form>

Provided that the rest of your HTML on the page is coded correctly, this will validate as proper XHTML. In this case, XHTML validation is not enough if we want for this form to be accessible. Let’s nit-pick this small bit of code.

What’s wrong with the code?

Let’s fix the form so we don’t exclude blind and low-vision users from being able to use our wonderful web applications.

Use <p> for paragraphs

First, is the content marked as “Your Name” followed by an input box really a paragraph? Is anything in the form really a paragraph, justifying the use of <p> tags? In this case, we want our fields to be defined at a block level, so let’s replace the <p>s with <div>s.

<form action="action.cfm" method="post">
    <div>
        <strong>Your Name</strong><br />
        <input type="text" name="yourName" />
    </div>
    <div>
        <strong>Gender</strong><br />
        <input type="radio" name="gender" value="M" />
        Male<br />
        <input type="radio" name="gender" value="F" />
        Female
    </div>
    <div>
        <input type="submit" value="Submit" />
    </div>
</form>

You’ll notice that you lose spacing between lines provided by the <p> tags. You’ve heard the experts preach about using CSS to separate content from presentation, so let’s use it that way by writing this CSS in an included style sheet:

form div {
	    margin: 10px 0;
	}

<label> your form fields

It’s very difficult for those using screen readers to be able to decipher which form control the “Your Name” text goes with. That’s why we have the <label> tag, which pairs text with a form field. The <label> links text to the id attribute of a given form field. Let’s apply this to the HTML.

<form action="action.cfm" method="post">
    <div>
        <label for="yourName">Your Name</label><br />
        <input id="yourName" type="text" name="yourName" />
    </div>
    <div>
        <strong>Gender</strong><br />
        <input id="genderM" type="radio" name="gender" value="M" />
        <label for="genderM">Male</label><br />
        <input id="genderF" type="radio" name="gender" value="F" />
        <label for="genderF">Female</label>
    </div>
    <div>
        <input type="submit" value="Submit" />
    </div>
</form>

You’ll notice one other key benefit on the radio button fields. If you click on the text that says “Male” or “Female,” you’ll notice that it selects the correct radio button, just like your favorite Windows or Mac applications. Also, please notice that those two radio buttons cannot have the same value defined in their id attributes.

This will help tell screen readers and other HTML renderers which textual elements label which form controls.

Note that you can style the <label> tag with CSS, thus making it unnecessary to use <strong> tags to highlight the text.

Group related fields into <fieldset>s

We can use more standard HTML tags to further describe this form. The two radio buttons for selection of gender can be grouped together. Use the <fieldset> and <legend> tags to describe that group of controls.

<form action="action.cfm" method="post">
    <div>
        <label for="yourName">Your Name</label><br />
        <input id="yourName" type="text" name="yourName" />
    </div>
    <fieldset>
        <legend>Gender</legend>
        <input id="genderM" type="radio" name="gender" value="M" />
        <label for="genderM">Male</label><br />
        <input id="genderF" type="radio" name="gender" value="F" />
        <label for="genderF">Female</label>
    </fieldset>
    <div>
        <input type="submit" value="Submit" />
    </div>
</form>

If you don’t like the standard border that your browser of choice puts around the fieldset, you can change its appearance by adjusting the <fieldset>‘s border, padding, and margin CSS properties and the <legend>‘s margin and font-weight properties, among others. You may need to use some negative margin/padding properties to get things looking the way you want them to.

The point is that you’ve described your content more fully, thus enabling everyone to better understand it. If you don’t like the way something looks on the screen, you use CSS to change its appearance, not HTML.

Now you know your HTML

As you’ll find out, once you learn these simple techniques, it is easy to adopt them into your practices with little thought going forward.

I am constantly learning how to improve my HTML authoring practices, and I’ve found that it’s best to prioritize what I learn. Forms are all over the place on the Web. I hope that by sharing what I’ve learned about them, you will improve your habits as well!