From The Linux Foundation
Revision as of 03:06, 27 January 2008 by Oedipus (Talk | contribs)

(diff) ←Older revision | view current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

Open A11y Working Group Conference Call (15 January 2008)


  • Janina Sajka (JS/chair)
    • Bill Haneman (BH)
    • George Kraft IV (GK4)
    • Gregory J. Rosmaita (GJR/scribe)
    • Gunnar Schmidt (GS)
    • Olaf Schmidt (OS)
    • Neil Soiffer (NS)
    • Willie Walker (WW)
      • regrets: none yet logged

For Reference

Preliminary Items

WW: Olaf, you sent mail to the list i think has a typo -- wanted to give you the opportunity to correct before flaming begins: "should not have a wide choice"

OS: thanks for the pick-up -- will clarify on list

Approval of Past Minutes

Action Items Status Review

Summary of Action Items Assigned at the 2007-01-08 Open A11y Conference Call

none logged

Summary of Continued Action Items

Meeting Minutes

Topic 1: AT-SPI on D-Bus and the Collection API

For Reference:

JS: today's telecon was supposed to be dedicated to continuing the discussion about the Collection API in relation to the port of ATK/AT-SPI to D-Bus; while there are no CodeThink reps here today, i think we can still address some concerns concerns -- the recent study data from CodeThink would help, but we can gather concerns to give that future conversation more structure

GK4: probably need to wait until we have Michael Meeks, Mark Doffman, Robert Taylor, and Bill Hanemen on the call

JS: should we try have the Collections API discussion at the 29 january 2008 call?? 22 January 2008 call is already scheduled around Calvin Gainsford's presentation on Novell's current work and in specific, the port of mono to linux

GK4: is there anything in the version repository? (note capitalizatoin of GAP); bug # 326516

WW: use the Collection API to generate page summary info for Orca -- implementation close, but not quite there; want to see it finalized for GNOME 2.02

JS: need to invite all stakeholders to the 29 January 2008 meeting, then

GK4: dealing with documents that haven't been rendered on screen -- current implementation keeps from happening over IPC, but doesn't presume problems with object not yet rendered

WW: getting summary in FireFox

GK4: to do simply, need ATK collection, so can ask FireFox and not the bridge to do it -- more in-process

WW: if can identify use cases when need all accessible when not rendered could use single API to handle those use cases

GK4: why not use Collections API for that?

WW: need to examine the "cost" of that

GK4: could be what we need (the use cases) -- if answer is collection is too big a hammer and can be abused to cause efficiency problems for FireFox, should perhaps consider something in collection to allow UA to politely decline server requests ("Resource exceeded" -- communicates to client "i don't want to do that")

WW: need Michael Meeks, Robert Taylor, Mark Doffman, Bill Haneman etc. to discuss in detail

Gk4: D-Bus specific collection may be another argument for why we need unique object identifiers as opposed to paths for handles; path in hierarchy presupposes a lot of rendering/realization stuff -- if want to collect a bag of things without regard to whether on screen or styled specifically; path implies know entire architecture of document

WW: life-cycle issue -- if visible, it's available; if not visible, not garunteed to have handle; should have discussion with CodeThink and other players

Topic 2: XHTML Access Module and Open Accessibility: Tracking, Commenting and Review

For Reference:

JS: developement out of XHTML2 WG that in a more generic sense seeks to put reqs and specificity around a11y tech and markup

BH: is the work include some sort of explicit mapping in form of table between XHTML and taxonomies

GJR: not yet -- DTD and Schema; may be an appendix or a best practices document (ARIA model)

BH: particular interest to AT middle-ware and AT developers using APIs should be something can look at in tabular form and proposed mapping of features

BH: DTDs and Schemas fine as far as describing universe of XML dialects; even if can't be made explicit to point that can do with automation, recommended for someone who isn't in the thick of working with XML a lot easier to reveiw table and satisfy ourselves that features will meet our needs

GJR: the module defines an element that, when used in conjunction with other XHTML modules in the XHTML Family Markup Languages, enables a "more robust accessibility model" than it is currently possible to do with extant markup languages -- to quote the first public working draft:

a single module designed to be used to help make XHTML-family markup languages more effective at supporting the needs of the Accessibility Community. It has been developed in conjunction with the W3C's Web Accessibility Initiative and other interested parties. It provides a generic mechanism for defining the relationship between document components and well-known accessibility taxonomies.

[scribe's note: a Second Edition of XHTML Modularization is currently being developed]

NS: what kind of information would go into that table? what does XHTML Access Module need to do to map to something?

BH: don't think would be mapping; Access Module is yet another API for providing accessibility information; in order to be most useful, needs to be mappable to specific taxonomies

NS: other than "set focus here" what is the module trying to accomplish? what is the mapping that needs to be done beyond focus?

BH: not exclusively for POR mapping

GJR: its genesis is a redefinition and clarification of the HTML 4.01 concept of "accesskey" in XHTML

BH: only one of a whole constellation of modules with accessibility implications; mapping from whole of XML, not individual modules; need for some "omniscient" group that will write what one needs to understand

GJR: will bring this feedback back to the XHTML2 Working Group at tomorrow's (16 january 2008) meeting

Topic 3: Open A11y Specification Template

For Reference:

Meta Issues and Questions: Open A11y Specification Template

  • boilerplate "copyright" and "licensing" verbiage -- get from LF?
    • status: under investigation
  • is there a boilerplate LF template?
    • status: under investigation
  • should the boilerplate template be Open A11y specific?
    • status: yes, to the greatest extent possible
  • is any other boilerplate material needed?
    • status: under investigation
  • conform to which ISO recommendations/standards as far as terminology and recommendation structure is concerned?
    • status: Open A11y will use RFC2119: Key words for use in RFCs to indicate requirement levels
  • verbiage needed re: trademarks of companies, interested parties, implementors? disclaimer-like things?
    • status: under investigation

Open A11y Specification Template MarkUp Issues

  1. do we want to use "class" as a pseudo-semantic attribute, or RDFa or simply use id/name associations?
  2. we want to use XHTML 1.0 Strict (at least)
  3. elimination of needless tables (table of contents should not be interpreted literally by an authoring tool
  4. we need to decide on a unified "look-and-feel" (and sounds)
  5. we want to use Dublin Core markup in the HEAD via the meta element, right?
  <meta name="DC.Title" 
     content="Keyboard Access Functional Specification, RC2" />
  <meta name="DC.Title.Alternative" 
     content="" />
  <meta name="DC.Creator.PersonalName" 
     content="Earl Johnson, Sun Microsystems, Inc." />
  <meta name="DC.Creator.PersonalName" 
     content="Bill Haneman, Sun Microsystems, Inc." />
  <meta name="DC.Creator.PersonalName" 
     content="Mark Novak, University of Wisconsin, Madison" />
  <meta name="DC.Creator.PersonalName" 
     content="Willie Walker, Sun Microsystems, Inc." />
  <meta name="DC.Subject" content="Functional Specification" />
  <meta name="DC.Subject" content="Keyboard" />
  <meta name="DC.Subject" content="Keyboard Input" />
  <meta name="DC.Subject" content="Alternative Input" />
  <meta name="DC.Subject" content="system pointer" />
  <meta name="DC.Subject" content="keyboard accessibility support" />
  <meta name="DC.Subject" content="keyboard notification" />
  <meta name="DC.Subject" content="Configuration and Setting Requirements" />
  <meta name="DC.Subject" content="End-User Notification Requirements" />
  <meta name="DC.Subject" content="Keyboard Invocation Requirements" />
  <meta name="DC.Subject" content="Pointer Emulation Requirements" />
  <meta name="DC.Subject" content="Feature Behavior Requirements" />
  <meta name="DC.Subject" content="StickyKeys" />
  <meta name="DC.Subject" content="MouseKeys" />
  <meta name="DC.Subject" content="RepeatKeys" />
  <meta name="DC.Subject" content="SlowKeys" />
  <meta name="DC.Subject" content="BounceKeys" />
  <meta name="DC.Subject" content="ToggleKeys" />
  <meta name="DC.Subject" content="Free Standards Group (FSG)" />
  <meta name="DC.Subject" content="FSG" />
  <meta name="DC.Subject" content="FSG Certified" />
  <meta name="DC.Subject" content="X Windowing System" />
  <meta name="DC.Subject" content="" />
  <meta name="DC.Subject" content="" />
  <meta name="DC.Subject" content="" />
  <meta name="DC.Description" content="This functional specification 
  defines the support that must be built into the system. The 
  capabilities provided by the features in it define the pointer 
  based events and capabilities that must be emulated by the system 
  as well as how the system should interpret and process a user's 
  keypresses. For the most part, defining and/or specifying the exact 
  user interface[s] these features are presented in is beyond the scope 
  of this specification. The one exception area is keyboard shortcuts 
  that are already considered de facto standards.  These shortcuts are 
  explicitly defined." />
  <meta name="DC.Publisher" 
     content="Open Accessibility (A11y) Workgroup of the Linux Foundation" />
  <meta name="DC.Rights" content="" />
  <meta name="DC.Type" content="Text" />
  <meta name="DC.Format" content="text/html" />
  <meta name="DC.Identifier" 
  content="" />
  <meta name="DC.Language" content="us-en" />

Topic 4: SIG Updates

For Reference:

NS: Expert Handlers SIG is developing a [Use Cases and Flow of Control] document; outlines strategies on how AT may work with an Expert Handler; close to soliciting general review from main Open A11y working group

JS: explanation of Expert Handlers: plug into AT to get better models to provide better interaction with specific domain knowledge markup languages

NS: standard way to interact with specialized markup languages so as to avoid proprietary (one-off) implementations

JS: will be bringing finalized Expert Handlers Unified Use Case document to main group; then, solicit feedback from AT vendors; if can come up with a standard mechanism, any AT can just plug-into it

Topic 5: Website Update

New Business

Identify Topics for 22 January 2008 Teleconference

  • Scheduled Main Topic: Calvin Gainsford's report on the port of mono to linux

Wrap Up

Summary of New Action Items

Summary of Continued Action Items

Summary of Resolutions