[Athen] Jaws and javascript links

[Sean Keegan]

Hi Stacy,

Okay - if you *must* retain the current look/presentation model, then you
may want to try the Ultimate Drop-Down menu (http://www.udm4.com) by
Brothercake.  It provides an accessible drop-down/flyout menu structure
coded using CSS, javascript, and semantic HTML.  Another one is YADM (Yet
Another Dynamic Menu - http://www.onlinetools.org/tools/yadm/ ).  Probably
the best options if you *must* retain the look/presentation model of
drop-down/flyout menus.

At the very least, the sub-menu links should be replicated on the
second-tier page.  In other words, if the user clicked on "Content", then
the page returned should have all the sub-menu items on that "Content" page.
Not the best solution, but an option.

Ideally, Javascript should be used to enhance the experience - not limit the
interaction by the user.  Setting up a menu structure using semantic HTML
(headings, lists, etc.) and then applying javascript is a better option.
Terry T. asked about delivering the links via HTML instead of javascript -
is there anyway to customize the interface from the user's perspective to
choose between a javascripted and non-javascripted user interface?


> The developers (while they do very much care about accessibility) 

> evidently thought that since the *text* was present on the page, the 

> reader would "read" that text and the user would recognize it as a 

> link.  They didn't realize that the user most likely wouldn't navigate

that way.

It depends on how this is done.  However, in the method you are describing
it does not sound like the method used to implement the menu content is
accessible.  Without seeing the code, I cannot be more helpful.

Things to consider, however:

- individuals using magnification software (when zoomed into the page, it
can be hard to "see" where the actual menu options are as they may open
outside of the field of view).

- those using speech recognition software to manipulate the mouse.  A
problem with drop-down/flyout menus is that if you are using the mouse to
hover and the mouse moves off the "hover" area, the user must begin again -
very frustrating if you are controlling everything by voice.

- those using PDA-style browsers.  Many PDAs have problems with Javascript,
so navigating that menu structure can be problematic.  You may not have
anyone checking pages with a PDA right now, but this is going to be an issue
down the road.  Developing to standards now makes forward compatibility much
easier in the long run.

- as Ron S. mentioned earlier, can you duplicate this problem with any other
assistive technology (e.g, Window-Eyes/Supernova, etc.)?  I have found some
issues that I assumed were errors by a Web developer only to check other
assistive technology and learn that the error was with how JAWS interprets
the page.  Other assistive technology worked just fine with how the page was
coded - just not JAWS.  There have been times when perfectly valid HTML code
will not be read by JAWS - and the problem was (is) with JAWS, NOT the code
(developers find this..."frustrating" <grin>).


Take care,
Sean


-----Original Message-----
From: Stacy L. Smith [mailto:stacylee at ksu.edu]
Sent: Monday, December 04, 2006 1:06 PM
To: skeegan at htctu.net; Access Technologists in Higher Education Network
Subject: Re: [Athen] Jaws and javascript links

Sean (and anyone else who has information on this!)

When a student opens a course page in our LMS, he or she is presented with
main level links that, onMouseOver, open other lists of links. 
The main level links are recognized by JAWS.

The second level links are a mix of some HTML links and some JavaScript
links.  For example, when I mouse over the main level link, "Content,"
I get a list that contains the Calendar.  When I mouse over the calendar
link, the browser tells me that it's sending me to "javascript:openCal();".

If the user instead clicks on "Content," a new content page loads, with all
of the same sections and same links.  The problem is that the links in this
new content window are the same javascript links, and they aren't read,
either.

The developers (while they do very much care about accessibility) evidently
thought that since the *text* was present on the page, the reader would
"read" that text and the user would recognize it as a link.  They didn't
realize that the user most likely wouldn't navigate that way.

I'm really new to this, and I know next to zilch about javascript, so
anything you can tell me to pass along to the designers would be most
helpful.

THANKS!

Stacy

Quoting Sean Keegan <skeegan at htctu.net>:


> Hi Stacy,

>

> I suppose I am a bit unsure of what you are asking.  Are the 

> javascript links you are describing part of a drop-down menu 

> structure?  In other words, when you hover over the main navigation 

> heading, additional hyperlinks are revealed?

>

> Thanks,

> Sean

>

> Sean Keegan

> Web Accessibility Instructor

> High Tech Center Training Unit of the California Community Colleges

>

> -----Original Message-----

> From: athen-bounces at athenpro.org [mailto:athen-bounces at athenpro.org]

> On

> Behalf Of Stacy L. Smith

> Sent: Friday, December 01, 2006 9:16 AM

> To: Access Technologists in Higher Education Network

> Subject: [Athen] Jaws and javascript links

>

> This message is for those of you famliar with Jaws - HTML 

> interactions.

>

> K-State uses a homegrown learning management system, which has a very 

> robust user interface.  A couple of semesters ago they changed the 

> main level navigation to where some links are HTML and some are 

> Javascript.

> I just found out from a user this morning that he can't see what turns 

> out to be the javascript links.  THe design team assumed that Jaws 

> would read the text on the screen and didn't realize that the user may 

> not be navigating that way (and is instead navigating by looking for 

> links).

>

> The design and programming crew is VERY interested in accessibility 

> and wants very much to fix this problem.  We have a new release coming 

> out in early January, and it's possible we could fix this problem by 

> then.

> We just need to know how to do that without sacrificing the look and 

> feel of the page for sighted users.

>

> Does anyone have any experience or ideas to share?  For example, we 

> wondered if there might be a name or value attribute that the reader 

> might pick up, or perhaps some other very clever solution.

>

> I'm looking forward to your thoughts.

>

> Thanks,

> Stacy

>

>

> Stacy Smith

> Adaptive Technology Specialist, Disability Support Services

> 532-6441

> stacylee at ksu.edu

>

> ~~~~~~~~~~~~

>

> One does not need buildings, money, power, or status to practice the 

> Art of Peace. Heaven is right where you are standing, and that is the 

> place to train.

>

> --Morehei Ueshiba

>

> _______________________________________________

> Athen mailing list

> Athen at athenpro.org

> http://athenpro.org/mailman/listinfo/athen_athenpro.org

>

>

>

> _______________________________________________

> Athen mailing list

> Athen at athenpro.org

> http://athenpro.org/mailman/listinfo/athen_athenpro.org

>

>



Stacy Smith
Adaptive Technology Specialist, Disability Support Services
532-6441
stacylee at ksu.edu

~~~~~~~~~~~~

One does not need buildings, money, power, or status to practice the Art of
Peace. Heaven is right where you are standing, and that is the place to
train.

--Morehei Ueshiba