User Agent Accessibility Guidelines 1.0 (UAAG 1.0) provides guidelines for designing user agents (browsers) that lower barriers to Web accessibility for people with disabilities (visual, hearing, physical, cognitive, and neurological).
Since the release of UAAG 1.0 as a W3C Recommendation in December 2002, the UAWG has received feedback about the usability, understandability, and applicability of the suite of documents. Also, in the intervening years there have been changes and improvements in technologies and techniques used in web content, functionality of assistive technology, accessibility application programming interfaces (APIs), and platforms used to receive content.
NS: There is definitively some overlap with what we are doing.
GJR: member of the UAWG and liaison between UAWG and the HTML WG; one notable decision taken at the W3C Technical Plenary is to require that all content -- no matter how generated (via CSS-pseudo elements or scripting) be made available in the DOM or directly to an Accessibility API; also working on action item as to what the means of final recourse (access to document source) means in the age of mash-ups, DHTML, and CDF
NS: good, so we already have someone on the inside who can liaise and keep each group apprised of what the other is doing
The mission of the W3C's Web API Working Group is to develop specifications that enable improved client-side application development on the Web. This includes the development of programming interfaces to be made available in a Web client.
The target platforms for this Working Group includes desktop and mobile browsers as well as many specialty, browser-like environments that use Web client technologies. The goal is to promote universal access both for devices and users, including those with special needs.
GJR: in process of joining WebAPI group; would like to get Doug Schepers -- staff contact at the W3C for SVG, WebAPI and CDF more involved slash in-tune with developments in Open A11y workgroup's group; also been informally liaising with Kenny Johar of Vision Australia, who has experience serving DAISY to mobile devices -- he is now a member of the CDF working group and we've discussed coordinating efforts to get for CDF what DAISY obtained in SMIL3 -- an entire SMIL profile so that there would be a standard means of handling CDF, so that, for example, digital talking books might be supported out-of-the-box by CDF-conformant user agents -- many other areas of discussion with Kenny, but time difference would make his direct participation in Open A11y difficult-to-impossible; want to at least get him subscribed to the main accessibility list
GJR: one place where a generic handler mechanism will have to be defined is the Ubiquitous Web Activity, in particular, by the Ubiquitous Web Applications Activity -- they are a natural ally in which we may have to find someone to participate directly
ACTION GJR: find out who Catherine Laws represents in UAAG
ACTION GJR: notify SIG when process of joining the WebAPI WG complete
SUB-TOPIC 1: Linux Foundation Process
GJR: if issue as a "note", i believe we can publish by ourselves -- as for a standard/specification, that would need approval by LF Board of Directors
JS: correct: that's the track on which the Keyboard Access Functional Spec and IDL for AT-SPI are on
NS: is there a LF requirements document?
JS: our charter is to develop Use Cases, requirements and roadmap, etc., then go back to main Open A11y WG for review;
SUB-TOPIC 2: Fundraising/Grant Writing
NS: may need to get some funding for expert handlers work
JS: definitely a need to fundraise -- one possibility is a NSF grant for improvements in math and science education for PWDs)
NS: Department of Education funding should also be explored
GJR: definitely -- part of the work on ARIA is supported by a grant from the U.S. Department of Education
JS: what will architecture look like? consumed and processed before reaches AT so that AT doesn't need to support specific MLs
NS: thought that AG implied that handler would say "here is where in the DOM you should be looking"
GJR: most full expression of what is needed at abstract level can be found in: Expert Handlers and the Flow of Control (Draft 1)
NS: what is needed to go back to main WG?
JS: use cases and requirements --- here they are, please read, please provide feedback before SIG goes to next steps
NS: take extant UseCases, clean up, put into single document/comprehensive framework; same with flow of control proposal
JS: that is a good way to separate the issues and bring them to the main WG; after that, try and engage AT vendors for conversation about architecture -- would it fit, is it implementable, what do you need from us
NS: don't have time until after holidays to do this;
GJR: think we should target presentation to main WG before the end of January 2008
ACTION GJR: combine Use Cases into coherent whole, post to handlers mailing list, collect feedback and prepare for submission to main WG
ACTION NS: tweak Flow Control draft into something reviewable by the main WG
ACTION JS: try and lure in as many AT vendors as possible; put as many hooks in water as possible to solicit participation
NS: due to the end of the year and holiday preparations, I think we should skip next week's meeting and hold a meeting in 2 weeks (17 December 2007) to check status of action items designated during today's meeting;