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

RE: Pop-Ups

From: Peacock, Kimberly <peacockk@ctcgsc.org>
Date: Fri, 18 Oct 2002 09:16:39 -0500
Message-ID: <5A69399A2BB6504B9193F0A1660A5CF903291D@pefl-mail1.pefl.ctcgsc.org>
To: "'w3c-wai-ig@w3.org'" <w3c-wai-ig@w3.org>

Not at all, I think my intent did not get communicated efficiently if you
thought that I was implying that the problem resides with browsers.  I
completely agree with you about the fact that accessibility is lacking and
in no way meant to imply that those systems are fully accessible.  My point
was simply to provide a real world scenario in which pop-ups/new windows are
completely unavoidable (at least given current technologies).  I understand
that it is the goal of this organization to remain focused on the utopian
aspects of accessibility and what it "should be".  But I don't think we
should loose site of where it is at the moment and the tools developers
currently have at their disposal in which to "make it happen".

The people who purchase/approve contracts for the development of training
software all too often know that accessibility standards exist but have no
real idea of what they are or how realistic they are to implement.  As
supported by the existence of the RFP you mentioned.  This results in
contracts where the client is putting out a request for proposals/bids and
the contract mandates that it be fully accessible.

My post resulted from reading so many posts that were wanting to ignore/wish
away/abolish pop-up windows instead of addressing them to see if there could
be an accessible way of constructing them, making that the standard, and
then trying to get browsers to implement a solution that would allow users
to choose to ignore all pop-ups that did not meet that standard.  Besides
let's face it, do you really believe those ads we all hate so much will ever
go away now that they are here.

Some discussion has already centered around tagging or otherwise identifying
sites that conform to the accessibility standards, why not apply this to
pop-ups as well?  My commentary is only to suggest that instead of throwing
it out because it's broken let's fix it (I realize not all pop-ups, but just
perhaps offering a way to build them that is accessible - even if it limits
capabilities).  I know that the W3C as a whole has alot to do with the
acceptance of HTML and Scripting standards, and perhaps this is something
other working groups within the W3C would be better suited to deal with, but
I don't feel it is something we should just turn our heads to, or attempt to
write out of existence by simply saying "absolutely no, for all time do not
use them."  Because then an entire and very important sector responsible for
developing web content will be forced to say "well we can't conform so let's
just ignore it completely".  I really don't want that.  I feel accessibility
is making wonderful progress, I just want to see that happen in all sectors
as much as possible.

Kimberly Peacock

-----Original Message-----
From: John Foliot - bytown internet [mailto:foliot@bytowninternet.com]
Sent: Friday, October 18, 2002 8:34 AM
To: Peacock, Kimberly; w3c-wai-ig@w3.org
Subject: RE: Pop-Ups

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

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


> 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 10:16:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:20 UTC