Re: Widget Accessibility

On Fri, Aug 14, 2009 at 12:21 PM, Simon
Harper<simon.harper@manchester.ac.uk> wrote:
> Hi there, thanks for this.
>
> On 14 Aug 2009, at 10:12, Marcos Caceres wrote:
>
>> 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.
>>
>
> This is case to everyone technical at the development end. But for every
> designer (oops web developer) we speak to - with mainly backgrounds in print
> media / graphic design and with dream weaver on their desktop - this is not
> how it seems.

Yes. I agree (I taught advanced web development, graphic design,
multimedia and hypertextuality courses at a university level in my
previous job for about 8 years). The problem in academia is that there
has been a gross misunderstanding of Web technologies, and a general
miscommunication from resources on the Web (particularly sites like A
List Apart, who stupidly pushed xhtml and focused on mythical markup
semantics and useless validation instead of the DOM and browser
behavior).

With the advent of HTML5, and the popularity of AJAX, there has been a
renaissance of late in the appreciation of the architecture of the
Web. That is, people are starting to take note about what HTTP is
about and how it should be used properly/RESTfully, as well as an
understanding that there is limited correlation between the markup and
the DOM. Hopefully academia will take note and rethink about what it's
teaching the next generation of Web developers (yes, "developers"!...
designers should stick to the practice of "designing"; I don't know
any professional architects who are also bricklayers or foremen -
hopefully, a more clear separation of vocational concerns will become
evident as the industry matures).

Oh! and DreamWeaver is my primary work tool (all the specs I work on
are written in that) :)

>>> 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...
>
> This is kind of right:
> http://java.sun.com/javase/technologies/accessibility/docs/jaccess-1.1/doc/bridge.html
>
> but if the JavaScript interpreter doesn't implement this there will be a
> disconnect.

True, but that's an implementation detail.

> Indeed, even the heterogeneity of the content foxes us because we make
> assumptions about what something 'is' based on it's visual appearance as
> opposed to what it is in the code - the way the machine sees it. This is why
> css styled headings without heading elements are bad - they look like
> headings but the structural semantics imposed by the heading is lost to the
> machine if it is not explicit.

That's an authoring problem. There is not much you can do to stop an
author using the tools incorrectly. The following document is
completely valid, and no machine could ever help me:

<p style="font-weight: bold; font-size:2em">I'm a heading!</p>
<h1 style="font-weight: normal; font-size:1em">I'm a paragraph, really!</h1>

>>
>>> 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?
>>
>
> Pure speculation based on the fact that ARIA requires web designers do
> something extra - mostly this does not happen. Secondly, IMO it is not rich
> enough when used in combination with very complex applications. Think of a
> tree widget - you can build one of these using a combination of js, css, and
> html but the semantics of structure, control, and navigation is different
> for each one, regardless of ARIA additions. ARIA annotates what is there but
> does not impose anymore semantics than this - widgets have the opportunity
> to do this in a really powerful way. The problem in the visual visibility
> domain is that, when things don't work as you are used to, everything stops.

Wait, wait, wait! I think you have misunderstood the widget spec: the
widget spec is about packaging applications, not about  "UI widgets".
We don't even recommend any UI language at all. That is, widgets have
no real knowledge of HTML, CSS, etc. You can have a fully conforming
widget that has no interface at all.

>> 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.
>
> Widgets are the gateway because they describe a complicated combinatorial
> component and endow it with defined set of navigational and interactive
> semantics - widgets are really exciting in this regard.

UI widgets, yes. But those widgets you are describing are part of
HTML5's forms, not the widget spec:
http://dev.w3.org/html5/spec/Overview.html#forms

>
>> What you alluding to is a much wider discussion about
>> accessibility of platforms in general.
>
> I Agree
>
>> 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).
>>
>
> It wasn't my intention, I just wanted a general discussion on it, to see
> what you guys thought so I can take it back to UAWG.

Ah.

>> 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).
>>
>
> Thanks for this but no need as I work on WAI UAWG and so I'd run stuff
> through them - we're a bit too focused on html5 comments at the moment
> though.

Ok, cool.

-- 
Marcos Caceres
http://datadriven.com.au

Received on Friday, 14 August 2009 10:56:37 UTC