I posted awhile back about some great accessibility tools out there, such as the Firefox Accessibility Extension and WebAIM’s WAVE. (Wow, that was a year ago??)

Using automated tools are a tremendous help in figuring out problematic code or color contrasts that just don’t feel like they are sufficient. However, your testing shouldn’t end there!

Similarly, don’t assume that a non-disabled person testing their site or application with assistive technologies is good enough. I’ve been asked by well-intentioned fellow non-disabled web designers, “Well, how can we get our hands on a screen reader to do testing?”

The best way to ensure your experience is as accessible as possible is to reach out to actual disabled users for testing.

This hit home for me when I watched Scott Mayer (Multiple Facets of Accessible Design – Scott Mayer presentation) demonstrate how blind users navigate both good and bad experiences via a screen reader.

For one, the speed at which the automated voice spoke was surprisingly rapid — and he even slowed it down for our benefit! Two, a sighted user trying their hand at a screen reader just isn’t the same as someone who is completely dependent on one and uses it day in and out.

Sure, a web surfer with hearing can plug their ears and watch a video, but afterwards, they can simply unplug them and go about their lives. A deaf user doesn’t have that luxury. You may think a pretend session gives you a glimpse into their world, but it doesn’t really.

Having access to disabled testers may be challenging depending on the resources in your area. There are some alternatives on the web, such as forums like the Accessify Forum, where you can post a site and ask for feedback.

The bottom line is that, whenever possible, you should use multiple avenues of testing for accessibility, the best being actual disabled users who could be part of your audience.

Tags: accessibility tools, assistive technology, screen readers, user testing

Let’s face it — when you work in a corporate environment, you’re exposed to a ridiculous amount of corporate jargon. Sometimes, it’s in the form of acronyms. Other times, it’s slang terms developed in the business world.

Example: “Let’s talk offline.”
Example: “We’ll have a go/no-go meeting.”

As easy a target as it is, I’m not about to go into the general absurdity of office lingo and corporate speak — I’ll leave that to great sites like Corporate Trash.

“Dovetailing” (there’s another one) with jargon catchphrases are excessive acronyms. I suppose it’s easier to speak with fewer words by making everything an acronym, but it’s painful to anybody on the outside trying to decipher the code.

Regardless to how easier it makes things to talk in such ways internally, it poses a user experience and accessibility problem if you litter your outward-facing web site with them.

Let’s start with acronyms. While some like FYI (for your information) are reasonably well-known, others may not be. Don’t assume that the outside world is on to all your shortcuts. Be sure to spell them out or use the <acronym> or <abbr> tag. Most screen reader devices read aloud the associated title tag, such as <acronym title=”For Your Information”>FYI</acronym>. In the browser, a dotted line appears under the item within the acronym or abbr tag, and mousing over will reveal the full description.

There seem to be different schools of thought as to if you need to use these tags on every single acronym, even if it’s used multiple times. On the one hand, only using the tag in the first instance may pose a problem if someone skips around the content and misses that initial explanation.

On the other hand, using the tag ten times for the same acronym seems a bit excessive too, especially if it’s a long one, like CAPTCHA.

Not sure where I stand on the issue, I tend to just use the acronym tag in all cases, even multiple times with the same acronym. Whatever you do, just make sure that when you need to use acronyms, there’s an explanation of what they stand for.

If the acronym is one your company made up for some sort of internal process, and basically nobody in the outside world would understand it without a frame of reference (like the initials for a department), just spell it out in your web site content. If they work for you or do business with you, they’ll learn the acronyms when it makes sense.

As for using corporate jargon and catchphrases in your content on an outward-facing web site? I say skip it. People, whether they are disabled or not, are coming to your site to either make purchases or learn more about you. Just give them concise, impactful, clear content.

Be direct.  Save the cute expressions, sports metaphors, or whatever else for your meetings…or be merciful, and stop them altogether.

Tags: acronyms, corporate jargon, corporatespeak, screen readers

Last night, I was privileged to attend the great “Multiple Facets of Accessible Design” presentation conducted by MilwauCHI and hosted by IndependenceFirst (a place so amazing that I’ll be doing upcoming blog posts about the experience)

After a great introduction to the IndependenceFirst facility by Carol Voss, including a 5 minute video about their new building, we were treated with two very different but equally compelling presentations.

The first was “Unleashing Opportunities through Accessibility” from Shawn Henry. Shawn Henry needs no introduction in the web accessibility ranks, as the Outreach Coordinator of the Web Accessibility Initiative (WAI) at the World Wide Web Consortium (W3C) and an all-around advocate and voice for accessibility awareness. She is also the author of Just Ask: Integrating Accessibility Throughout Design.

Shawn covered a lot of ground. She explained that accessibility doesn’t just pertain to those with visual disabilities — there are many more to varying degrees. There are also other “limitations”, such as technology, bandwidth, literacy, non-fluency in a certain language, etc.

She raised a point that has really been hitting home with me lately, as I discussed in my last post. There are easy things to do to improve the accessibility of a site. Sure, complexity increases when you deal with rich applications, Flash, and more complicated scripting, but many important obstacles can be cleared on the simple markup level — alt tags, page titles, headings, lists, to name just a few.

Shawn summed up accessibility poignantly by calling it, “an act of enlightened self-interest.” After all, any one of us may at any point become a disabled web user, through accident, illness, or just through the aging process.

We had the pleasure of chatting with Shawn further after the event. She is very down-to-earth and clearly passionate about accessibility. She gave us some very good advice and tactics on pursuading organizations to see both the business needs and obligations of ensuring their web presence is usable by all.

The second speaker was downright amazing. His name is Scott Mayer, a usability services specialist for American Family Insurance, who became blind at the age of 24. In my next post, later this week, I’ll share highlights from his powerful presentation.

Related Links:

• IndependenceFirst (@Independence1st on Twitter)
• MilwauCHI
• Shawn Henry (@shawn_slh on Twitter)
• Just Ask: Integrating Accessibility Throughout Design – online version

Tags: alt tags, assistive technology, IndependenceFIRST, milwauCHI, milwaukee, Scott Mayer, screen readers, shawn henry, W3C, wai, wai-aria

I’m in the very early stages of putting together accessibility improvements for an e-commerce web site. The site is several years old, and while it isn’t a complete accessibility disaster, there are many ways it can be improved. The markup was constructed decently enough, but it’s safe to say that accessibility wasn’t so much as even a fleeting thought.

My efforts are part of an overall project to improve and refresh the look and information architecture of the web site. From both a design and user experience perspective, we’ve advocated refreshing the site through gradual enhancements, instead of a massive, all-at-once redesign.

I’m excited at the chance to steer some real accessibility improvement on this project. This is a chance to get in there and make immediate improvements.

Some of the things I aim to do right out of the gate are:

These are easy “quick wins” that can be done without massive amounts of effort.

Not every accessibility undertaking — or redesign/refresh overall — needs to be a huge undertaking. For one, there may not be a budget to completely overhaul a site. Also, such overhauls can potentially be too sudden and startling a change for visitors who have been there before.

You don’t have to wait for the big, all-encompassing project to make improvements. You can tackle it piece and piece and, incrementally, improve the accessibility.

As I knock off each of those bullets above as well as whatever else I find, the site will become better and better for those who visit via screen readers, keyboard navigation or whatever means they need to. The site will become better and better, period.

Tags: accessibility, alt tags, color contrast, header tags, keyboard navigation, screen readers, usability, user experience

This week, thanks to a friend and colleague at Hello Goat Designs, I had the opportunity to do some accessibility testing on a web site he is building. I’ll share more about my findings and the final result when the site launches.

There were a few basic accessibility tweaks that I suggested, one of them relating to header tags. That gave me the inspiration for another post in my Web Accessibility 101 series.

There are a few things worth noting about properly and effectively using H1, H2, etc. These basics not only help provide an easier navigating experience for the disabled, but also get wins in search engine optimization.

Screen readers like JAWS have key commands to read off header elements, in order. For example, JAWS has a command INSERT + F6 that reads the entire list of headers, and H cycles the user through each header. The browser Opera allows you to highlight across header elements via its single-key shortcuts.

H1 should be the top level heading of a document. Often times this would be the page title. It gets huge consideration from search engines. There should only be one H1 per page.

You can use any number of H2 tags, H3 tags, and so on. And while there are six header tags, you don’t need to use all of them. There may be cases that only H1 and H2 are needed, for example. If H1 is your page title, H2′s are major headings, followed by H3 sub-headings, and so on.

Avoid skipping header tags. If there are H3′s on your page, there better be H2′s and an H1 as well. Skipping causes confusion for screen readers.

Header tags should be wrapped around actual headers or titles, not blocks of code or content. This came to mind because I recently saw a site (that was built using SharePoint Designer), that had actual tables within a header tag. That’s all kinds of wrong.

Header tags, in short, are more than just stylistic additions. For screen reader users, they are vital in giving a sense of the main topics of the page, and enabling easier navigation through your content. Additionally, effective header tag usage will get you superior search engine treatment — making your site more accessible to everybody, not just the disabled.

Tags: h1, h2, h3, header tags, jaws, opera, screen readers, search engine optimization