Primary Navigation

Re: [OLmws] Accessiblity question

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 1 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:

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:

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 2 of 12
, Apr 15, 2008

0 Attachment

Hi Fote

> The above is not all that difficult to do, but difficult enough such

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).

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 4 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.

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 5 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).

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.

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 6 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.

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).

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.

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 7 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:

... 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.

--- 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:

... 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.