Web Applications Working Group deliverables

I've added some preliminary comments for each of the bullet items we'd included on the Wiki page (https://www.w3.org/WAI/UA/work/wiki/Comments_on_Web_Applications_Working_Group_Charter) describing possible issues or areas of concern.

  * DOM Level 3 Events

        Events and DOM partitioning could affect AT that hooks into the DOM for presenting info to the user, manipulating the document or its presentation for the user's benefit, or manipulates the document at the user's request. It is not yet clear whether the proposed API will have these effects. 

  * UI Events

        UI Events currently address changes to focus, as well as input from mouse, wheel, and keyboard devices. Should it also address other input methods, such as those from speech recognition and switch devices? 

  * Fullscreen API

        Several types of AT need to reserve portions of the screen for their own use (e.g. screen magnifiers, on-screen keyboards, text chat utilities), and these may have have problems working with full-screen applications unless a mechanism allows them to cooperate with each other. 

  * Input Method (IME) API ?

        An IME could be implemented in a way that is incompatible with AT that simulates user input (e.g. speech recognition or on-screen keyboard utilities). It is not yet clear whether the proposed API would have any bearing on this. 

  * Pointer Lock

        Users who rely on some forms of AT must move the pointer in order to explore the screen contents, or to manipulate controls outside of the active window (e.g. screen magnifiers and on-screen keyboards, respectively). Constraining pointer location would be entirely incompatible with these utilities. The proposed API must provide a means for AT to block this functionality, and web apps must be written so that they can have fallback behaviors when the function is disabled. 

        Pointer locking may be incompatible with some absolute-positioning input devices, such as eye-gaze tracking. 

        Constraining pointer movement could have disastrous results when used with some relative motion input devices, unless care is taken in its implementation. For example, Tom is quadriplegic and uses a head tracking device. He moves his head 15 degrees to the right so that he's facing the right edge of the screen, and the pointer should move there as well. However, the application has the pointer locked to the left half of the screen, so it does not move. From now on the pointer may remain 15 degrees left of where Tom is pointing. Even after the pointer is unlocked, he may not be able to turn his head far enough to the right to bring the pointer to the right edge of the screen. 

  * Screen Orientation API

        Some users may have the physical device constrained to a particular orientation, such as when it is affixed to their wheelchair or when they need to hold the device using a particular grip. They need to be able to tell the platform and browser to prevent the orientation from changing, and thus block any attempts by web apps to change the orientation. 

  * Custom Elements

        Custom elements will affect AT that hooks into the DOM for presenting info to the user, manipulating the document or its presentation for the user's benefit, or manipulates the document at the user's request. For example, a screen reader would need to know how to describe the element, its purpose, and its visual appearance to a blind user, while a speech recognition utility would need to know how to manipulate it on the user's behalf and how to describe available actions to the user. 

  * HTML Templates ?

        DOM partitioning could affect AT that hooks into the DOM for presenting info to the user, manipulating the document or its presentation for the user's benefit, or manipulates the document at the user's request. It is not yet clear whether the proposed API will have these effects. 

  * Shadow DOM ?

        DOM partitioning could affect AT that hooks into the DOM for presenting info to the user, manipulating the document or its presentation for the user's benefit, or manipulates the document at the user's request. It is not yet clear whether the proposed API will have these effects. 

  * Web Components Introduction

        Training materials should guide developers towards creating accessible products, both actively (e.g. by discussing the importance of accessible design and specific steps that should be taken) and passively (e.g. by ensuring that all provided examples follow proper accessible design guidelines).