Re: Widget Accessibility
Hi Simon, On Thu, Aug 13, 2009 at 7:45 PM, Simon Harpersimon.har...@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
Re: Widget Accessibility
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 Harpersimon.har...@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. 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. 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. 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. 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. 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. 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. Cheers Si.
Re: Widget Accessibility
On 14 Aug 2009, at 10:31, Arve Bersvendsen wrote: On Thu, 13 Aug 2009 19:45:14 +0200, Simon Harper simon.har...@manchester.ac.uk wrote: 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. Just to clarify something here: The Widgets PC specification is agnostic with regards to the underlying technology platform, and does not actually require the content contained within the widget to be web content/applications. If you want to use Widgets as a container/packaging format for, say, Windows or Linux applications, you are most certainly free to do so (not that I would recommend it, though). As such, I believe the widget space is the wrong arena to discuss accessibility issues, unless some part of the widget family of specifications directly prohibit accessible applications. Thanks for the clarity, I just get excited that widgets may provide some really niffty accessibility enhancements as they did with Java - before the bridge and the accessifying of Java Swing widgets accessibility in Java was low (and bespoke) - after that things really started to move. Cheers Si -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: Widget Accessibility
On Fri, Aug 14, 2009 at 12:21 PM, Simon Harpersimon.har...@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 Harpersimon.har...@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:2emI'm a heading!/p h1 style=font-weight: normal; font-size:1emI'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 -
Re: Widget Accessibility
On Fri, 14 Aug 2009 12:55:35 +0200, Marcos Caceres marc...@opera.com wrote: That is, widgets have no real knowledge of HTML, CSS, etc. You can have a fully conforming widget that has no interface at all. Just reiterating this point: Opera Unite [1], while currently using a proprietary manifest format are essentially widgets whose only interface is HTTP. ___ [1] URL:http://unite.opera.com/ -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
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 Harpersimon.har...@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 Harpersimon.har...@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:2emI'm a heading!/p h1 style=font-weight: normal; font-size:1emI'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
Re: Widget Accessibility
Thanks for the pointer to that, have a good weekend! 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 12:29, Arve Bersvendsen wrote: On Fri, 14 Aug 2009 12:55:35 +0200, Marcos Caceres marc...@opera.com wrote: That is, widgets have no real knowledge of HTML, CSS, etc. You can have a fully conforming widget that has no interface at all. Just reiterating this point: Opera Unite [1], while currently using a proprietary manifest format are essentially widgets whose only interface is HTTP. ___ [1] URL:http://unite.opera.com/ -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: Widget Accessibility
Simon Harper wrote: 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. Heh, we actually started this working group four years ago specifically with that goal in mind (standardize something like XAML or XUL)! Most of us quickly threw that idea in the bin when we saw how awesome HTML5 and XBL2 were (and a few other reasons, we won't go into here):) However, I see that you're correct re the problems of not being appropriate to address accessibility here. Thanks for the chat. Much appreciated. No probs!
Re: Widget Accessibility
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. 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). 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. 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. 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. 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 7 Aug 2009, at 16:31, Marcos Caceres wrote: On Fri, Aug 7, 2009 at 5:12 PM, Simon Harpersimon.har...@manchester.ac.uk wrote: Hi there, I've been looking through the widget specifications specifically 'Widgets 1.0: The Widget Landscape (Q1 2008)' - Figure 1 at http://dev.w3.org/2006/waf/widgets-land/ I wonder if there is any concept of an accessibility bridge in either the widget of web application specifications. I was thinking of something like the Java Accessibility Bridge which links the code to the interpreter and on to the OS. If there is the concept of the Web as an application Platform then are there any similar concepts for making accessibility work in a uniform way - built-in at the start as opposed to an ARIA addition? No, not for widgets. Widgets rely on HTML and its hooks for accessibility. See also: http://dev.w3.org/2006/waf/widgets-reqs/#user-interface-accessibility However, if you have any ideas about a better way of doing this, we would certainly like to hear it. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: Widget Accessibility
Simon, On Aug 13, 2009, at 1:45 PM, ext Simon Harper wrote: 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. If you have any specific accessibility-related requirements for any of the WebApps WG's specs [1], especially our widgets specification suite [2], please send us the info/pointers. -Regards, Art Barstow [1] http://www.w3.org/2008/webapps/wiki/PubStatus [2] http://www.w3.org/2008/webapps/wiki/PubStatus#Widgets_Specifications
Widget Accessibility
Hi there, I've been looking through the widget specifications specifically 'Widgets 1.0: The Widget Landscape (Q1 2008)' - Figure 1 at http:// dev.w3.org/2006/waf/widgets-land/ I wonder if there is any concept of an accessibility bridge in either the widget of web application specifications. I was thinking of something like the Java Accessibility Bridge which links the code to the interpreter and on to the OS. If there is the concept of the Web as an application Platform then are there any similar concepts for making accessibility work in a uniform way - built-in at the start as opposed to an ARIA addition? Best 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
Re: Widget Accessibility
On Fri, Aug 7, 2009 at 5:12 PM, Simon Harpersimon.har...@manchester.ac.uk wrote: Hi there, I've been looking through the widget specifications specifically 'Widgets 1.0: The Widget Landscape (Q1 2008)' - Figure 1 at http://dev.w3.org/2006/waf/widgets-land/ I wonder if there is any concept of an accessibility bridge in either the widget of web application specifications. I was thinking of something like the Java Accessibility Bridge which links the code to the interpreter and on to the OS. If there is the concept of the Web as an application Platform then are there any similar concepts for making accessibility work in a uniform way - built-in at the start as opposed to an ARIA addition? No, not for widgets. Widgets rely on HTML and its hooks for accessibility. See also: http://dev.w3.org/2006/waf/widgets-reqs/#user-interface-accessibility However, if you have any ideas about a better way of doing this, we would certainly like to hear it. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
