Web Directions North » Blog Archive » Real World Accessibility for Real World People with Derek Featherstone

• The real world is messy when it comes to a lot of things including accessibility.
  • Build things that follow the guidelines but ensure a good experience for everyone.
  • Checklist syndrome – people know they need to be accessible, but always turn to guidelines. They don’t know why they need to comply. They just want to be able to state they are compliant.
  • This removes the person from the equation and just follows the ‘rules’.
  • The checklist is a means to get to accessibility, but not the endpoint.
  • Small usability barriers for average users can become huge issues for a person with a disability.
• Advanced search page:
  • Differentiation between like elements: simple search box in the header vs. advanced search in the main content area of the site.
  • Poses a usability issue for everyone.
• News items:
  • “News for September 22, 2007”
  • Users expect current/daily news
  • Also expect to see an news archive elsewhere on the site
  • Changed wording to “Highlights for September 22, 2007”
  • This changes the expectation for the user
  • Real people need to be involved in testing to identify these issues.
• Dopplr:
  • Sharing your trips with another user: notification appears out of context of the clicked action.
  • The notification could be displayed near the action link in source order, but use CSS to move notification visually.
  • Question: “does this change if you’re using a full page refresh vs. an ajax call?” On page refresh, give the focus of the page to the notification. Possibly include an indication of the notification in the tag.
  • The most important thing to remember is to remember that the interaction should have a logical (linear) path.
• Dopplr:
  • Managing notifications.
  • Clicking with the mouse maintains context (ajax functionality maintains context). Good for sighted users.
  • Click using the keyboard shifts focus back to the top of the page. Loses context for keyboard users.
  • Clicking with keyboard should reset focus to where the click occurred.
  • You won’t find this issue in any checklist or guideline. Will only find this by seeing how real users interact with the application.
• Custom Map Widgets (Google Maps):
  • Need to provide the controls in an accessible way.
  • Voice recognition software can’t identify the map controls as a link or a button.
  • Requires many steps to use mouse grids to narrow down the screen to click a map control.
  • Keyboard users can’t tab to any of the map controls.
  • Replace Google map controls with custom controls (button elements). Use image replacement and CSS to make them look nice.
  • Now, VR software can recognize these controls and keyboard users can easily tab to the controls.
  • Makes this interface accessible to all users.
• Amazon.com:
  • Tagging mechanism
  • Clicking an existing tag’s checkbox adds the tag to a text box.
  • Checkboxes aren’t real checkboxes, they’re just emulated with images/Javascript/CSS
  • Not keyboard focusable, not visible to VR software as a checkbox. If it looks like a checkbox, it should be a checkbox.
• British Rail (Alternate accessible versions):
  • Toilet sign: text and braille.
  • Flush sign – braille for title, but not for the additional description (could be a critical instruction that’s not available to non-sighted users).
  • Another caution sticker, critical instructions, but no braille available.
• Flickr:
  • Inline text editing.
  • Instruction only appears when hovering over title with mouse.
  • Keyboard users can’t hover with the mouse.
  • They provide an alternate link (version), that provides the functionality for keyboard users.

Posted by Jeff on 30/01/08 at 11:45 am