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

James,

On the PF call today I agreed to have a call to review the DOM 3 events
specification on Monday as part of the ARIA call. Given that Mike Cooper is
tied up with WCAG 2, the fact that DOM 3 is trying to get to last call and
the need for device independence I think we should see how we can integrate
your proposal into that work. Chris, if you would like to attend you are
certainly welcome.

I will respond to below in a separate note.

Rich

Rich Schwerdtfeger
CTO Accessibility Software Group



From:	James Craig <jcraig@apple.com>
To:	Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc:	Chris Fleizach <cfleizach@apple.com>, public-canvas-api@w3.org
Date:	09/22/2010 01:18 PM
Subject:	Re: Proposal: User Interface Independence for Accessible Rich
            Internet Applications



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.

James