Loading ...
Sorry, an error occurred while loading the content.

Re: ADA (accessibility compliance) issues

Expand Messages
  • Robert E Boughner
    ... Act provision for providing court access by states, and this is spurring interest in accessibility compliance issues for overlibmws popups if used at sites
    Message 1 of 7 , May 29, 2004
    • 0 Attachment
      --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...> wrote:
      > ----- Original Message -----
      > From: Robert E Boughner
      > To: overlibmws@yahoogroups.com
      > Sent: Friday, May 28, 2004 7:19 PM
      > Subject: [OLmws] Re: ADA (accessibility compliance) issues
      > --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...>
      > The Supreme Court recently upheld an Americans with Disabilities
      Act provision for providing court access by states, and this is
      spurring interest in accessibility compliance issues for overlibmws
      popups if used at sites that may be encompassed by the ADA. This is
      my understanding of the situation, posted for the archive and
      subsequent reference to it.
      > For normal use of overlib popups, the device handler
      correspondences for onmouseover, onmouseout and onclick are,
      respectively, onfocus, onblur, and onkeypress. For accessibility
      compliance, e.g., when using IE v5 or higher with screen readers, each
      of the handlers should be paired in the markup. The key-based
      handlers should include RELX,0, RELY,0 commands, which are in the core
      module. E.g, for links and for area elements in image maps with
      onmouseover popups, you want:
      > href="foo.html"
      > onmouseover="return overlib(...);"
      > onfocus="return overlib(..., RELX,0, RELY,0);"
      > onmouseout="nd();"
      > onblur="nd()
      > onclick="nd();"
      > onkeypress="nd();"
      > The user tabs through the links and any area elements, and the
      popups appear in the upper left corner of the screen. They are
      replaced there on subsequent tabs to the next link or area tag, or
      disappear if not sticky and the next link or area tag has no overlib
      popup associated with it. The popups also are handled properly if the
      link or area element is activated via the enter key. The popup geared
      toward screen readers can be optimized for accessibility, i.e., need
      not have the same content as the popup geared toward sighted users.
      > Fote,
      > Have you tried your suggestion in browsers other than IE? Using a
      RELX,0,RELY,0 in Netscape 7.1 will sometimes obscure the popup because
      it doesn't show up, apparently because the positioning routine hasn't
      gotten the most up to date value of the window scrolling. Also I
      can't get anything to work in Opera when I try to march through the
      links using the TAB key. I don't know if they've got keyboard
      navigation or not. I'd be interested in hearing your experience with
      the other browsers.
      > Opera7 supports Tab and Shift-Tab changes of focus only for form
      elements, and not also anchors. For example, if you go to:
      > http://www.macridesweb.com/oltest/STICKY.html
      > and invoke the "Google Search" popup, I initially set the focus on
      the input element, and Opera7 does set that. You then can use Tab and
      Shift-Tab to cycle the focus back and forth among that input element
      and the two submit buttons.
      > For navigating through anchors with Opera7, you use the 'a' key or
      Ctrl+DownArrow instead of Tab, and the 'q' key or Ctrl+UpArrow instead
      of Shift-Tab. That works fine for onfocus-invoked overlib popups.
      I found that out after I sent this message. I ended up defining the
      F6 key to move to the next URL and it seemed to work fine for me.
    Your message has been successfully submitted and would be delivered to recipients shortly.