Comments on Web Applications Working Group Charter

webapps-charter.html

Categories Related to UAAG

Recommendation-Track Deliverables

These are the collected concerns that the User Agent Working Group wants to follow up on with the Web Applications Working Group after their Charter is approved. These are not feedback on charter.

• Clipboard API and events

May be a WCAG issue. Concern about preserving Accessibility information (alt, aria, etc.) when cut/copy/paste. Especially, for aria-labelledby and aria-describedby where accessibility content may not be within the selected region. We suggest you consult ATAG, which includes a requirement to preserve all accessibility information when copying within the same application and same web technology (e.g. HTML to HTML, but not HTML to PDF) (http://www.w3.org/TR/2013/CR-ATAG20-20131107/#sc_b122):

"B.1.2.2 Copy-Paste Inside Authoring Tool (WCAG): If the authoring tool supports copy and paste of structured content, then any accessibility information (WCAG) in the copied content is preserved when the authoring tool is both the source and destination of the copy-paste and the source and destination use the same web content technology."

• 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. This seems a PF issue.

• 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? What about touch events?

• 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.

Jackie uses an on-screen keyboard that lets her "type" by hovering a head pointer over buttons on the on-screen keyboard window. If she starts a web app which switches into full-screen mode and covers up the on-screen keyboard window, she is unable to perform any input, including commands to exit that mode. She's totally stuck, and has to request human assistance. If the full-screen API took into consideration reserved areas of the screen, such as those being used by such critical utilities, the browser would not have covered the tools she relied on.

• 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).

3.1.1. Specification Maintenance

• Widget Interface