W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2002

RE: Pop-Ups

From: John Foliot - bytown internet <foliot@bytowninternet.com>
Date: Fri, 18 Oct 2002 09:33:49 -0400
To: "Peacock, Kimberly" <peacockk@ctcgsc.org>, <w3c-wai-ig@w3.org>
Message-ID: <GKEFJJEKDDIMBHJOGLENIEOFCMAA.foliot@bytowninternet.com>

Earlier this year some associates and I looked at fufilling an RFP for an
eLearning solution which was both SCORM compliant as well as being totally
accessible (well actually WCAG Priority 1 & 2 compliant).  After much
research and considerable thought and discussion we determined that at this
time delivering the request with the current crop of COTS tools is simply
not possible... not only does the current implementations require Pop-ups,
but JavaScript as well - two "silver bullets" in terms of accessibility.

With all due respect Kimberly, these systems are broken.  Popup windows will
never be totally accessible, there are too many configuration options which
negate this possibility; the same too with JavaScript - there are numerous
reasons why a person would be using a device which does not support JS.  In
both instances, this is not about disabilities, but rather about user choice
in determining which user agent they will employ to access your content -
something that is often overlooked in Accessibility discussions: this is
more than making web sites for blind people!

What concerns me the most is that 99 times out of 100 there are alternative
solutions which developers can emply which will deliver similar or identical
functionality, yet not require the end users system set up to match a
certain profile - just about everything *important* that you might do with
JavaScript can be done with a server side script.  Using a combination of
server include and session tracking (cookies?) can provide almost identical
functionality to the end user as having a "popup" open and close... after
all the main reason (especially in the situation you illustrate) is to keep
a user session open.

You mention that often Powerpoint, Word, embeded applications etc. are also
employed into these "solutions".  If any of these "alternative" content
components require a helper application then it becomes, "...is there a
helper application available for every given user platform?"  What happens
if the end user does not have Powerpoint installed?  Too Bad So Sad, go
away?  How is that valuable or accessible?  Besides, in my experience,
Powerpoint presentations *usually* require a "voice" to explain the
"slides" - it is rare that all relevant information is included into the
slide - more often it is bullet points or eye candy to be used in
conjunction with a narrative.  Thowing that into an eLearning application
does a disservice to the end user - again here the accessibilty issue is
more about requiring installed software rather than the content being served
up.

So rather than rail against the browser for not doing what you want, the
blame should be focused on the LMS developers who take shortcuts and build
sloppy or non-accessible frameworks for the eLearning solution you wish to
develop.  They, not the browser manufacturers, need to take a look at what
they are doing.

As always, just my $0.02

JF

>
>
>
>
> Alot of the problem has to do with the Learning Management System (LMS)
> software, and the rest of it has to do with the military client and
> developers.  The goal of the LMS software is to track student
> completion and
> interactivity throughout their eLearning experience.  I'm not sure if you
> are familiar with SCORM (www.adlnet.org) or not, but I will just
> proceed as
> though you are and you can write me back with additional questions if
> needed.  Currently LMS systems are built to the SCORM 1.2 standard.  SCORM
> 1.3 is expected to be made available as a public draft within the next few
> months.  The difference between the two primarily has to do with the
> sequencing of the learning objects.  At the moment under SCORM 1.2 this
> sequencing is not possible, and as a result MOST (not all) of the LMSs
> function like this:
>
> - the main window (LMS GUI window) remains open
> - the user selects a topic of instruction
> - that topic opens in a new window
> - user finishes the training object and closes it
> - then selects another topic
>
> Additionally, the topic's themselves contain pop-ups/new windows.  This
> occurs for various reasons:  separate testing sections, special
> interactivity that calls some kind of plug-in, special document
> formats, and
> sometimes just bad developer design that reflects a lack of
> sensitivity for
> accessibility.  Keep in mind also that a wide variety of tools are usually
> implemented in these types of products:  all of Macromedia's products
> (Authorware, Director, Flash, etc.), Photoshop, 3-D graphics programs,
> video, audio, embedded screen readers, PDF and Word document formats, as
> well as PowerPoint presentations.  Often times these are embedded
> within the
> training, linked to and embedded in various ways, etc.  Most of these
> products are not coded strictly in HTML!  I think that the importance here
> is that on-line training is becoming a huge industry, with
> Universities and
> the government expanding these services at an incredible rate,
> and these are
> among the primary tools they use.
>
> My hope is that once the LMS developers incorporate SCORM 1.3 into their
> products this will be improved, however I expect the need for the
> pop-up/new
> window to be around in the training arena for quite a long time.  So, my
> personal opinion is that if you can't beat them join them, but
> improve them
> while your with them.  I would like to see pop-up/new window code that
> allowed for accessibility.  I would then like to see browsers then give
> users the option of disabling any pop-up/new window that did not
> meet those
> standards.
>
> Or at least those are my thoughts on the subject at the moment.  I see far
> too many of my colleagues choosing to ignore accessibility entirely just
> because they can only partially implement it.  I would like to see that
> practice stopped.
>
> Respectfully,
> Kimberly Peacock
> Multimedia Programmer
>
> Pensacola, Florida
>
>
> -----Original Message-----
> From: Jon Hanna [mailto:jon@spin.ie]
> Sent: Thursday, October 17, 2002 1:18 PM
> To: Peacock, Kimberly
> Subject: RE: Pop-Ups
>
>
> it is an
> > unfortunate fact of
> > our lives that due to Learning Management System constrictions,
> etc. a new
> > window is often required.
>
> How?
>
Received on Friday, 18 October 2002 09:34:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:14:07 GMT