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

Re: [OLmws] Accessiblity question

Expand Messages
  • dave_rado
    ... the content of your DHTML popups depending on how (via which events) the popups are invoked and whether or not you do things such as those ... Thanks,
    Message 1 of 12 , Apr 14, 2008
    • 0 Attachment
      --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@...> wrote:

      > To answer your second question, screen readers may or may not read
      the content of your DHTML popups depending on how (via which events)
      the popups are invoked and whether or not you do things such as those
      discussed in the set of support documents beginning with:
      >
      > http://www.macridesweb.com/oltest/ONFOCUS.html

      Thanks, Fote. It seems from those pages that most of my pop-ups won't
      be accessible to screen readers at all, then, because as you know, for
      the most part I use images' and spans' mouseover events to trigger the
      overlib calls, rather than anchors. Am I right in surmising that only
      overlib calls associated with anchors (and form fields) can be made
      accessible to screen readers? If so, that's a great shame, but on
      balance, I think I'd prefer to continue to only use anchors for
      genuine hyperlinks, and to use the mouseover events of images and
      spans for when it isn't a genuine link. I had no idea though that
      doing this would have such a serious drawback to it.

      Dave
    • Foteos Macrides
      Dave, No, there is no technical impediment to making the DHTML popups invoked via span or div (or any other element) links accessible equivalently to anchors.
      Message 2 of 12 , Apr 14, 2008
      • 0 Attachment
        Dave,
         
        No, there is no technical impediment to making the DHTML popups invoked via span or div (or any other element) links accessible equivalently to anchors.  The anchor elements automatically are included into the document's tabbing order as the document is rendered during loading.  So you don't normally include tabindex attributes in them.  But if you have other kinds of links, you should include tabindex="#" in anchors, and in the other kinds of links with onmouseover popups, incrementing the number with the flow of the document.  Also assign all of them unique id's.  Then in addition to the overlib calls via onmouseover, specify overlib calls via onfocus and make those suitable for screen readers, using the id's for REF-based positioning (e.g., REF,'foo', REFC,'LR', REFP,'UL').  Those using a mouse will invoke the popups on hovering over the elements.  Those using a screen reader will hear them on tabbing to the elements' positions in the tabbing order.
         
        For non-STICKY popups, include onmouseout="nd()" and onblur="nd()"
         
        For STICKY popups, which include a Close link in the CAPTION and links in the main text area, getting those links included in the tabbing order is non-trivial, and I haven't come up with a way of doing it reliably across all of the otherwise supported browsers.  So the companion popups invoked via onfocus should not be STICKY (with onblur="nd()" included) and have alternative content, e.g., explaining how to access the dynamically loaded links in some other way (e.g., via a list of static links at the bottom of the document).
         
        The above is not all that difficult to do, but difficult enough such that sites which are not required to respect the ADA:
         
         
        typically don't do it. And many ADA-compliant sites instead provide alternative content via noscript blocks and expect users with screen readers to have javascript disabled.  Sigh . . . 
         
        Fote
        --
         
        ----- Original Message -----
        From: dave_rado
        Sent: Monday, April 14, 2008 8:26 PM
        Subject: Re: [OLmws] Accessiblity question
        Foteos Macrides wrote:
        To answer your second question, screen readers may or may not read the content of your DHTML popups depending on how (via which events) the popups are invoked and whether or not you do things such as those discussed in the set of support documents beginning with:

        http://www.macridesweb.com/oltest/ONFOCUS.html
        Thanks, Fote.  It seems from those pages that most of my pop-ups won't be accessible to screen readers at all, then, because as you know, for the most part I use images' and spans' mouseover events to trigger the overlib calls, rather than anchors.  Am I right in surmising that only overlib calls associated with anchors (and form fields) can be made accessible to screen readers?  If so, that's a great shame, but on balance, I think I'd prefer to continue to only use anchors for genuine hyperlinks, and to use the mouseover events of images and spans for when it isn't a genuine link.  I had no idea though that doing this would have such a serious drawback to it.

        Dave
      • dave_rado
        Hi Fote ... It s not only difficult, but would be such a massive amount of work, and such a maintenance nightmare, in the context of my site, that I m going to
        Message 3 of 12 , Apr 15, 2008
        • 0 Attachment
          Hi Fote

          > The above is not all that difficult to do, but difficult enough such
          that sites which are not required to respect the ADA:
          >
          > http://www.ada.gov/
          >
          > typically don't do it.

          It's not only difficult, but would be such a massive amount of work,
          and such a maintenance nightmare, in the context of my site, that I'm
          going to have to very reluctantly join those who don't do it.

          For really crucial pop-ups, I'll make them anchors linking to another
          page containing the pop-up text and the links within the pop-up text,
          and will partially hide the fact that they are anchors from ordinary
          users who have javascript enabled by making the mouse cursor an arrow
          rather than a hand (although unfortunately this brings up the hoary
          old chestnut of not being able to hide the status bar text).

          Thanks for the detailed and helpful explanation, though.

          Dave
        • dave_rado
          Also, re. ... overlib calls via onfocus and make those suitable for screen readers, using the id s for REF-based positioning (e.g., REF, foo , REFC, LR ,
          Message 4 of 12 , Apr 15, 2008
          • 0 Attachment
            Also, re.


            > Then in addition to the overlib calls via onmouseover, specify
            overlib calls via onfocus and make those suitable for screen readers,
            using the id's for REF-based positioning (e.g., REF,'foo', REFC,'LR',
            REFP,'UL').

            Are you saying that OFFSETX and OFFSETY won't work, and that I have to
            use REF-based equivalents for all of my anchor-based pop-ups or else
            screen readers won't be able to read them?

            Dave
          • Foteos Macrides
            Dave, If you only wish to offer alternative, accessible markup for critical pop-ups that strategy is not uncommon, but you might also consider the most
            Message 5 of 12 , Apr 15, 2008
            • 0 Attachment
              Dave,
               
              If you only wish to offer alternative, accessible markup for "critical pop-ups" that strategy is not uncommon, but you might also consider the most common strategy for sites which do seek to be accessible in a manner fully sanctioned by the ADA, which is to expect that users with screen readers turn off javascript for your site.  In that case, your non-anchor links would function as links only for those with javascript enabled, and you would associate each/any of them that have "critical pop-ups" with noscript blocks which contain the anchors for the alternative content.  The latter would not be rendered/displayed for those who have javascript enabled.  This also is a good thing to do if you want the popup content to be included in the indexing of your site by search engines, because they include the content of noscript blocks, but not the content of event-invoked DHTML popups.
               
              And for the other links which you do not consider to have "critical pop-ups" (typically those are tooltips), you can include title attributes whose values offer the equivalent content via system tooltips.  For those with screen readers, as well as for others who have javascript disabled, the onmouseover event-triggered displays of DHTML popups will not occur, and instead the title-based system tooltips can be read by sighted users or "spoken" for those using a contemporary screen reader.  As we've discussed before, in that case the onmouseover attribute value for making the overlib call should begin with this.title=''; to disable the system tooltip when javascript is enabled, and thus display only the DHTML popup with it's additional eye candy.
               
              Fote
              --
               
              ----- Original Message -----
              From: dave_rado
              Sent: Tuesday, April 15, 2008 7:11 AM
              Subject: Re: [OLmws] Accessiblity question
               
              Hi Fote
              The above is not all that difficult to do, but difficult enough such that sites which are not required to respect the ADA:
               
               
              typically don't do it.
              It's not only difficult, but would be such a massive amount of work, and such a maintenance nightmare, in the context of my site, that I'm going to have to very reluctantly join those who don't do it.

              For really crucial pop-ups, I'll make them anchors linking to another page containing the pop-up text and the links within the pop-up text, and will partially hide the fact that they are anchors from ordinary users who have javascript enabled by making the mouse cursor an arrow rather than a hand (although unfortunately this brings up the hoary old chestnut of not being able to hide the status bar text).

              Thanks for the detailed and helpful explanation, though.

              Dave
            • Foteos Macrides
              Dave, The OFFSETX and OFFSETY commands are cursor-based. They specify the X and Y offsets for the popup relative to the screen position of the cursor (based
              Message 6 of 12 , Apr 15, 2008
              • 0 Attachment
                Dave,
                 
                The OFFSETX and OFFSETY commands are cursor-based.  They specify the X and Y offsets for the popup relative to the "screen position of the cursor" (based on mouse movements -- the overlib code captures them and computes the appropriate coordinates for the screen position via an onmousemove event-handler) at the moment when the popup is invoked.
                 
                People using a screen reader are not using a mouse, and the so "screen position of the cursor" does not validly apply for them as for you.  Those using screen readers "navigate" the document via keyboard commands/shortcuts instead of via the mouse.  The keyboard tab is a command/shortcut to move focus to the next element in the order of elements with a default or overtly specified tabindex attribute value.  When an element receives focus, if javascript is enabled then either the onfocus or onclick event can be used to invoke a popup, and in your documents which use onmouseover for when a mouse is being used, it would be onfocus for when a screen reader is being used.
                 
                In the latter case, the "visual" positioning of the popup is irrelevant to someone who cannot see it and instead wants to hear the popup content, but the popup none-the-less needs to be associated with javascript positioning commands, and so you can use either REF-based ones (as I suggested with REFC and REFP commands chosen to position the popup at the equivalent of the BELOW, RIGHT defaults if cursor-based positioning were being used), or you can use frame/window-based positioning commands (e.g., REFX,0, REFY,0 for placing the popup at upper-left in the frame/window or MIDX,0, MIDY,0 for centering it).
                 
                Read the "Mouse-based versus Keyboard Navigation" section at bottom in the:
                 
                 
                support document and then try keyboard navigation in that and its associated set of support documents.  Keep in mind that someone using a screen reader typically is not "seeing" the positioning and visual display/hiding of the popups, as you can see during the keyboard navigation, but instead is depending on the screen reader to "speak" the popup content.  Also note that the keyboard navigation begins in the chrome, not the document, so that potentially import information like the URL in the address bar, various buttons, the search bar, etc., also can be accessed via contemporary "screen" readers.
                 
                Fote
                --
                 
                ----- Original Message -----
                From: dave_rado
                Sent: Tuesday, April 15, 2008 7:50 AM
                Subject: Re: [OLmws] Accessiblity question
                 
                Also, re.
                Then in addition to the overlib calls via onmouseover, specify overlib calls via onfocus and make those suitable for screen readers, using the id's for REF-based positioning (e.g., REF,'foo', REFC,'LR', REFP,'UL').
                Are you saying that OFFSETX and OFFSETY won't work, and that I have to use REF-based equivalents for all of my anchor-based pop-ups or else screen readers won't be able to read them?

                Dave
              • Foteos Macrides
                Dave, Just to be sure this is clear, here s a shorter answer to your question: You can leave the onmouseover-based overlib calls in your documents with their
                Message 7 of 12 , Apr 15, 2008
                • 0 Attachment
                  Dave,
                   
                  Just to be sure this is clear, here's a shorter answer to your question:
                   
                  You can leave the onmouseover-based overlib calls in your documents with their cursor-based positioning commands exactly as they presently are.  But if you add complementary onfocus-based overlib calls for users with screen readers, the latter should use REF-based or frame/window-based positioning commands.
                   
                  Fote
                  --
                   
                  ----- Original Message -----
                  Sent: Tuesday, April 15, 2008 12:54 PM
                  Subject: Re: [OLmws] Accessiblity question

                  Dave,
                   
                  The OFFSETX and OFFSETY commands are cursor-based.  They specify the X and Y offsets for the popup relative to the "screen position of the cursor" (based on mouse movements -- the overlib code captures them and computes the appropriate coordinates for the screen position via an onmousemove event-handler) at the moment when the popup is invoked.
                   
                  People using a screen reader are not using a mouse, and so the "screen position of the cursor" does not validly apply for them as for you.  Those using screen readers "navigate" the document via keyboard commands/shortcuts instead of via the mouse.  The keyboard tab is a command/shortcut to move focus to the next element in the order of elements with a default or overtly specified tabindex attribute value.  When an element receives focus, if javascript is enabled then either the onfocus or onclick event can be used to invoke a popup, and in your documents which use onmouseover for when a mouse is being used, it would be onfocus for when a screen reader is being used.
                   
                  In the latter case, the "visual" positioning of the popup is irrelevant to someone who cannot see it and instead wants to hear the popup content, but the popup none-the-less needs to be associated with javascript positioning commands, and so you can use either REF-based ones (as I suggested with REFC and REFP commands chosen to position the popup at the equivalent of the BELOW, RIGHT defaults if cursor-based positioning were being used), or you can use frame/window-based positioning commands (e.g., REFX,0, REFY,0 for placing the popup at upper-left in the frame/window or MIDX,0, MIDY,0 for centering it).
                   
                  Read the "Mouse-based versus Keyboard Navigation" section at bottom in the:
                   
                   
                  support document and then try keyboard navigation in that and its associated set of support documents.  Keep in mind that someone using a screen reader typically is not "seeing" the positioning and visual display/hiding of the popups, as you can see during the keyboard navigation, but instead is depending on the screen reader to "speak" the popup content.  Also note that the keyboard navigation begins in the chrome, not the document, so that potentially import information like the URL in the address bar, various buttons, the search bar, etc., also can be accessed via contemporary "screen" readers.
                   
                  Fote
                  --
                   
                  ----- Original Message -----
                  From: dave_rado
                  Sent: Tuesday, April 15, 2008 7:50 AM
                  Subject: Re: [OLmws] Accessiblity question
                   
                  Also, re.
                  Then in addition to the overlib calls via onmouseover, specify overlib calls via onfocus and make those suitable for screen readers, using the id's for REF-based positioning (e.g., REF,'foo', REFC,'LR', REFP,'UL').
                  Are you saying that OFFSETX and OFFSETY won't work, and that I have to use REF-based equivalents for all of my anchor-based pop-ups or else screen readers won't be able to read them?

                  Dave
                • dave_rado
                  Hi Fote ... critical pop-ups that strategy is not uncommon, but you might also consider the most common strategy for sites which do seek to be accessible in
                  Message 8 of 12 , May 4, 2008
                  • 0 Attachment
                    Hi Fote

                    --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@...> wrote:
                    >
                    > Dave,
                    >
                    > If you only wish to offer alternative, accessible markup for
                    "critical pop-ups" that strategy is not uncommon, but you might also
                    consider the most common strategy for sites which do seek to be
                    accessible in a manner fully sanctioned by the ADA, which is to expect
                    that users with screen readers turn off javascript for your site. In
                    that case, your non-anchor links would function as links only for
                    those with javascript enabled, and you would associate each/any of
                    them that have "critical pop-ups" with noscript blocks which contain
                    the anchors for the alternative content. The latter would not be
                    rendered/displayed for those who have javascript enabled. This also
                    is a good thing to do if you want the popup content to be included in
                    the indexing of your site by search engines, because they include the
                    content of noscript blocks, but not the content of event-invoked DHTML
                    popups.
                    >
                    > And for the other links which you do not consider to have "critical
                    pop-ups" (typically those are tooltips), you can include title
                    attributes whose values offer the equivalent content via system
                    tooltips. For those with screen readers, as well as for others who
                    have javascript disabled, the onmouseover event-triggered displays of
                    DHTML popups will not occur, and instead the title-based system
                    tooltips can be read by sighted users or "spoken" for those using a
                    contemporary screen reader. As we've discussed before, in that case
                    the onmouseover attribute value for making the overlib call should
                    begin with this.title=''; to disable the system tooltip when
                    javascript is enabled, and thus display only the DHTML popup with it's
                    additional eye candy.

                    ---------------------

                    Using a combination of variations on some of your suggestions and the
                    method I described previously, I have now made all the pop-ups on the
                    site I'm developing accessible.

                    1) The majority of my pop-ups are functionally equivalent to inline
                    footnotes, so for those I used a variation on your <noscript> idea. I
                    found two problems with using the <noscript> tag itself: first that it
                    can't be used inline (or at least, it doesn't verify if it is); and
                    the other was that what determines whether the <noscript> text prints
                    or not is whether the user has javascript enabled or not, whereas I
                    want it to print, or to not print, depending on the type of pop-up it
                    is, and regardless of whether or not the user happens to have
                    javascript enabled. So instead, in an imported js file I have:

                    document.write('<style type="text/css"
                    media="screen">.NoScriptPrintText {display: none}</style>'
                    +'<style type="text/css">.NoScriptNoPrintText {display:
                    none}</style>');

                    and in my PrintStyles.css file I have:

                    .NoScriptNoPrintText {display: none}

                    ... and so in my html, I can use either span.NoScriptPrintText or
                    div.NoScriptPrintText, for when I want the noscript text to be
                    printed, and either span.NoScriptNoPrintText or
                    div.NoScriptNoPrintText for when I don't want it to be printed.

                    For this type of pop-up I've set the title to say "See the note in
                    green text below" or "See the note in green on the right", depending
                    on whether it's a div or a span; and I've also encased these noscript
                    notes in square brackets and given them a smaller font size than the
                    surrounding text.

                    2) Where it's not practical for the noscript text to be next to or
                    below the text or graphic that has a pop-up associated with it, I've
                    made the text or graphic into an anchor that links to a separate
                    document containing the pop-up text; and I've hidden the fact it's an
                    anchor from users with javascript enabled by setting the cursor to
                    'default' (combined with STATUS, ' ' for those browsers that support it).

                    3) In the few cases where the pop-up text is short enough to be
                    contained in a title without being truncated by Firefox and without
                    being displayed for too short a time by IE for it to be readable; and
                    where there is also no benefit in the pop-up text being printed; I
                    have set the title to be the same as the overlib text.

                    So between those three methods, as I say, the whole site
                    (incorporating several hundred pop-ups) is accessible now.

                    All three methods can be seen in my mockup at http://tinyurl.com/28mcte.

                    Many thanks for your help in pointing me in the right direction.

                    Dave
                  • Foteos Macrides
                    Dave, That s quite clever, and I m sure will be appreciated by those with accessibility issues. Thanks for sharing and clearly explaining it. Fote -- ...
                    Message 9 of 12 , May 4, 2008
                    • 0 Attachment
                      Dave,
                       
                      That's quite clever, and I'm sure will be appreciated by those with accessibility issues.  Thanks for sharing and clearly explaining it.
                       
                      Fote
                      --
                       
                      ----- Original Message -----
                      From: dave_rado
                      Sent: Sunday, May 04, 2008 3:40 PM
                      Subject: Re: [OLmws] Accessiblity question

                      Hi Fote

                      --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@...> wrote:
                      >
                      > Dave,
                      >
                      > If you only wish to offer alternative, accessible markup for "critical pop-ups" that strategy is not uncommon, but you might also consider the most common strategy for sites which do seek to be accessible in a manner fully sanctioned by the ADA, which is to expect that users with screen readers turn off javascript for your site.  In that case, your non-anchor links would function as links only for those with javascript enabled, and you would associate each/any of them that have "critical pop-ups" with noscript blocks which contain the anchors for the alternative content.  The latter would not be rendered/displayed for those who have javascript enabled.  This also is a good thing to do if you want the popup content to be included in the indexing of your site by search engines, because they include the content of noscript blocks, but not the content of event-invoked DHTML popups.
                      >
                      > And for the other links which you do not consider to have "critical pop-ups" (typically those are tooltips), you can include title attributes whose values offer the equivalent content via system tooltips.  For those with screen readers, as well as for others who have javascript disabled, the onmouseover event-triggered displays of DHTML popups will not occur, and instead the title-based system tooltips can be read by sighted users or "spoken" for those using a contemporary screen reader.  As we've discussed before, in that case the onmouseover attribute value for making the overlib call should begin with this.title=''; to disable the system tooltip when javascript is enabled, and thus display only the DHTML popup with it's additional eye candy.

                      ---------------------

                      Using a combination of variations on some of your suggestions and the method I described previously, I have now made all the pop-ups on the site I'm developing accessible.

                      1) The majority of my pop-ups are functionally equivalent to inline footnotes, so for those I used a variation on your <noscript> idea. I found two problems with using the <noscript> tag itself: first that it can't be used inline (or at least, it doesn't verify if it is); and the other was that what determines whether the <noscript> text prints or not is whether the user has javascript enabled or not, whereas I want it to print, or to not print, depending on the type of pop-up it is, and regardless of whether or not the user happens to have javascript enabled. So instead, in an imported js file I have:

                      document.write('<style type="text/css"
                      media="screen">.NoScriptPrintText {display: none}</style>'
                       +'<style type="text/css">.NoScriptNoPrintText {display: none}</style>');

                      and in my PrintStyles.css file I have:

                      .NoScriptNoPrintText {display: none}

                      ... and so in my html, I can use either span.NoScriptPrintText or div.NoScriptPrintText, for when I want the noscript text to be printed, and either span.NoScriptNoPrintText or div.NoScriptNoPrintText for when I don't want it to be printed.

                      For this type of pop-up I've set the title to say "See the note in green text below" or "See the note in green on the right", depending on whether it's a div or a span; and I've also encased these noscript notes in square brackets and given them a smaller font size than the surrounding text.

                      2) Where it's not practical for the noscript text to be next to or below the text or graphic that has a pop-up associated with it, I've made the text or graphic into an anchor that links to a separate document containing the pop-up text; and I've hidden the fact it's an anchor from users with javascript enabled by setting the cursor to 'default' (combined with STATUS, ' ' for those browsers that support it).

                      3) In the few cases where the pop-up text is short enough to be contained in a title without being truncated by Firefox and without being displayed for too short a time by IE for it to be readable; and where there is also no benefit in the pop-up text being printed; I have set the title to be the same as the overlib text.

                      So between those three methods, as I say, the whole site (incorporating several hundred pop-ups) is accessible now.

                      All three methods can be seen in my mockup at http://tinyurl.com/28mcte.

                      Many thanks for your help in pointing me in the right direction.

                      Dave
                    • dave_rado
                      Hi Fote Sorry about the delay in replying - I got sidetracked by a high priority deadline again. ... Not entirely my idea - I based it on the idea at
                      Message 10 of 12 , May 11, 2008
                      • 0 Attachment
                        Hi Fote

                        Sorry about the delay in replying - I got sidetracked by a high
                        priority deadline again.

                        --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@...> wrote:

                        > That's quite clever

                        Not entirely my idea - I based it on the idea at
                        http://tinyurl.com/6elw4r , although the print-specific bits were my
                        own idea.

                        > and I'm sure will be appreciated by those with accessibility issues.
                        Thanks for sharing and clearly explaining it.

                        You're welcome - many thanks again for setting me on the right track.

                        Dave
                      Your message has been successfully submitted and would be delivered to recipients shortly.