Re: Accessibility and Pop-Up Ads

aloha!

pop-up ads rely upon javascript to "pop up" OnLoad - that is, when the
requested document is parsed by the user agent...  since the "pop up" is
part of the user interface, if a site employing pop-up ads claims
conformance to WCAG, then the markup employed in pop-up adds are also
subject to WCAG, while control over the popping is addressed by the User
Agent Accessibility Guidelines (UAAG)

no matter the source of the content that pops up, if the site which utilizes
pop-up ads does not ensure that the pop ups are WCAG compliant, then that
site, or the document to which the OnLoad event that causes a new viewport
to be generated is attached (if the claim is document-specific) cannot be
considered WCAG compliant...  for starters, pop-up ads are not rendered by
non-javascript-aware browsers, such as lynx, which means that some users do
not have access to all of the content on the page/site -- regardless of
whether that content is useful...

moreover, as david p has pointed out, turning off scripting in order to
suppress the generation of pop-up ads is far too draconian a solution --
akin to prescribing decapitation as the cure for acne...  therefore, the
User Agent Accessibility Guidelines (UAAG) stipulates that users should be
able to configure their browser so that pop-up ads are either (a) allowed to
pop-up; (b) they are prompted that the document wants to open a new browser
instance and given the choice of allowing the new viewport to be spawned or
suppressing the event; or (c) suppressed altogether [reference 1]

the aspect of the pop-up add phenomenon which disturbs me the most is a
trend which has, over the course of the year, been transformed from a
trickle into a deluge... i'm speaking of pop-up windows that are generated
OnLoad which contain only an image -- while some also contain either a
"Close This Window" hyperlink or (more common) a "Close" button, almost
without exception, when ALT text has been defined for the image, it is of
the "Click Here" variety, as the intent of the pop-up window is to (a) catch
the attention of the user, (b) lead the user to another portion of the site
in a new instance of whatever browser is being used, so that the page that
the user explicitly requested remains available in another viewport...

i know that this is an issue that the GL working group (which is responsible
for WCAG) has addressed (and re-examined) several times in the past (i
remember, in particular, a thread from 1999 on the topic), and the consensus
has always been that one should not link directly to an image, but to an
image placed inside an appropriate wrapper -- one encoded using the same
markup language used by the document from which the new viewport was
spawned, and which utilizes all appropriate "accessibility" markup defined
for that language, but i think that the conformance or scope section of
WCAG2 must stress that -- no matter the source of the content -- any
advertising yanked into a site from a third-party provider MUST be WCAG
compliant...

gregory

Reference 1: the latest version of the User Agent Accessibility Guidelines
is dated 31 august 2001 (this is the draft which has been submitted to the
director of the W3C so that UAAG can advance to Candidate Recommendation
(CR) status)
http://www.w3.org/WAI/UA/WD-UAAG10-20010831/

the specific portions of UAAG are contained in Guideline 5: "Ensure User
Control of user interface behavior" -- in particular, checkpoints 5.1
through 5.4, which are reproduced below, along with the introductory text
for UAAG-GL5:

<quote

href="http://www.w3.org/WAI/UA/UAAG10/guidelines.html#gl-user-control-ui">
    Ensure that the user can control the behavior of viewports and other
user
    interface controls, including those that may be manipulated by the
author
    (e.g., through scripts).

   Control of viewport behavior is important to accessibility. For people
   with visual disabilities or certain types of learning disabilities, it
   is important that the point of regard - what the user is presumed to
   be viewing - remain as stable as possible. Unexpected changes may
   cause users to lose track of how many viewports are open, which
   viewport has the current focus, etc. This guideline includes
   requirements for control of opening and closing viewports, the
   relative position of graphical viewports, changes to focus, and
   inadvertent form submissions and micropayments.

 Checkpoints

  5.1 No automatic content focus change. (P2)

    1. Allow configuration so that if a viewport opens without explicit
       user request, its content focus does not automatically become the
       current focus.
    2. Configuration is preferred, but is not required if the content
       focus can only ever be moved on explicit user request.

  5.2 Keep viewport on top. (P2)

    1. For graphical user interfaces, allow configuration so that the
       viewport with the current focus remains "on top" of all other
       viewports with which it overlaps.

  5.3 Manual viewport open only. (P2)

    1. Allow configuration so that viewports only open on explicit user
       request.
    2. In this configuration, instead of opening a viewport
       automatically, alert the user and allow the user to open it on
       demand (e.g., by following a link or confirming a prompt).
    3. Allow the user to close viewports.
    4. If a viewport (e.g., a frame set) contains other viewports, these
       requirements only apply to the outermost container viewport.
    5. Configuration is preferred, but is not required if viewports can
       only ever open on explicit user request.
    6. User creation of a new viewport (e.g., empty or with a new
       resource loaded) through the user agent's user interface
       constitutes an explicit user request.

   Note: Generally, viewports open automatically as the result of
   instructions in content. See also checkpoint 5.1 (for control over
   changes of focus when a viewport opens) and checkpoint 6.5 (for
   programmatic alert of changes to the user interface).

  5.4 Selection and focus in viewport. (P2)

    1. Ensure that when a viewport's selection or content focus changes,
       it is at least partially in the viewport after the change.

   Note: For example, if users navigating links move to a portion of the
   document outside a graphical viewport, the viewport should scroll to
   include the new location of the focus. Or, for users of audio
   viewports, allow configuration to render the selection or focus
   immediately after the change.
<quote>

Received on Tuesday, 4 September 2001 15:28:58 UTC