From The Linux Foundation
Revision as of 02:01, 1 August 2008 by Oedipus (Talk | contribs)

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

Minutes of the Open A11y Expert Handlers SIG Call 2008/07/21


  • Neil Soiffer (NS/chair)
    • Pete Brunet (PB)
    • Vladmir Bulatov (VB)
    • Gregory J. Rosmaita (GJR/scribe)
    • Janina Sajka (JS)
      • regrets: Alexander Surkov

Agenda Review

Approval of Last Meeting's Minutes

Minutes of Expert Handlers Conference Call 2008/07/21

Expert Handlers: Requirements & Strategies, continued

NS: noted in reviewing minutes from last week's call that GJR's discussion about CSS is XHTML/XML centric

NS: thought our mandate was broader

JS: in principle, broader, but in practice, will probably be using a dialect of XML

NS: there are styling conventions, but no CSS in non-XML dialects

GJR: if have Compound Document Format, possible -- XHTML in PDF, XHTML+SVG+MathML; almost all of our use cases involve specialized knowledge domain markup languages written in accordance with the W3C's XML specification

GJR: another advantage would be the Element Traversal Specification which is under development -- when enter SVG go into SVG mode and DOM, leave when user navigates away or goes into review mode

NS: HTML5 doesn't recognize namespaces

GJR: the question of namespacing and extensibility in HTML5 is still a topic of discussion; for others it is a topic of dissention and contention -- besides HTML5 isn't a standard; XML is, and we are attempting to deal with extant specialized knowledge domain markup languages

GJR: use cases investigation led us to the realization that this is one area in which there is heavy use of XML - knowledge domain markup - GJR presumed XML markup

JS: what types of markup and what styling is available

GJR: another XML strength is XSLT - not optimal, but better than nothing; can always use XSLT to stuff text/html down the pipleline, for backwards compatibility

JS: had conversation with Judy Brewer in Tokyo - discussed need for liaison between W3C/WAI and Open A11y - informal agreement to check-in and steer resources to one another that might be mutually beneficial

GJR: PB, did you follow up with RichS on UbiWeb?

PB: RichS leaving for UbiWeb face2face -- good time to send questions

PB: [checks local email archive] july 9 and july 26 emailed JS, NS, and GJR emessage to RichS

PB: quotes from email:

PB: will do a memory jog - send note to Rob of Freedom Scientific and RichS after call

GJR: also lingering discussion of attributes available via the DOM -- example: AT keying off of the lang attribute to provide natural language switching on the fly

GJR: also problem of getting CSS-generated content into the DOM

GJR: CSS-generated content is rendered, but does not appear in DOM; have done a lot of testing of this over the years - there are a few CSS3 modules that aim to address this, they are all in limbo (include links)

ACTION GJR: provide sample pages with generated CSS

  1. CSS-Generated Contextual Content, example 1: explicit insertion of contextual content
  2. CSS-Generated Contextual Content, example 2: the CSS-generated content is hidden from the visual canvas by use of WCAG2 Technique C7 (results may vary by browser/this page needs further tweaking)

NS: hard to understand and tell where breaks are - real renderer

GJR: no substitute for expert handler, but (a) basic (b) supported and (c) backwards compatible

NS: GJR has also repeatedly brought up content negotiation - what device need to render to? generating speech, braille display, or for any AT at all

JS: linked to note PB sending Rich?

NS: specific query of device for properties, but how to know what device to ask for? current device? could be more than one (screen reader and braille, screen reader and magnification)

JS: threshold question - way to identify device

GJR: would need to be part of CC/PP profile

NS: AT asks for info, "tell me how to render"?

GJR: unminuted content negotiation explanation with clarifying questions by NS & PB

GJR: id in abstract a device, AT would know the specific localized hardware and settings

GJR: similar to content negotiation with UA; AT is going to know specific localized info needed for correct rendering

NS: of use to us, or limited use? touches EH, but not our problem

GJR: need abstract device types similar to @media types for CSS - just exploring means of implementing

NS: media types in CSS are rather generic

GJR: device types would be generic, communicate to AT, and then AT looks at its internal settings to localize the preference for a specific device - AT responsible for transition from device-type to device-specifics

NS: AT needs to know specifics - where does that come from?

GJR: AT has register of installed/supported devices and drivers, braille tables, and languages -- respect AT's settings (and more importantly the user's preferences), by letting AT determine specifics based upon localized information known to the AT

GJR: some MLs won't have navigational flow - guidance can be provided by either CSS or through SVG's proposed order attribute for the XHTML Access Module, which is a boolean attribute, the default value for which is document (meaning respect ML's native sequential ordering) or list (which would provide an author with a means of setting a sequential flow through a document that isn't sequential, such as an SVG object, which is stacked)

NS: so, CSS can help some

GJR: Access Module will definitely help

GJR: status check of SIG: right now, after having defined use cases, we're trying to identify holes in the use cases already defined and exploring existing solutions (even if partial); we need to use our individual contacts to fill in knowledge gaps/specifics

JS: sounds reasonable

TOPIC: Next Expert Handlers Conference Call

NS: availability for 28 July 2008?

  • Janina: yes
  • Pete: yes
  • Vladmir: probable
  • Gregory: yes

GJR: i will try and get more info on CC/PP current status; and perform a reality check