Accessibility: January 2010 Archives

Overring the Ordered List CSS on MT

| | Comments (0)

As I've noted before, I'm not too crazy about using CSS to control presentation of ordered lists. Normally, my solution is to declare my content XHTML transitional and still use the type="" attribute. When playing with a content managment system (CMS) though, you may not have that option.

I just realized that my template in Movable Type (MT) actually has a setting that makes all OL's the decimal type (i.e. 1,2,3...). That's fine except if you have a nested list, in which case you nave nested lists all being numbered 1,2,3. Even my editor, who is no usability guru, commented that this could be confusing (no kidding).

In the code, I HAD made the nested list type="a" for lower-case alpha, but the CSS in my MT template overrides any type declaration I make. Fortunately, Movable Type allows me to add custom CSS to the template, so I did. You can see the code below, but note that #alpha-inner refers to the DIV for the main content. I don't want to mess with OLs in the navigation or sidebar widgets...yet.

/* Nested OL fix */
#alpha-inner ol {list-style-type: decimal;}
#alpha-inner ol ol {list-style-type: lower-alpha;}
#alpha-inner ol ol ol {list-style-type: lower-roman;}

What this declaration does is make first level OL's decimal (1,2,3), the second level lower-alpha (e.g. a,b,c) and the third level lower-roman (i,ii,iii). If I get to a 4th level, I will probably have to rethink my content.

FYI - You can use this strategy on any CMS so long as you or a developer can access the CSS styles, but I do recommend restricting the domain to whichever DIV is the main content. Navigation is often done with a list with its own CSS which should be left alone until you have a better idea of how you want to hack it....

I'm fairly cautious when it comes to predicting the future, especially in terms of technology, but I will go out on a limb here and make one. But first, a little background.

The "Hot" Accessibility Audience Effect

The "accessibility audience" technically includes a wide range of users including visually impaired users, hearing impaired users, mobility impaired users (particularly disabilities involving the hands) and cognitive disabilities.

In reality though, a lot of developers tend to think in terms of just one disability and skimp on the rest. When I first learned about that audience, it was visually impaired users. That made sense because there are so many hurdles for that audience, but it did sometimes results in Web sites that were 100% navigable on a screen reader and was fairly difficult for a visual users (because you don't need to check colors on a screen reader).

But...once podcasting and YouTube became more common, the focus switched to providing captions for the hearing impaired audience. This is good also because finally, more video content received captions...but the price was that we often forgot to ensure that video players worked on a screen reader. Oops.

The Next "Hot" Accessibility Audience?

Will there be a next "hot" audience? I officially predict, that the next audience we will be focusing on are mobility impaired users. These aren't necessarily people in a wheelchair (although this group does need be sure they can get to a computer), but rather people who have hand injuries of some sort and have problems using the mouse or even the keyboard.

One reason I believe this will be an issue is that in the next few years, more veterans will try to use their new GI Bill education benefit.Any veteran with a permanent hand injury may need accommodation, depending on the severity of the injury.

Another reason is the aging population in general. This is when issues such as "essential tremor" come into play as well as other disorders like Parkinson's disease and arthritis. Although you can get these kinds of illnesses at any age, the statistical probability that you are affected increases with age. Among my personal acquaintances, the most common call for accessibility advice has been in reference to not being able to control the mouse or keyboard very well.

A final population I will touch on are those suffering repetitive motion disorders such as carpal tunnel syndrome. As my wrist was protesting over the fact that I was playing my action game too much after work, I remembered that it was time to use my keyboard shortcuts (eek). As we become more accustomed to our mobile devices, mice, joysticks and other devices which require a lot of repetitive hand motion, the potential for the onset of repetitive motion disorder continues to increase (Blackberry thumb anyone?)

What the Motion Impaired Audience Needs

Right now not many accessibility discussions focus on this audience, so I will list the common recommendations:

Less mouse, more (large) keyboard

The amount of control needed to aim and hit a reasonably sized key is less than to aim a mouse, joy stick and/or finger swipe. For some people, a standard keyboard is sufficient to assist users, but others may need one with extra large keys.

In any case it's good to plan keyboard equivalents for software functions whenever possible. For instance, most browsers let you tab through form fields and tab through headers (particularly in those which covert headers into an outline). Photoshop lets you switch tools by clicking a certain letter and Microsoft Office and most other commercial products replicates most of its functions with keyboard equivalents such as Control+B for Bold face. This great for avoiding frequent return trips to a tool palette or menu. Similar keyboard equivalents can be built into Flash applications or media players, but aren't necessarily done (or aren't necessarily widely known).

Note: There are issues of keyboard equivalents on the Web interfering with keyboard commands. I think they need to be carefully implemented and announced on the Web site so everyone is aware of them.

Large Mouse Targets

You can't always avoid a mouse, but it's good to make your targets larger than not. Hence "Click to download" as a link is generally preferable to "Here" as a target. Similarly a tiny icon is worse than a medium sized icon with a text label as a target. And an 8x8 pixel X to close a pop up window - are you kidding?

Motion Tolerant Dropdowns

There are times when a Web design calls for a dropdown menu (e.g. a list of all 50 states), but it should definitely have "wiggle room". The worst offenders I have seen are complex drop down menus with multiple levels which call for precise movement to move between levels - lest it disappear altogether (Argh!).

A better design might allow users to click on top levels and would remain on the screen until someone made an actual click (and would provide visible keyboard equivalents...at least for the top levels)/

Consequences

If we really do focus on this audience, I think developers will be pleasantly surprised that the screen reader audience will also benefit greatly. Imagine aiming a mouse when you can't see the screen...The other good news is that some of these accommodations may already be in place, just not visible on visual browsers. For instance, the option to skip the main menu by tabbing does benefit motion impaired users as well screen reader users.

Will we be losing our video captions again if our focus switches to the motion impaired user? That could happen, but I'm betting that this will be moved to the back burner instead. Even though a lot of developers are caption obsessed at the moment, there is an awareness that ALT tags and properly HTML tables should still be in use - all recommendations for the screen reader audience.

I don't know if my prediction will come true, but I do hope it does. I really need to cut back on my mouse for now.