Ryan Fitzer

To Be, or Not to Be, an Anchor

In reading Chris Coyier’s response to a reader’s question on when to choose an anchor element over some other element when creating javascript-driven experiences, I realized that only recently did I form a concrete opinion on the matter. My response originally started as a comment on Coyier’s post, but quickly turned into a full post of its own.

Here’s the part of Chris’s response with which I identified most:

If the app is totally JavaScript dependent all behavior is attached via JavaScript, I guess it doesn’t really matter what element you use.

Until recently, I would have given the same answer. For the past year and a half I’ve been part of a large team working on the rewrite of a major ecommerce site that required full accessibility for blind, low-vision and cognitively disabled users. Being a javascript-heavy UI, it required a lot more effort in discerning the semantics of an HTML element.

I plan on writing a lot more about that experience, but right now I want to respond specifically to the question of when to use an anchor element.

The reader says that he generally used the a tag liberally to represent an element as clickable.

In brief, that’s the safest choice. But the natural inclination of a developer (ideally) is to dig as deep as possible and make the most informed choice. After all, their the ones who have to support it when things get wonky.

If you decide on something other than an anchor though, just make sure the element you choose is accessible to keyboards and screen readers. Easy. Done.

Of course, it can be a lot more complicated than that. Anchor elements are natively focusable and screen readers provide functionality for navigating a page by its anchors. This allows to users to quickly scan the page via their keyboard. Visual users often (and understandably) take for granted their ability to visually scan a page since it’s a natural response and not specific to viewing a webpage. But, substituting a different element can require a lot more effort in facilitating a equal experience to non-visual users.

Using tabindex with a value of 0 on a non-natively focusable element will allow for the element to be navigated via the tab key, and in the order of the natural document flow. But the catch is that a screen reader will not include the element in its anchor shortcut feature. This may not be necessary if the the element’s purpose would not make sense outside of its surrounding context, like a tooltip, for example.

More importantly though, the screen reader will not speak the element as a link. Visual users employ visual clues to interpret actionable elements in a page. Screen readers rely on semantics. While a visual user can instantly recognize a button by its design, a screen reader can do so only if a button element is used.

Also, it’s good to understand that title attributes are not necessarily spoken when a screen reader user is focused on an element that contains one. The popular screen reader JAWS provides this as an op-in preference. So using a span as an actionable element will need both a title attribute and screen-reader-only text (off-screen) to communicate to the user the purpose of the element.

Ultimately, an anchor element provides users an actionable element that’s accepted as a means to navigate information. Regardless of whether the navigation happens via a full page refresh, asynchronously, or with javascript turned off, the underlying meaning remains the same. Using it liberally is a good choice.

Update: 8.24.2011

Regarding ARIA, support is getting better, but it’s still pretty spotty. In fact, I’ve had to remove ARIA attributes at times because of screen reader conflicts. It can also change how the user’s screen reader interacts with a page (Form and Application modes). This can be disorienting to a user who has yet to master the full feature set of their screen reader. But after reading Dave’s comment below, I figured I should give the link role a try. I use the role when it’s useful, but the link value is one I’ve never considered.

I used the following markup for my quick test:

<span id="link" role="link" tabindex="0">Test Link</span>

Surprisingly, JAWS 12 with IE8 spoke the element as a link. I was also able to navigate to it using the u key shortcut (navigates unvisited links). The v key did not register it as a visited link even though it had been clicked. That makes sense since there’s no href. Good to know.

Update: 11.8.2011

I’ve put up a page of various attempts to mimic links. Not exhaustive, but should be helpful in drawing general conclusions. I’ll add to it as I get more examples and time.

Room to Work

I was just thinking about how nice it would be to have a Textmate command that could help you isolate the block of code you’re working on.

Here’s the  idea, when you’re working in a big, messy file you could:

1. highlight a block of code
2. press a key combination
3. Textmate grabs that selected block
4. opens a new file and sets it to the current language
5. pastes in the block of code
6. make all of your edits
7. press the same key combo
8. Textmate cuts the edited code
9. closes the temp document
10. replaces the original block of code with the updated version

That sounds like it would be pretty handy. When I get some time I’ll try to create such a thing. Plus, I need to rework my css property arranger. Some friends (and I) have found glitches.

Write a TextMate Command to Order your CSS Properties

I like to have my css property lists ordered by string length (smallest to largest). Some my find it fussy but I feel they are easier to read when formatted this way. Looking at this stuff all day makes my eyes pretty tired and I’ll do whatever I can to improve things.

TextMate has a great feature called Commands. These are essentially small programs you can write using common programming languages (I prefer php since it’s the only one I know). You can invoke these commands using key shortcuts or tab triggers.

Since I spend a lot of time formatting my css, I wanted to make it an automated process that I could fire off using the key shortcut option+return.

Be careful not to use an existing key shortcut when choosing your own. TextMate is smart enough to not overwrite the previous shortcut but instead shows you a contextual menu of the choices bound to the shortcut. This slows down the workflow, adding more steps to get the end result.

Start by opening a new document and select Bundle Editor > Show Bundle Editor

With the Bundle Editor open, select New Command. This will create a new command in whatever bundle was currently selected.

I prefer to keep all my customizations in my own bundle. This makes it easy to keep the bundles current between my home and work machines. It also makes it easy to share with friends. To create your own bundle simply select the “New Bundle” menu item first. Then add a “New Command” to it.

Give the new command a descriptive title.

Next, select what input you’d like. This is what gets passed to your command from the document. Choose “Selected Text” with a fallback of “Scope”. For the output, choose “Replace Selected Text”. You can also use “Show as Tool Tip” while debugging. This simply pops up a yellow tool tip showing you the result.

TextMate tracks the location your cursor to determines it’s scope. For instance, if you’re in-between the enclosing braces in a css rule, TextMate will determine the scope as meta.property-list.css. You can check the scope of the current cursor location using the key shortcut shift+control+p.

We want to edit the order of a css property list so we’ll need to use meta.property-list.css as our scope. This way, TextMate will pass us all the properties inside the enclosing braces, including the braces.

We also need to choose our activation method. We want a “Key Equivalent” for this so click inside the input field and press the key shortcut you’d like to use. The input field will record your actions and show the shortcut using the associated key icons.

To start using a specific language in your command you need to let TextMate know where to look. #!/usr/bin/php is the default path to the php executable on a mac running Snow Leopard.

Open the php declaration with <?php and start coding.

Make sure there is no empty lines between the php path and opening declaration. If there is, this will get returned to your document in the form of an unwanted newline character. This drove me batty until a helpful person replied to my question on the TextMate mailing list.

Here’s the tricky part, getting the input parsed out from the STDIN (standard input) constant. I referred to this excellent explanation for help. To see other data to which you have access, use print_r($_ENV). This shows an array of goodies you can use in in your command.

[updated 12.13.09] – Allan Odgaard suggested using file_get_contents("php://stdin") instead of $fstat = fstat(STDIN); $stdin = fread(STDIN, $fstat['size']); The updated command can be downloaded using the same download link at the end of the article.

Here is the full commented code for the command.

#!/usr/bin/php
<?php

// Get the properties list
$stdin = file_get_contents("php://stdin");

// remove the enclosing brackets
$pattern = '/\{(.*)\}/Us';
preg_match($pattern, $stdin, $matches);

// Trim off the whitespace
$match = trim($matches[1], "\n");

// Turn each line into a member of an array
$match = preg_split('/\n/', $match);

// Check the string length of each member.
function sort_strlen($val_1, $val_2) {
       // initialize the return value to zero
       $retVal = 0;

       // compare lengths
       $firstVal = strlen($val_1);
       $secondVal = strlen($val_2);

       if($firstVal > $secondVal) {
               $retVal = 1;
       } else if($firstVal < $secondVal) {
               $retVal = -1;
       }

       return $retVal;
}

// Iterate through the array using the preceding function to organize the array.
uasort($match, "sort_strlen");

// Wrap the finished product in braces.
$output = '{' . "\n";
foreach($match as $line) {
	$output .= $line . "\n";
}	
$output .= '}';

echo($output);
?>

Now that I have added my command and if my cursor is located inside a properties list, I can invoke it using option+return.

Here is what my properties looks like before the command:

And after:

Download the command.

Unzip and double click to install it.

Tip: Invert Your Screen Colors for Easier Reading

In terms of web design, light text on a dark back ground can give some dynamic results. When it comes to reading on the web though, I prefer the reverse. What happens, especially when the scenario is white text on a black background, is that similar to looking into a bright light, the text can become “burned” into my vision very briefly. As I end a line of text and start to wrap back, the ghost text stays with me and takes a sec to fade away. Needless to say, it can make reading very unpleasant.

There are a few simple tricks I use to alleviate this issue.

1. Write my own stylesheet for the browser with simple defaults to make the background and text reversed. Not my first choice as I usually want to experience the intended design first. Find out more about user stylesheets.
2. Use the excellent Readabilty bookmarklet. I use this on most news sites to remove all the blinking ads. It’s not prefect though. It has trouble saving the inline images and doesn’t work with paged articles, which so many sites use to gain more ad revenue.
3. Or the simple shortcut (on Mac only) of Control + Option + Command + 8. While it seems long it’s actually pretty simple. This command can be toggled quickly and is therefore my favorite.

Example: Perishable Press, a well designed and excellent source of WordPress and general web development tips.

Before the key command:

After the key command:

And if you forget the key command you can always visits your Mac’s system preferences and make the change.

While this makes reading easier on the web, I actually use light text on a dark background when I’m coding. Seems counter intuitive but I’ve found it preferable. I need to think a bit more about why it makes such a difference…

Example using TextMate‘s Blackboard theme (modified):