Back in April, Jared Smith at WebAIM posted “Accessibility Blog Roundup II“, a list of noteworthy blogs that cover web accessibility. I was already following some of the suggested sites, but overall I found the post to be incredibly useful.

I thought I would follow suit with a listing of the accessibility-focused sites that I currently frequent. I use Bloglines for feed reading, and this is pretty much my whole “Accessibility” list.

This is by no means a comprehensive list of the best sites out there. I would absolutely love getting comments recommending others of note.

In no particular order:

• WebAIM Blog by Jared Smith et al
• Do It Myself Blog by Glenda Watson
• Web Axe by Dennis Lembree and Ross Johnson
• Accessites.org (The Art of Accessibility)
• Action for blind people by Sandi Wassmer, Kevin Nuttall et al
• Adobe Accessibility blog
• All Access Blogging (Tips for making your blog more accessible to people with disabilities)
• iheni :: making the web worldwide by Henny Swan
• Box of Chocolates by Derek Featherstone
• Bruce Lawson’s blog
• Digital Likeness by Andrea Hill
• Dingo Access by Roger Hudson
• Dotjay by Jon Gibbins
• Accessible Web Design by Joe Dolson
• Learning the World by Martin Kliehm
• Oz by Glenda Sims
• Wait Till I Come! by Chris Heilmann
• Beast-Blog by Mike Cherim
• Accessibility Tips by Mike Davies
• web output by Dirk Ginader
• 456 Berea Street by Roger Johansson

Tags: accessibility, accessibility blogs, web accessibility

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

There’s a few simple accessibility tips that I’ve been meaning to talk about, some of which I took on to improve the experience on this site. Today’s subject — skip navigation.

What is it?
Quite simply, the skip navigation technique is creating a link on your site that anchors the visitor down to where the actual content on the page begins.

Why is that important?
For people with no disabilities, the ability to get right to the meat of the page and read what’s important is straightforward. Ignore the navigation, ignore whatever else you want — and just find what you need.

Those using screen readers have a different experience. Screen readers read everything from the top down. So when a user is going from page to page, they have to endure listening to all the navigation read first, as well as any other elements such as site search, header imagery, and sub-navigation. You can imagine how tedious this gets for someone just wanting to read what they came to the site for.

Also, those who use the keyboard for navigating a page must tab through all of those elements to advance as well.

In those cases, skip navigation enables one to get right to the content.

How do you do it?
Though there are few header elements on the art of web accessibility, I nonetheless have a “Jump to Content” link at the top.

The coding is quite simple:

<div id=”skipelements”>
<a href=”#maincontent”>Jump to Content</a>
</div>
…
<a name=”maincontent”></a>

Pretty much your standard, old-school anchor link.

There are a couple variances out there. You can make the skip navigation hidden to most users but able to be read by a screen reader. Frankly, the easiest, most straightforward way is to just put it at the very top of your site, in plain sight.

Those without a need for it will just ignore it. It’s not like it’s an eye sore either. Quite honestly, and perhaps in some cases unfairly, when I see skip navigation on a site, it gives me some measure of comfort that the developers at least have some consideration for web accessibility.

Common iterations of the wording are “skip navigation”, “skip to main content”, etcetera.

Like I said, while there are other ways to do this, such as hidden and driven through your stylesheet, I say just display it loud and proud, at the top of your site.

Tags: screen readers, skip navigation

As I eluded to in my post about getting accepted into the Guild of Accessible Web Designers, I had to make some edits to this site to strength its overall accessibility.

Some of these changes stemmed from WordPress limitations and others were just things I missed or wasn’t aware of. All in all, though none of the changes were out-of-this-world complex or obscure, it was an excellent learning experience for me. While this site’s accessibility no doubt isn’t “perfect” yet (is such a thing possible?), I feel better knowing that I’ve made definitive strides forward.

Here are some of the changes that were recommended to me by GAWDS:

Skip Navigation option
This is perhaps less of a must-have on a site like mine without header navigation, but it is advisable to provide an option at the top of your site for skipping straight to the main content.

Screen readers read from top down, and as such, when a visually-impaired navigator hits each page of a site, he or she has to hear the navigation spoken aloud before getting to the meat of the page. Providing the ability to skip past that to the meaningful content makes the experience much more straightforward and less tedious.

What I did: I added the “Jump to Content” anchor link you see at the top right of this page.

Proper Header Order
Correct usage of header tags (<h1>…<h2>…<h3>…etc) provides greater accessibility on a couple fronts. One, screen readers like JAWS offer a key command for reading off headers in order. They also announce the number of headers up front.

The WordPress template I’m using followed proper procedures like having only one <h1> tag, and subsequent <h2> and <h3> tags. However, there were a few instances, based on certain content showing in certain situations, where <h2> was missing. Skipping from an <h1> to an <h3> can cause confusion for screen reader users.

What I did: I straightened out some of the inconsistencies to ensure that on all pages of this site there is one <h1> followed by <h2>’s. I didn’t find the need to go beyond <h2>’s.

Link Focus
For those navigating through a site via a keyboard, making it obvious what link they are focused upon is good accessibility. The unformatted dotted-line box around the focused-upon link isn’t the most visually discernible, across the major browsers.

What I did: I chose a distinctive orange color to clearly denote what link you are focused on when you tab through the site.

a:focus, a:active {
text-decoration : none;
background: #ffce00;
}

Color Contrast
When you have text on top of a background image or solid background color, if there isn’t a strong enough contrast between the respective colors, certain visual disabilities such as color blindness may prevent users from properly differentiating the elements.

WCAG 2.0 call for a minimum contrast ratio of 4.5:1 (3:1 for large text).

What I did: Using an online contrast ratio calculator, I followed the most stringent Level AAA WCAG requirement by ensuring that my “the art of web accessibility” header text was at least a 7:1 ratio from the blue cloud background image.

Likewise, I made sure that my aforementioned link focus background color adhered to a 7:1 ratio from the text on top of it.

Ambiguous Linking
Last and certainly not least, the WordPress usage of “No Comments” or “X Comments” linkage for all blog posts is a link that provides no clear-cut direction as to where it will take the user. Links on the same page should also be worded uniquely and specific to the target.

When you see “No Comments”, you don’t intuitively know that clicking on it is your avenue to posting a comment on a specific topic, much less when there are 5 identical “No Comments” on the same page.

What I did: Given the handy code below, I changed the offending link in the Main Index Template so that, as you can now see on any post on this site, it reads something like “Comment on X topic”. That way, it is more obvious from the link that clicking on it takes you where you can post a comment on the specific post “X topic”.

<?php if('open' == $post->comment_status) : ?><p
class="comment_link"><?php comments_popup_link('Comment on
'.$post->post_title, '1 Comment on '.$post->post_title, '% Comments on
'.$post->post_title,'postcomment','Comments are off for
'.$post->post_title); ?></p><?php endif;?>

I made a few minor tweaks here and there, but these suggestions from GAWDS were very helpful and set me in a good direction for making this site closer to practicing what it preaches.

Tags: color contrast, gawds, guild of accessible web designers, h1, h2, h3, header tags, link focus, skip navigation, WCAG, Web Content Accessibility Guidelines, WordPress

It’s no great revelation that many people use Internet Explorer to comb the web, while others prefer Firefox or Safari. Some are giving Chrome a go, and a small percentage hop around cyberspace through Opera. Those of us in the web design and development world use all of the above (or at least should!)

I remember, back in my college days when the Internet was first making its foothold, I used the text-only browser Lynx to putter around, mostly because I had problems getting Mosaic to work on my Mac and 2400 modem.

As I began researching web accessibility, I was surprised to read that people still use Lynx.

Sure, there are people restricted by low bandwidth Internet access who would sooner get to where they are going than endure painfully long load times.  But Lynx by its nature has an attribute that makes it particularly appealing to people with certain disabilities — because it strips down a webpage to its most basic, GUI-less state, and can be completely navigable by keyboard. For someone with physical limitations that affect the motor skills necessary to navigate with a mouse, strict keyboard navigation is much easier.

Some other assistive technologies that aid the disabled in their web surfing:

JAWS™ screen reader
JAWS is long-standing software that enables the visually impaired to navigate Windows more easily. It uses text-to-speech technology and also interacts with refreshable Braille displays (to be discussed in a moment). Working over the top of Windows, it begins its speech capabilities upon startup. A user navigates using keyboard commands and shortcuts. This extends to Internet Explorer as well, reading aloud what is displayed through the code of the web page.

Naturally, as we’ll talk about at length in future posts, how accessible a site is determines how well programs like JAWS present its material to blind visitors.

Like a lot of assistive technologies, JAWS is not inexpensive. It runs $900 and up. Another option in roughly the same price range is Windows-Eyes.

VoiceOver
Built right into Apple’s OS X since 10.4, VoiceOver allows users to navigate about their Mac using keyboard commands and voice. It works with Braille displays and boasts being very intuitive for users of Windows-Eyes and JAWS who are switching to Mac. 

Refreshable Braille Displays
Some blind computer users prefer to use speech technology to navigate, while others opt for Braille. Refreshable Braille displays, in layman’s terms, raise dots to form the Braille that enables the visually impaired to read whatever the screen reader is capturing. As an example, Freedom Scientific offers 40-cell and 80-cell displays. Their devices are quite expensive in their own right, roughly $4000 and up. The ALVA Refreshable Braille display is another example.

Screen Magnifiers
Built in to Windows, Mac OS X, and several flavors of Linux is “magnifying glass” type of technology, to enable those who are visually impaired by limited sight to zoom in on whatever they want on their computer screen, including web browsers.

There are certainly other assistive technologies that will crop up in future posts. These are but a sampling. Feel free to pass along others worth mentioning in the meantime. As I continue along with my Web Accessibility 101 series, I hope to better flesh out the user experience that various disabilities create. 

Web accessibility — specifically, how designers and developers build out their sites — make such assistive technology’s jobs easy or very difficult.

Tags: accessibility, assistive technology, braille, jaws, screen magnifiers, screen readers