I've been thinking a lot lately about why creating accessibility outreach materials targeted at bloggers needs to be different than all the great materials that are out there about web accessibility in general. I definitely don't want to be duplicating effort.

Bloggers come in a wide variety of skill levels, from those who still have trouble with sending email to those who are coders and programmers. My guess is that most blogs are maintained by people on the lower end of the technical spectrum. Look at the sheer number of blogs hosted on Blogger, WordPress.com, and LiveJournal. Sure, some of those folks are coders and programmers, but most are not.

Because of this guess, I'd been conceptualizing the information I'm trying to organize as split between "things you can do when you're posting" and "things you can change on your blog overall." So far, so good. However, that line of thinking lumped in a tip like "change your text and background color" with "create skip navigation links" as "things you can change on your blog overall."

Even the most fearful of the content creator bloggers, though, is likely using a publishing tool that makes it fairly easy to change your text and background colors.

And even the hardiest of the content creator bloggers who have learned a little bit about their templates might not get how to properly use headings right away - and headings in posts often require some CSS work.

So I'm going to take a little time and reorganize the tips I've already written and pencil in the ones I think are left. Something like skip navigation links is a great idea for the content creator bloggers who have already gotten their alt text, link text, and color schemes in order, so I'm going to put that near the bottom of the list.

And when bloggers are at the technical level where they want to tackle skip navigation links, I'm pretty sure they can take care of it from one of the existing resources out there - so instead of spending time writing tutorials, I should curate the good ones and link to them.

That will hopefully mean I'm done with writing sooner and can move on to action.

(Except that, of course, TypePad updated itself and now I have to recheck how everything works.)

What I really want is to reach out to the bloggers who don't already care about accessibility. To do that, though, I felt like I needed to get all my information organized. If I was going to say "hey, you need to make your blog accessible!" then I should be prepared to tell them how, including instructions for their blogging platform. That's what I so appreciated about Dive Into Accessibility.

This blog basically came about as a way for me to make progress in organizing my material. A blog format tugs at your sleeve when you don't work on it for very long. Obviously it's been in fits and starts. Part of that is how long it takes to do each section of the Guide. I think it's about 6-8 hours for each section that includes step-by-steps for the various blogging platforms. I struggle with how to present it in a way that's understandable to non-technical people without dumbing it down. I struggle with what level of support will help people who have never edited HTML or CSS in their lives. It's hard to figure out where to stop - at some point, people will be interested enough in accessibility that they can "graduate" to reading the accessibility blogs I read, which are overwhelmingly targeted at geeks rather than the person who started a blog on Blogger or WordPress.com just because they liked to write.

I've also been feeling stuck because I wasn't sure what to do when I got done.

While I've been away from the blog, though, dealing with a bunch of family issues, a plan has started to percolate. The plan I'm forming, means concentrating on the basics and treating some topics as "extra credit" ideas, because the people I'm interested in reaching are often not very technical. Getting those folks to remove the major accessibility barriers seems like as good a goal as getting a small number of people to push their blogs to the bleeding edge of accessibility.

So my goal is to get the Guide done, meaning usable, by the end of the year. Then I can start 2010 in outreach mode, trying to make the blogosphere more accessible rather than just writing about it.

My question for you, my readers who are already interested in accessibility: if you had to ask people to do just 5 or 6 things, rather than 25 things, what would those things be? Where should people start?

My session is flagged as appropriate for beginners, which is going to include some people who don't even know what HTML means, but I assume I'll also have some folks with some code knowledge wander in.

So far I've tried to take the best of the two previous presentations I've done, and the areas I'm focusing on are as follows - going for a mix of what's really important and other things that are helpful and easily doable:

• Breaking posts into paragraphs
• Real list markup
• Meaningful link text
• Not breaking the back button
• Alt attribute for images
• Sufficient contrast between text and background
• Using something other than color to designate links
• CAPTCHA avoidance
• Page title
• Music that plays automatically

What else is a burning issue that must be addressed?

To make your blog more accessible, though, are there any special considerations for what should be in the title? I've blogged before about how special characters in the page title sound when read by screen readers, but what about the content?

The page title is the first thing that screen reader users hear when they get to a page, so it's great if it actually tells them what the page is. If every page on your blog has just the name of the home page, that's not so helpful and could even be disorienting if a reader goes from your home page to one of your posts, or vice versa. If the page title is your blog's name, then the tagline, then the name of the post, that's a whole lot to listen to before knowing exactly where you are.

For more on page titles and how to change yours on your blog, check out Make Your Page Titles Do Their Jobs, a new tip in the Guide to Making Your Blog Accessible. And as always, feedback and corrections are very appreciated.

I was cleaning out my web bookmarks on accessibility a while ago and came across this gem from Nickie of Nickie's Nook, in a post from a couple of years ago called Accessible social media: It's not just for fun anymore, on the topic of how it feels to be a visually impaired user confronted with a visual CAPTCHA:

It's kind of like saying "People can come here in wheelchairs, as long as they have friends to carry them up the stairs."

I've interviewed Nickie on this blog, she's no slouch when it comes to technology. But she also has a very busy life, and she doesn't need to hit roadblocks like CAPTCHAs when she's trying to get things done online.

I've just checked to make sure that the tip Fight Comment Spam Without Locking Out Your Readers is updated (I hope!). So if you haven't seen it before, head on over and check it out.

But whenever I discuss alternative text, stored in a bit of code known as the "alt attribute," someone invariably asks about the different between the alt attribute and the title attribute. In the code for an image, you can put one of each, and often people are left wondering what the difference is and how to use them both effectively.

So let's start from the beginning. Here is some image code with both an alt and a title attribute:


<img src="http://www.lizardkingdom.org/archives/2005/04/bluecarpos.jpg" alt="Movie Poster for Blue Car" title="totally awesome movie, I really enjoyed it" />


The alt= part says what the picture is, the title= part is extra comments.

Repeat after me:

Alt means alternative.

Title is for extra information.

The alt attribute for an image should be whatever is needed to replace the image if it were to disappear. It needs to be fairly short, and the important information needs to be up front so it doesn't hold the reader hostage to a long, drawn-out explanation. If the image is a link, the alt text needs to say so, and where the link goes. Every image that's not a background image should have an alt attribute, either with some text, or blank if the image is purely decorative.

The title attribute is for any additional information, often displayed in a popup box by some browsers when you mouse over the image. You don't want to put any critical information here. It's often not accessible to people who use a keyboard instead of a mouse, it may not be resizable for people who need larger text to see it, and it only stays up for a short time which means it may be difficult for people with any reading difficulties. The number of images that really need title attributes are probably few and far between, and it's okay to leave it off.

So when you're thinking about accessibility, the alt attribute is where you should focus.

What's a bad way to use the alt attribute?

Stuffing it full of keywords hoping to increase your page's search engine rankings.

Seriously, people, I know you love some Google ranking, but when you use the alt attribute on an image to cram keywords at the expense of its actual function, you're essentially telling people who need it that you care more about your page rank than about whether they can even understand what's going on with your blog.

That's bad karma, yes?

Sources and further reading are after the jump, if you're viewing this post on the home page.

• Top tips for TITLE attributes on the Web Access Centre Blog
• Proper Use of ALT and TITLE Attributes on Fadtastic (though I disagree with parts of it)
• Using the title Attribute by Gez Lemon on Juicy Studio
• The Title Attribute (podcast) at Web Axe.

Glenda recently had the opportunity to present at SOBCon: Biz School for Bloggers, and apparently it went quite well! You can read more about her presentation, or make sure you download her e-book on blog accessibility.

I find Glenda's success heartening, for a couple of reasons. First, she had an opportunity to present to a large number of bloggers who were fairly new to the topic. I think many people who have presented on accessibility would agree that if you advertise a session on accessibility or web standards, a smaller number of people show up than would be there if you advertised a session on "web design tips" or "search engine optimization." Also, attendees at an accessibility session are generally people who already know something about the subject. I'm not sure how SOBCon works, but it sounds from the feedback around the web that Glenda managed to reach a large number of "accessibility newbies" and their eyes were really opened.

Second, it's great to see the commenters on Glenda's post mentioning that they are trying to improve the accessibility of their blogs in concrete ways based on her presentation. It's good to open people's eyes, but to create change, they have to take action.

So hurray for accessibility outreach to bloggers! If you haven't checked out Glenda's e-book yet, make sure you do!

So today I thought I'd present a tip that's primarily helpful to people with motor disabilities. There are many people with various motor disabilities who navigate the web without using a mouse. No, it's true! You can get a lot done with a keyboard.

To make your blog more usable for these folks, you can make sure that your links have a "focus" state, which means a visual change when someone has selected the link. If you're a mouse user, you see what's called the hover state when you "mouse over" a link. Sometimes the link changes color, is highlighted, or some other change. For keyboard users, the focus state is the critical piece because it tells that person where they are on the page as they tab through - when the link is "selected," not hovered over with a mouse cursor. If you imagine counting the number of links on a page, and then trying to tab to link number 49, you can imagine how it might come in handy to have a visual reminder of how far you've gotten... unless you're the kind of person who would never lose track of where they were when doing such things, which I am definitely not!

As discussed in the tip about choosing your blog's link colors for accessibility, text color alone isn't really enough to ensure a positive experience for all of your blog's readers. Some readers have color blindness, visual impairments, or may have lost a little of their color sensitivity as they have gotten older. So I would encourage you to use something other than just a color change to indicate the focus state.

For more on this tip and how to implement it on your blog, head on over to Give Your Links a Focus State, a new section of How to Make Your Blog Accessible. And as always, let me know if you have any thoughts, comments, or suggestions.

The only reason I didn't reject it utterly was that I once saw someone take a poll of their readers, and most of them liked the music. So in an attempt to be open-minded, I thought that in some cases it was an issue of knowing your audience, and if they liked it, then perhaps it was okay.

While going through research material the other day, though, I came across this tidbit in Improving accessibility for motor impaired users over at Webcredible:

Some motor impaired web users utilise voice recognition software to navigate through web pages. If pages on your website start to play audio without users knowing about this in advance then this can severely conflict with the voice recognition software.

There's nothing wrong with using audio but do make sure that it doesn't start by default when users arrive at the page. Instead, provide a link/button that users can select to start the audio.

Oops.

My frustration at hearing two different kinds of music overlap is likely minimal compared to the experience of someone who actually can't navigate the page because they can't hear their software. Whether the person is motor impaired or visually impaired, if they depend on audio cues for their software in order to read your blog, automatic music - or automatically playing a video with sound - is quite a roadblock.

My frustration at having to click through tabs and scroll down on blogs to figure out where to click to make the music stop is also likely minimal compared to the work required of someone with a visual impairment to even find the source of the noise.

So bloggers, let's be kind, and make our music and other audio opt in.

It describes an ongoing partnership between Facebook and the American Foundation for the Blind to make sure that Facebook can be enjoyed by everyone regardless of how they access the web - including with screen magnification software or screen readers.

Very cool!

The thing that really bugs me is, in the “Add an Image” dialog box, the Title is marked as a required field, not the Caption that becomes the ALT: a crucial piece in web accessibility.

It is the ALT text that enables an individual using a text-to-speech screen reader to hear what an image is; not the TITLE. It is the ALT text that appears on the webpage when an image does not load; not the TITLE.

Confusion about the difference between ALT and TITLE already abounds, and Glenda is right that the WordPress scrambling of all these elements does not help.

The "title" that the WordPress dialogue box is asking for does not perform the same function as the TITLE attribute in HTML. WordPress uses the title as an internal label for the image to help you find it again if you want to re-use it. That's why the default value is the filename. Using that field automatically as the TITLE in the HTML makes little sense, since the purpose of the TITLE attribute in HTML is to convey extra information about the image.

"Caption" is a word that most people associate with print publication captions that appear under photographs, and there is an HTML tag called CAPTION which is for something totally different than what happens with the caption in the WordPress dialogue box, which becomes the ALT text.

The logical place to ask for something that would turn into the ALT text would be in the "description" field, except that it's too long. And why in the world would you need to fill out three separate fields for one image, anyway?

There are similar issues in my beloved Movable Type as well. In Movable Type 3, there wasn't a prompt in the default File Upload process for the ALT attribute, and the filename was used as the ALT text by default. In Movable Type 4, using the asset manager, whatever you include in the Name field becomes the ALT text, but there's no indication that this is the case in the dialogue box. Leaving the Name field blank produces a blank alt attribute and the asset manager uses the filename as the asset's name within the system. If you use the Better File Uploader plugin (which is awesome), you can configure it to ask for alt text during the upload process, but it will still fill in the image's filename by default and you have to replace it with something meaningful.

The beauty of using HTML and CSS together is to separate content from presentation. I would argue that the way both WordPress and Movable Type handle image uploading fails to separate two other things that should be separate: the content added by the user and the internal functions of the blogging tool. When a blogger is presented with a dialogue box because she or he is adding content to their blog, in this case an image, that blogger should be prompted to add the information that will make that image work for the readers and the blogger. The needs of the software for a label to use when filing the image should be secondary, and yet they seem to drive the design of the upload process.

It's a disservice to people with disabilities, but also to bloggers, who aren't being given the information they need to set up their images with full understanding of the consequences for certain decisions. Given that a properly labeled dialogue box would go a long way toward conveying the needed information, it just doesn't seem that hard to fix.

So how about it, Automattic and Six Apart? Care to tweak your tools to encourage accessible blogs with proper use of attributes? There's a pumpkin muffin in it for you.

This is good news if you want to make your blog more welcoming for people with disabilities who use a screen reader, which includes some people with movement-related disabilities and learning disabilities as well as people with visual impairments. There are probably already some headings built into your template. Chances are, the titles of your posts are already marked as headings, making it easier for people using screen reader software to jump from post to post. Some people with certain disabilities find it easier to use text-only browsers, and they benefit from headings as well.

Your sidebars may also have some headings if you have titles for different sections or widgets; see Keep Your Sidebars Organized for more information on that topic. Within your posts, you can also use headings to organize your information or break up long posts. If you're writing a personal essay, it may not make sense to break up your posts into sections, although it can be used for effect. If you're writing an informational blog post with distinct sections, like a Top 5 post or a step by step tutorial, you may want to think about using headings.

The trick is to make sure you're using proper heading code instead of just making the heading bigger and bolder than your regular text by changing its appearance. Unfortunately, screen reader software can't really tell that you're made it purple. It just takes a quick tweak behind the scenes to add the right code. Search engines also look at text that is marked as a heading and they give it a little more weight when they're figuring out what the page is about.

I've added a section to the guide on How to Make Your Blog Accessible that walks through how to use heading code in your posts.

Take a look and let me know what you think.