This week I’ll be presenting two topics at Spring <br />, Web Accessibililty Acronyms and RIA Accessibility. As I was pulling together some resources to share, I pulled out a blog post I wrote for our Resource Interactive Technology blog. I figured I may as well share it here as well…

Is your site accessible? Web accessibility is making the news, with the target.com lawsuit[1] the most notable. It’s no longer enough for a developer to know Java, .NET, PHP, AS, HTML, CSS, JS, XML (insert other TLAs as applicable), now they’re expected to be experts on WCAG, W3C, ADA, WAI, WAI-ARIA, JAWS and Section 508, as well?

Is what we’re doing accessible? How do we know?

Testing for web accessibility is challenging; there are consultants[2, 3] who make their living on it, and many comprehensive (expensive) commercial tools[4]. However, there are several simple tools a developer can use to ensure he’s being conscious of some of the common barriers to accessibility.

Note: there is a difference between making a site comply with accessibility guidelines, and making one that is usable by people with different disabilities. The former may be assessed to some extent by automated tools, but user testing is really required to ensure a site is usable and provides visitors with a positive experience.

Automated testing isn’t infallible, and not all the guidelines are verifiable by automatic means. It’s been estimated that only about 25% of accessibility errors can be verified automatically. As well, the tools themselves aren’t perfect. Jim Thatcher[5] and Gez Lemon[6] have posted reviews of automated testing tools on their respective websites. Passing an automated validator does not guarantee a site will be accessible! However, it is more likely to be accessible than one that does not validate.

FireFox: a developer’s best friend

There are many FireFox extensions related to accessibility. A few of my favorites:

FireFox Accessibility Extension: Similar to the standard web developer toolbar, this offers many features related to accessibility. The “report” option applies to a single webpage, and records the frequency, severity and rationale for each reported issue. https://addons.mozilla.org/en-US/firefox/addon/5809

FANGS: A screen reader emulator. For anyone who’s tried to use a screen reader, it can be very hard to understand (and navigate!) FANGS offers a textual representation of how a page would be read on page load. This helps to see if content is accessible, but doesn’t help in terms of interaction. http://www.standards-schmandards.com/projects/fangs/

Fire Vox: For those not content with a screen reader emulator like FANGS, Charles Chen has created a fully-featured screen reader for FireFox. It reads changes made to the DOM, and does not have access to changes that occur within plugins (like Flash). Fire Vox does have support for live regions marked up for WAI-ARIA (proposed markup to help make AJAX accessible) http://firevox.clcworld.net/

Color Contrast Analyzer: This tool is moreso for designers than developers: it can be used to determine if the foreground and background colors of elements have “sufficient contrast.” This functionality is also available via the FireFox Accessibility Extension listed above, I haven’t compared the output from each. http://juicystudio.com/article/new-improved-colour-contrast-firefox-extension.php

Other techniques

Accessibility doesn’t just refer to blind users with screen readers. Color-blind, short-sighted and mobility-impaired users need to access your site as well. The following techniques can help you understand their experience.

Throw your mouse out the window: Tab through your site. Is it a painful process to actually get to the content on your page? Can you access all the actionable items?
Using skip navigation and semantic HTML markup can help *

Resize your font: Most browsers allow users to resize their font using keystrokes. What happens to your site when you increase your font size once or twice? Is it still legible?

Disable JavaScript: Can you perform all essential site actions without it?

That OTHER browser

Although I mention several FireFox extensions, it’s commonly believed that most users of screen readers are using Internet Explorer on Windows. There are some differences in how the different browsers interact with assistive technology, so it is imperative to perform testing in both environments. Vision Australia has an accessibility toolbar available for Internet Explorer: http://www.visionaustralia.org.au/ais/toolbar/

No one sets out to build an inaccessible site, but sometimes the end result is such. We may not be able to offer a visitor using assistive technologies (screen readers, screen magnifiers, pointing devices) the same rich, engaging experience as other visitors, but we should work to provide him with something. These tools help ensure at least some of the common barriers to accessibility are removed.

* Most screen readers allow users to bring up a “links list” or “headers list” so the visitor can navigate quickly to the section they’re interested in. HTML button or submit elements allow for a keyboard user to submit a form more easily than images that evoke JavaScript for form submission.

Citations

[1] http://www.eweek.com/c/a/Retail/Court-Rules-Against-Target-in-Web-Site-Accessibility-Lawsuits/
[2] http://www.wats.ca/showcategory.php?categoryid=14
[3] http://jimthatcher.com/
[4] http://jimthatcher.com/testing2.htm
[5] http://jimthatcher.com/testing1.htm
[6] http://juicystudio.com/article/invalid-content-accessibility-validators.php

My topic suggestion for Spring <br /> has been accepted. On June 3rd, I’ll be presenting the following:

Topic: Making RIAs Accessible
Description: Rich Internet Applications offer the site visitor a more interactive, engaging experience. But can this richness be conveyed to a user of assistive technologies, and how?
This session will differentiate between DOM-based (AJAX) and Plugin-based (Flash/Flex) RIAs in terms of navigation and notification of changes taking place. We will look at current and proposed best practices and techniques.

I am drafting an article for the RI:Technology blog on Screen readers and Search Engines, and was reviewing a paper a colleague wrote about Search. He mentioned sIFR as a technique “to bring content to search engines”. I asked another colleague about this, as I’d always just considered sIFR as a “stylability” technique.
We started talking about the weight factor of search engines, whether content written to a page and then sIFRized would be weighted more heavily than the alt text of an image. I hadn’t really thought about that before. I then mentioned a habit I have of placing images within a heading tag, i.e.
<h1><img alt="descriptive text" /></h1>. Toby asked if this really worked, if the alt text would be considered the header. I realized that I’d never really verified it before.

So I took a quick look at an example using FANGS, and learned that alternate text, really isn’t. Turning off images would cause the alt text to display as the appropriate heading level, but at least for FANGS, the alt text does not get surfaced as the heading (the text should show up before the colon in the screen shot below)

Now, obviously FANGS is an emulator, and it’s possible that a screen reader would access that alt text. But this gave me something to consider..

One of our Human Factors Engineers just asked us to compile a list of “what makes good code”. He had a few initial suggestions, and they were added to for the following list. Although I think we are aware of certain principles, how do we create a checklist of what is “good” versus “poor”.

1. The code is valid
2. Inline comments are used consistently and effectively
3. Alignment and structure of the code display allows for easy scanning and reading
4. The code is accessible
5. Tables are not used for layout
6. CSS is used appropriately via an imported style sheet, a linked style sheet, or styles in the header (in that order).
7. The code is as slim and compact as possible
8. The code uses semantic markup
9. Inline styling and scripting is kept to a minimum
10. Graceful degradation is kept in mind

You can’t currently use CSS to target input elements of a specific type. (i.e. radio, text, etc). This can be a pain when you want to set padding on radio buttons, or a width on textfields. Today’s issue was adding left padding to a button.

I decided to throw together some script to find these elements and apply the appropriate style info, and this is what I came up with:

function cssInputTypeFix(tipe, stile,val) {
  <!-- until browsers support CSS input type -->
  var inputs = document.getElementsByTagName("input");
     for (var i = 0; i < inputs.length; i++) {
         if (inputs[i].getAttribute("type") == tipe) {
             inputs[i].style[stile]= val;
         }
      }
   }

I then applied this when the page loaded, with Simon Willison’s handy dandy addLoadEvent script

addLoadEvent(function() {
   //cssInputTypeFix(type,style,val)
   cssInputTypeFix('button', 'marginLeft', '5px');
   }
)

And of course, as soon as I finished I did a search on the web and found this article: http://www.dustindiaz.com/input-element-css-woes-are-over/ It is along the same lines, although he creates styles such as input.text, input.button and uses the onload event to append the appropriate classname. Well, mine can do that too

cssInputTypeFix(‘button’, ‘className’, ‘button’)

where you have a class named button.

From Chapter 9: CSS-DOM.

A neat example on how to target elements in relation to their siblings. The following may be used to attach specific presentation to the element following another specific element. The example given is “the element immediately following an h2″. I like this; reminds me of the proposed section element in XHTML2. Headers are semantically associated with the content that follows, and often there are presentational implications as well.

This is also similar to the CSS pseudo-classes “first-child” and “last-child”.. which are not widely supported in modern browsers. This is a way to achieve those effects while browsers catch up.

Code:

function getNextElement(node) {
  if (node.nodeType ==1) {
      return node;
  }
  if (node.nextSibling) {
     return getNextElement(node.nextSibling);
  }
  return null;
}

And the code they used that called this one:

function styleHeaderSiblings() {
 if (!document.getElementsByTagName) return false;
 var headers = document.getElementsByTagName("h2");
 for (var i = 0; i < headers.length; i++) {
   var elem = getNextElement(headers[i].nextSibling);
   addClassName( elem, "intro");
 }
}

Thoughts: Can this help with setting up tabs, etc? Although we seem to be moving towards the sliding doors tabs, what about using this to determine if you are at the first or last tab, and load the appropriate image accordingly?

…….

And as I read further…
The book then goes onto talking about abstraction. The styleHeaderSiblings function is very specific, it deals with h1s and the classname “intro”. This should really be made more generic so it is reusable. We really should modify it to take in a tag and classname as arguments.

function styleElementSiblings(tag, theclass) {
 if (!document.getElementsByTagName) return false;
 var headers = document.getElementsByTagName(tag);
 for (var i = 0; i < headers.length; i++) {
   var elem = getNextElement(headers[i].nextSibling);
   addClass(elem, theclass);
 }
}

I should also store this somewhere.. and here seems as good a place as any!

function insertAfter(newElement, targetElement) {
  var parent - targetElement.parentNode;
  if (parent.lastChild == targetElement) {
     parent.appendChild(newElement);
  } else {
     parent.insertBefore(newElement, targetElement.nextSibling);
  }
}

Joe Marini has developed a tool called the DOMDumper free for download. It’s a single js file, and then you create the following link


<p><a href="javascript:DumpDOM(document, ' ')">Show Structure</a></p>


My thought is that it would be good to modify the script so that you can check the structure of a document from outside the doc itself.