Form Accessibility - Try Out Your Own
With web standards being all the rage, and accessibility being a major driving factor in people adopting standards, you might be surprised to actually check out the accessibility of web-sites. After watching a video of a blind user using Jaws, I figured to give using a screen reader a try just to see if I could understand it any better. I ran into a couple problematic areas; what caught my attention first was the use of forms .
When Things Were Right
When a form was built properly, I could easily understand what inputs a form had, and what input I had tabbed to. Quite simply, there were 2 tags the specifically improved the accessibility of the form for my screen reader:
When I tabbed to an
input that was within a
fieldset , and that
fieldset had a
legend , it would tell me. The above would read to me: “Personal grouping.” So if this
fieldset wrapped up inputs like your name, telephone, and e-mail address, it would remind me each time that this
input was part of the “Personal grouping”, so I knew I hadn’t tabbed to a new
fieldset . Good.
<label> <input name="personal:name" type="text" /> <span>Name</span></label>
For specific inputs, having a
label did exactly as we would hope. I tabbed to the
input , and it read the
input type: “Name, text.” It specifically worked with the above example, when the
input was inside a
label . It would read the rest of the text inside the
When Things Sucked
I visited a few other sites that seemed to be using standards, and found that their forms performed far worse. It showed that using the correct structure for forms is actually very important . When a form used a simple paragraph before an input, with no
label , guess what happened? Yep, it skipped it. When I tabbed to an
input , it would just read me: “Text”. Hey, great. Any text? You got it: poop.
Yea, not good.
Even if someone managed to make up information for these fields, or perhaps, say they did have labels on them, one more form feature that screwed my experience using a screen reader: captcha . Some implementations simply had an image above the input, with no alt tag, no possible way for me to ever prove I’m a human being. Minus one call to action.
Try Out Your Own
I’d suggest grabbing NVDA, and surfing your site, and pay attention to your forms. See if the way you made them makes sense to a screen reader. And then visit some of your favorite sites, try out their forms, and compare with their markup. It’s quite enlightening.
We see valid code popping up all over the place. And that’s great! Web standards should be followed by everyone. But, is it possible to make your code pass W3C’s validator without actually meeting the standards?
Valid vs Semantic
Standards were set for xHTML, and the validator can read through and make sure that every textarea tag has the properties for cols. But what if you use tags improperly? You could very easily make a heading, without using a h2 tag. Or you could italicize text, without using the em tag. What does that hurt?
You’ve lost the strength of web standards in relation to better SEO, because spiders collect data in headers as more important than in paragraphs, and you’ve lost all emphasis for accessibility. Reading software checks for headings, paragraphs, emphasis, strong, lists, and so forth. So the question is, how’s the validator supposed to know the difference?
Examples of Semantic Mark-up
Here’s some examples of non-semantic versus semantic mark-up, as well as some tips to doing so.
You could make the logo appear by styling a div to contain the logo.
But think about it in a semantic perspective. What does the logo mean? Is it the most important distinguisher on the page? Well then, give it an h1 tag! And on the web, wouldn’t the logo likely represent the whole web-site as a whole? Make sure it’s got an anchor to the index as well.
<h1 id="logo"><a href="http://domain.com/" title="Domain's Home Page">Domain Dot Com, Inc</a></h1>
Make sure to use a good title as well, and also spell out the company name inside the h1 tag. Since the readers and spiders couldn’t care less about your logo, you need to tell them what is important in text format.
I’ve seen code like this before:
<div class="main-text">Welcome to McArthur GFX, the portfolio of Sean McArthur. He currently lives in Orange County, CA.He's a designer, developer, programmer, and CSS genious. He plays with Rubik's cubes but sucks at it.</div>
Obviously, this is standard text on a web-site, and should be inside a paragraph tag. You could simply change the div’s to p’s, and keep the same style. It will look exactly the same. So why do it?
Like I’ve said, outside the p tag, text readers aren’t going to know what proper emphasis to put on the text. Bad for SEO. Bad for accessibility.
Take the header quote of my web-site. It has text in there, possibly “I live a web-standard world.” And I’ve changed the color of web-standard to a reddish. Now here’s two ways you could do this, the second being the better way.
<h2>I live in a <span class="red">web-standard</span> world.</h2>
And the semantic way:
<h2>I live in a <em>web-standard</em> world.</h2>
You can use ths span tag to differentiate text in the same in-line paragraph, but what is the purpose? Is it merely for design purposes? In my case, I wanted to emphasis the “web-standards” phrase. I mean, I’m really wanting it to have the same power as italics, but I want it red instead. So when read, it should still have the emphasis of the em tag.
You could make your navigation simply a set of divs that each contain their own anchor and background image. And that would validate. But, you have to think about what the navigation is in terms of structure. Your site navigation is really a list of links.
<ul id="nav"> <li><a href="/">Home</a></li> <li><a href="/contact/">Contact</a></li></ul>
- Subscripts or fine print: Use the <small> tag.
- Describing form elements: Use that <label> tag. It let’s readers know it’s labeling a form element.
- Quoting elements: There’s the <blockquote> to make something stick out in it’s own block, and there’s <cite> to quote something from somewhere else.
The key here, is to realize that in the xHTML, you’re creating the informational structure. The HTML is what crawlers, readers, and the like care about, and all these useful tags were created for certain data types. You can always change the way everything looks with CSS. You don’t like the way cite makes things italics? Then change it up. But keep it cite, because that’s its real data type.