W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: Widget Accessibility

From: Marcos Caceres <marcosc@opera.com>
Date: Fri, 14 Aug 2009 11:12:29 +0200
Message-ID: <b21a10670908140212p5713d4eke63c297ffd578ebf@mail.gmail.com>
To: Simon Harper <simon.harper@manchester.ac.uk>
Cc: public-webapps@w3.org
Hi Simon,

On Thu, Aug 13, 2009 at 7:45 PM, Simon
Harper<simon.harper@manchester.ac.uk> wrote:
> Hi there Marcos, sorry for the delay in responding - I've been thinking
> about this...
>
> It seems to me that the current aspects of accessibility and notification is
> built in general for content, yet we are trying to use it in the context of
> applications.

Right.

> If the Web 'page' is going to present content we need content accessibility
> (which we kind-of have).
> If the Web 'page' is an application we need application accessibility (which
> we don't have).

The distinction between "page" and "application" was broken down the
second the DOM became accessible through script (around 1995). There
are no "pages", only applications of HTML that behave metaphorically
as static "pages" (HTML5 was originally called "Web Applications 1.0"
for this reason [1]). Anyway, that's a rat-hole that we should not go
down.

> To me this seems to suggest that we need the kind of accessibility solutions
> found in languages such as Java - in which there is an accessibility bridge
> connecting the Java interpreter to the OS.

Right, but you already get an "accessibility bridge" with every
platform (java, .net, objective-c): browsers integrate as components
into platforms, which themselves provide the accessibility hooks...

> Rich accessibility based in an
> implicit knowledge of the well-structured data and the way a complicated
> structure, such as a swing widget, should be navigated and interacted with.
> This can only come with a knowledge of the explicit structural and
> navigational semantics of the widget, component, or application framework.
> Indeed, I would also suggest that this accessibility can be mainly
> facilitated without the knowledge of the developer, purely based on this
> groups specifications of widgets and applications.

Agreed.

> As far as I can see, the browser is the (JavaScript+HTML) interpreter,
> therefore a richer accessibility bridge is required, which will not be
> addressed by ARIA alone.

Why? is this speculation? or do you have data to support claims that
HTML+ARIA does not provide sufficient structure and semantics to
create an accessible object that can be bridged with a platform?

I can see the potential benefit of having a standardized bridge for
accessibility, but I don't believe this is something that pertains to
widgets. What you alluding to is a much wider discussion about
accessibility of platforms in general. Also, you haven't really
presented a case that shows that the varying accessibility bridges
across platforms is causing interoperability issues across Web
applications (or for applications in general).

If you could show the above, then I would take that up with the WAI WG
(though, I would sure like to hear the details).

Kind regards,
Marcos

[1] http://www.whatwg.org/specs/web-apps/2005-09-01/
-- 
Marcos Caceres
http://datadriven.com.au
Received on Friday, 14 August 2009 09:13:36 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT