Re: Widget Accessibility

Great, so that clears up some parts of my misunderstanding of the  
widget spec. I thought that the spec, as is, would form a series  
ending up at UI and therefore we would be able to contribute at an  
early stage. However, I see that you're correct re the problems of  
not being appropriate to address accessibility here.

Thanks for the chat. Much appreciated.

Cheers
Si.

=======================

Simon Harper
University of Manchester (UK)

Human Centred Web Lab: http://hcw.cs.manchester.ac.uk

My Site: http://hcw.cs.manchester.ac.uk/people/harper/

My Diary (Web): http://hcw.cs.manchester.ac.uk/people/harper/ 
phpicalendar/week.php
My Diary (Subscribe): http://hcw.cs.manchester.ac.uk/diaries/harper/ 
SimonHarper.ics





On 14 Aug 2009, at 11:55, Marcos Caceres wrote:

> 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 14:04:43 UTC