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

Re: [OLmws] ADA (accessibility compliance) issues

Expand Messages
  • Dennis Sandow
    ... Thank you, Fote. Very useful suggestion. You probably meant to say onblur= nd(); Dennis
    Message 1 of 7 , May 18, 2004
    • 0 Attachment


      Foteos Macrides wrote:
      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();"

      Thank you, Fote.  Very useful suggestion.

      You probably meant to say
      onblur="nd();"

      Dennis
    • Foteos Macrides
      ... From: Robert E Boughner To: overlibmws@yahoogroups.com Sent: Wednesday, May 19, 2004 7:59 AM Subject: [OLmws] Re: ADA (accessibility compliance) issues ...
      Message 2 of 7 , May 19, 2004
      • 0 Attachment
        ----- Original Message -----
        Sent: Wednesday, May 19, 2004 7:59 AM
        Subject: [OLmws] Re: ADA (accessibility compliance) issues

        --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...> wrote:
        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,
        Thanks for the information on this.  My inclination is that you can probably get rid of the RELX/Y commands for the onFocus handler in newer browsers which expose the whole page through its DOM.  When I get back from my little trip, I'll see what can be done on this if you haven't done it already.

        Oh, BTW, you don't need to have 0 parameters on the RELX/Y; one can use other values too.  Was there some reason that you recommend 0?
         
        Bob,
         
        It's not clear to me what your points are in relation to screen readers with speech or braille outputs, so please do elaborate when you get back.
         
        Regarding the RELX/Y parameters, screen readers commonly indicate a line where a change has occurred on the page, and have a command that uses the line as a parameter for presenting the changed portion (as speech or braille).  If the popups appear in a consistent place, the users of such devices may adopt a simple rhythm for getting the popups presented to themselves as they tab through the document.
         
        Again, it's not clear to me what your points are in relation to screen readers, so please do elaborate when you get back.
         
        Fote
        --
         
      • 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 3 of 7 , May 19, 2004
        • 0 Attachment
          --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...> wrote:
          > ----- Original Message -----
          > From: Robert E Boughner
          > To: overlibmws@yahoogroups.com
          > Sent: Wednesday, May 19, 2004 7:59 AM
          > Subject: [OLmws] Re: ADA (accessibility compliance) issues
          >
          >
          > --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...>
          wrote:
          > 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,
          > Thanks for the information on this. My inclination is that you
          can probably get rid of the RELX/Y commands for the onFocus handler in
          newer browsers which expose the whole page through its DOM. When I
          get back from my little trip, I'll see what can be done on this if you
          haven't done it already.
          >
          > Oh, BTW, you don't need to have 0 parameters on the RELX/Y; one
          can use other values too. Was there some reason that you recommend 0?
          >
          > Bob,
          >
          > It's not clear to me what your points are in relation to screen
          readers with speech or braille outputs, so please do elaborate when
          you get back.
          >
          > Regarding the RELX/Y parameters, screen readers commonly indicate a
          line where a change has occurred on the page, and have a command that
          uses the line as a parameter for presenting the changed portion (as
          speech or braille). If the popups appear in a consistent place, the
          users of such devices may adopt a simple rhythm for getting the popups
          presented to themselves as they tab through the document.
          >
          > Again, it's not clear to me what your points are in relation to
          screen readers, so please do elaborate when you get back.
          >
          Fote I wasn't making any reference to screen readers or such. I can't
          really do that since I have no idea how they work since I've never
          seen one. I was just making the point that you could probably get a
          location of the popup from an onfocus handler as illustrated in this
          simple code which works in Netscape 7.1 but doesn't function in IE
          (which I haven't had time to debug yet):

          function focusFn(e) {
          var X,Y;
          e = (e) ? e : event;
          if (e && e.type == 'focus') {
          var target = (e.target) ? e.target : e.srcElement;
          if (target.nodeType != 1) target=target.parentNode;
          X = pageLocation(target,'Left');
          Y = pageLocation(target,'Top');
          alert('Target element is ' + target.tagName + '\nX: ' + X + '\nY:
          ' + Y);
          }
          }
          function pageLocation(o,t){
          var x=0
          while(o.offsetParent){
          x += o['offset'+t]
          o=o.offsetParent
          }
          x += o['offset'+t]
          return x
          }
          document.onfocus = focusFn;

          The alert box tells me the element and its page location. All that
          you would need now would be to substract the vertical and horizontal
          scroll amounts to come up with a relative screen location.
        • Foteos Macrides
          ... From: Robert E Boughner To: overlibmws@yahoogroups.com Sent: Wednesday, May 19, 2004 10:20 AM Subject: Re: [OLmws] ADA (accessibility compliance) issues
          Message 4 of 7 , May 19, 2004
          • 0 Attachment
            ----- Original Message -----
            Sent: Wednesday, May 19, 2004 10:20 AM
            Subject: Re: [OLmws] ADA (accessibility compliance) issues
             
            <snip>
            Fote I wasn't making any reference to screen readers or such.  I can't really do that since I have no idea how they work since I've never seen one.  I was just making the point that you could probably get a location of the popup from an onfocus handler as illustrated in this simple code which works in Netscape 7.1 but doesn't function in IE (which I haven't had time to debug yet):

            function focusFn(e) {
            <snip>
             
            Bob,
             
            DHTML and CSS have been around for a long time now, and screen readers for GUIs have their own functions for dealing with such things
             
            The problem is the default setting for positioning overlib popups, which is cursor-based and tracks the cursor via the core module's internal function for handling onmousemove.  That is conceptually a "psychedelic" situation for users who are not sighted and would be trying to deal with all that screen activity via a speech synthesizer or braille.
             
            If both onmouseover and onfocus are specified, the screen readers can treat the onfocus version of the popup as intended for them, and correspondingly the author of the document should use positioning based on the window margins, and with a consistent position, to make life easier for the non-sighted users.  The NOFOLLOW command could be used, but that does not yield consistent positioning as the user tabs through the document, so RELX/Y are preferable  As I indicated, the onmouseover version of the popup is for the sighted users and need not have such restrictions.
             
            Fote
            --
             
          • Foteos Macrides
            ... From: Robert E Boughner To: overlibmws@yahoogroups.com Sent: Friday, May 28, 2004 7:19 PM Subject: [OLmws] Re: ADA (accessibility compliance) issues ...
            Message 5 of 7 , May 29, 2004
            • 0 Attachment
              ----- Original Message -----
              Sent: Friday, May 28, 2004 7:19 PM
              Subject: [OLmws] Re: ADA (accessibility compliance) issues
               
              --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...> wrote:
              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.
               
              Bob,
               
              I described the situation for "IE v5 or higher with screen readers" because the most popular GUI screen reader is JAWS:
               
               
              which is geared toward IE and MS office productivity software.  The company's founder is blind, as are a substantial number of the employees, and getting the reader to work well is guided by much more than just profit motives.
               
               
              Netscape 7.1 (and all of the Gecko-engine browsers through the most current Mozilla nightly build) have a "clunkiness" problem such that they need extra time before we call OLplaceLayer() to have the page offset values be correct if the shift in focus via Tab or Shift-Tab also caused scrolling of the document.  One could impose a 1 msec timer-based delay as a workaround, as I have for dealing with Gecko-engine "clunkiness" problems associated with handling of WRAP.  But I haven't done that in this case because blind users would not normally confront that problem.  They would listen to (via the synthesizer) or palpate (via braille) the content of the currently "displayed": portion of the document.  Then they might Tab (to go forward) or Shift-Tab (to go back) through the anchors therein.  But they would PageDown or PageUp to access other portions of the document, and that Gecko-engine "clunkiness" problem would not become manifest.  If the Tab or Shift-Tab navigation were done to an extent that it also caused the scrolling, the audio or braille output could be confusing quite aside from the "clunkiness" problem.
               
              If anyone is still concerned about this, the default delay (ol_delay) can be configured (in the core or via OLpageDefaults) as 1 (msec) instead of 0, and that is more than enough to deal with the Gecko-engine browsers' "clunkiness" problem without otherwise causing detectable effects for any of the supported browsers.
               
               
              Opera7 supports Tab and Shift-Tab changes of focus only for form elements, and not also anchors.  For example, if you go to:
               
               
              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.
               
              In general, Opera is the richest of the "modern" browsers in offering keyboard shortcuts such that you can use the browser without a mouse, and has always promototed itself as best tuned in to accessibility issues.  But, of course, to use the keyboard shortcuts effectively one must first expend the time and effort to learn all of them.  The list is accessible (pun intended) via Ctrl+B or Help | Topics | Keyboard.
               
              Fote
              --
               
            • Foteos Macrides
              ... From: Foteos Macrides To: overlibmws@yahoogroups.com Sent: Saturday, May 29, 2004 12:58 PM Subject: Re: [OLmws] ADA (accessibility compliance) issues
              Message 6 of 7 , May 29, 2004
              • 0 Attachment
                ----- Original Message -----
                Sent: Saturday, May 29, 2004 12:58 PM
                Subject: Re: [OLmws] ADA (accessibility compliance) issues
                 
                <snip>
                Opera7 supports Tab and Shift-Tab changes of focus only for form elements, and not also anchors.  For example, if you go to:
                 
                 
                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.
                <snip>
                 
                I should have mentioned that Opera7 does support the tabindex attribute in the W3C standards:
                 
                 
                So, if you include it in any anchors, and/or in any area tags of image maps, then those anchors and/or areas will be included in the navigation via Tab and Shift+Tab with the order indicated by the tabindex attribute values.
                 
                Fote
                --
                 
              • 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 7 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...>
                  wrote:
                  > 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.
                  >
                  <snip>
                  >
                  > 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.
                  >
                  <snip>
                  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.