W3C home > Mailing lists > Public > public-canvas-api@w3.org > July to September 2010

Re: Proposal: User Interface Independence for Accessible Rich Internet Applications

From: James Craig <jcraig@apple.com>
Date: Wed, 22 Sep 2010 11:18:16 -0700
Cc: Chris Fleizach <cfleizach@apple.com>, public-canvas-api@w3.org
Message-Id: <2AF5A98A-C160-4584-819D-CD3723F41037@apple.com>
To: Richard Schwerdtfeger <schwer@us.ibm.com>
On Sep 7, 2010, at 3:29 PM, Richard Schwerdtfeger wrote:

> In principle I like the approach of having device independent events. Here is some feedback on the proposal:
> 1. Regarding UI Change Request Events than what you are showing:
> open (and would this apply to expand/collapse?)
> close - not sure escape is quite right for all situations
> backspace - this is not the same as delete on Windows systems

Makes sense. I'll add them.

> 2. All UI events
> What happens with these and standard controls in HTML 5 when the controls are not repurposed?

I'm not sure I understand your question. Could you elaborate?

> 3. Regarding ARIA Authoring Practices we would need to set some guidance as to what events each UI component should support.

Agreed. WAI-ARIA Authoring Practices 2.0?

> 4. Regarding Drag and Drop
> I think we need an Drag Menu event for the target. There may be multiple operations that can be executed on the target. ARIA has a dropeffect property that will allow for a menu to be rendered. 

I'm not convinced it's necessary. Once the element receives the drop event, the application can do whatever it wants. If an ARIA-enabled web app wants to show a menu, that's fine.

> 4. Assistive Technology Identification and Notification
> Regarding indicating if a screen reader is accessing the web content or a screen magnifier is accessing the content. This may be a privacy issue. I think we may need to change what these are called. It is possible that this information could be retrieved and sent off to a system that gathers statistics about users. For example, those that access Facebook with a screen reader might result in the assessment that the Facebook person is blind. In typical personalization scenarios where users ask for content be delivered in a specific way we have avoided making statements like this. I think we may need to make this more generic. 

That's why we added the recommendation that "User agents may return false if the user has chosen to disallow sharing this information with the requesting domain." as well as the informative note, "The authors recommend that user agents adopt a domain-level security policy for the ScreenReader interface that is similar to the security policy for location data or cookies. A user should be able to explicitly disallow sharing of this information altogether, or on a per-domain basis."

> I don't have a problem with the magnifier API but this removes the possibility of tieing the notification with a drawing call such as with draw focus ring in canvas. Also, focus in rings in canvas follow the drawing path so the author would need to manage the polygon and a cursorRect separate from Canvas.
> What about caret? Platforms use different accessibility APIs for caret.

That's what the optional cursor and selection parameters are for.

Received on Wednesday, 22 September 2010 18:19:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:50 UTC