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

Hi James,

I am cc'ing David Bolter.

David please take a look at James' proposal. We are going to discuss it and
DOM 3 events on Monday's ARIA call. One thing it gets us away from is
dealing with the 2D Context API document and it appears to do be doing the
same things as the 2D API Context change.

http://lists.w3.org/Archives/Member/w3c-wai-pf/2010JulSep/att-0130/UserInterfaceIndependence.html

Rich Schwerdtfeger
CTO Accessibility Software Group

James Craig <jcraig@apple.com> wrote on 09/22/2010 01:18:16 PM:

> 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?
>
The HTML 5 controls are more elaborate. They have the equivalent of menus
and such. The events would likely be handled by the browser which manages
the native controls. Those controls respond to keyboard keys today. If the
author tries to overload those controls to create different UI elements are
we going to have conflicts?

> > 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?
>
ok

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

> > 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 like that approach. I would rather the browser provide information
like this in a non-AT sort of way as is done for AccessForAll. There may be
situations where providing information is important to users who
traditionally are not considered impaired users. This is the premise for
the lastest personalization accessibility efforts. It also makes it much
easier to provide things across domains. You may have an accessibility test
tool needing the information as well. I think having to approve things
across domains will be frustrating for some users. Cookies are driven by
the web application that sets them and manages them for that domain. These
are user driven.

That is not to say that I would  not want to allow the user the ability to
provide domain specific restrictions. Also, even if the user does allow the
domain to have access why should we announce that they are using a specific
AT? We could also deliver these through local data storage where the user
could apply them across domain from a web UI. If we go down this road there
are lot of accessibility properties that would need to be provided. I need
to get a copy of Access For All 3 to you. A first draft is in the works.

> > 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.
>
I may have missed that. Let me look at those again for Monday.

> James
>