accessibility posts

Javascript: Anchors in Dropdown Menus for Keyboard Access

in

My boss at work doesn’t like the top-level items that have submenus in our two-level menus to be links. In most of the sites we build, there is really no page for the top-level items to link to. Having a duplicated link to the first item or just a worthless value could be confusing, especially for both bots and screenreaders. But with no anchors, the submenus are inaccessible via the keyboard, as browsers generally only provide keyboard navigation to anchors, inputs, and buttons. As I prefer to keep my hands on the keyboard most of the time, I was disappointed with this characteristic of the menu system I built.

While building a vertical menu where the submenu drops down directly below the top-level items, I realized a solution to this issue. Anchors with no “href” attribute are fully valid, but they are interpreted much like spans and don’t receive keyboard focus or perform any actions on activation (barring event handlers of course). To a non-javascript agent, they are basically the same as the spans I would normally wrap around my top-level items. But for javascript users, I can simply add an href attribute to turn them into keyboard accessible items that can then activate the submenus. I use a worthless but descriptive value to tell users what the items do if they read their status bar. I prevent the default action anyway, but I still use a javascript qualifier to be sure and to describe the action, so the href looks like: “javascript://openMenu();”. This would do nothing if somehow the onclick event handler were not run. Like a good little javascripter, I attach event listeners programatically, of course. With jQuery, this would look something like:

elmsMenus.find("."+classTopitem).attr("href","javascript://openmenu();");

When I have time, I will have to update the horizontal menu that we use on many sites. In my vertical menu, I shall not that non-javascript users can still access the menus, because the default CSS displays them as opened. This is not the case for my horizontal menu script. I have yet to find a solution for this that will fit my bosses desires.

Lynda: Web Accessibility Principles

in

I’ve completed another Lynda course, Web Accessibility Principles by Zoe Gillenwater. This course was well put together, had a lot of good information, and should be very usable, though it perhaps had a lot of repetition (to give a feeling of what screen-readers must go through?) and pacing issues. It also, perhaps due to its age (from late 2007), missed some techniques, such as pure CSS drop-down menus.

As I watched it, in addition to taking copious notes, I stopped from time to time to implement some of the practices on my own site(s). For instance, I added a class for content that will benefit screen-readers but not be that useful to or possibly bother regular sighted visitors:

.screenreaderOnly{ position: absolute; margin-left: -9000px; }

I had been using “display:none;”, but evidently screen-readers hide that content as well. I added some screenreaderOnly headers in my navigation and footer since screen-readers provide easy navigation by header. I also created a skipToNav link (my nav is below my content) using the hiding technique above, but also used “:focus” and “:active” (for IE6) to allow keyboard users to access it:

<div id="skipToNav"><a href="#navigation">Jump to navigation</a></div>

and:

#skipToNav{ z-index: 3; position: absolute; top: -20px; left: 60px; }
#skipToNav a{ position: absolute; left: -9000px; }
#skipToNav a:focus, #skipToNav a:active{ position: relative; left: 0; }

I also added a few Firefox Extensions for accessibility purposes. Fangs writes out pages as text similarly to how they’d be read be a screen-reader. I had been using Lynx to see my pages rendered text-only, but hadn’t realized how much other stuff gets read out. Colour Contrast Analyzer and WCAG Contrast Checker both allow checking of page color contrast of individual page elements to make sure visually impaired folk can read text. They do things slightly differently, and both seem to show background-foreground pairings that don’t exist on the page.

I’ve done some other stuff to improve my sites accessibility, but plan to do more when I have free time. I will go through those accessibility checkers and attempt to move as close as I can to being compliant with them. As I start to implement this stuff on my own site, I will be able to more easily implement it on other sites I build as well. This will hopefully be helpful in getting a job as well.