- From: gregory j. rosmaita <oedipus@hicom.net>
- Date: Tue, 4 Sep 2001 15:29:33 -0400
- To: <w3c-wai-ig@w3.org>
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