- 1 Minutes of the Open A11y Expert Handlers SIG Call 2008/01/14
- 1.1 Attendance
- 1.2 Minutes of Expert Handlers Conference Call 2008/01/14
- 1.3 Unified Use Cases 2.01 Review
- 1.4 Topics for the 21 January 2007 Expert Handlers Conference Call
Minutes of the Open A11y Expert Handlers SIG Call 2008/01/14
- Neil Soiffer (NS/chair)
- Pete Brunet (PB)
- Gregory J. Rosmaita (GJR/scribe)
- Janina Sajka (JS)
- regrets: none logged
NS: should we give 3 weeks' notice before addressing the Unified Use Cases draft at the main Open A11y telecon?
JS: may have to postpone Collections API depending upon attendence at tomorrow's meeting -- Calvin Gainsford slated to present to WG on Novell's activities at the 22 january 2008 Open A11y call
GJR: would like us to discuss "Requirements for Expert Handlers"
Approval of Past Meetings' Minutes
Minutes of Expert Handlers Conference Call 2008/01/14
Unified Use Cases 2.01 Review
NS: start review with general introduction -- no comments on that; anyone else?
GJR: introduction or abstract?
NS: introduction makes most sense
- resolved: use word "introduction" rather than abstract
- (change effected in real-time)
NS: may need a third paragraph, to the effect that this document presents a number of use cases and an overall flow of control
GJR: will crib from CSUN2008 verbiage and post to handlers list
PB: intro looks good to me
JS: sounds good to me, too
GJR: author credits - inline or in author's section?
[scribe's note: no strong opinion expressed either way]
GJR: will leave as is for now
Speech Use Case Review
NS: Speech Use Case -- lieu is misspelled
GJR: will fix
NS: at end the term "similar to 'smart' content rendering" confused me -- wasn't clear what "On the other hand domain specific markup often does provide sufficient specificity so that the focus and rendering needs of the screen reader can be well supported. " means
NS: says "need an expert" then states that domain markup can contain what is needed
GJR: propose we move what is currently the last sentence before the sentence that begins "Furthermore..."
GJR: proposed text: "Some domain specific markup does provide sufficient specificity so that the focus and rendering needs of the screen reader can be well supported. However..."
JS: "often" can be removed
GJR: what about "In a few cases, domain specific markup does provide sufficient native specificity so that the focus and rendering needs of the screen reader can be well supported, but there is no garuntee that they will be implemented by a page author. Furthermore..."
JS: prefer "in many cases domain specific markup provides..."
GJR: in some cases? concern is that XHTML Access Module and ARIA will be the means by which accessibility features will be extended to custom XML dialects
NS: if expert handler provides information; on other hand, SVG can be authored accessibily or inaccessibly
GJR: that's why i added the bit about "page authors"
NS: for SVG can still follow specification and not make accessible -- while an SVG object validates; could still lack description and title
GJR: what about the term "native support"?
GJR: for example, in SVG no flow or flow of control is defined -- needs to be provided at abstract layer
JS: don't need all the caveats; there are appropriate caveats both ways; what can be siad for general HTML/XML can be said for domain specific; if provide mechanism for handling through expert handlers...
JS: appropriate discussion for future documents, but the Unified Use Case is about what can be done today
NS: there is markup out there that can be made accessible, but AT doesn't have hook to make accessible, for those interested groups that wish to have accessibility to that markup language, expert handler will make it happen
JS: shortcomings on markup side the problem/fault of the spec drafters/authors
NS: go back to leaving original sentence but with change from passive to active
JS: correct behavior is what we want to streee
GJR: even with generic markup languages, can be problematic if author doesn't provide explicit bindings to provide contextual information about content contained in a
TABLE, for example
NS: the Unified Use Cases assumes the editor used specific markup to programmatically bind data cells to headers
NS: previous paragraph addresses this without caveat
GJR: perhaps that is where caveat belongs
NS: as JS said, implied context is we are discussing correct implementation
GJR: address in introduction, then
NS: as in case of
GJR: prefer a universal up-front declaration, rather than inline comments
JS: would make whole document stronger
GJR: will post new introductory text to list before effecting change; will, however, effect passive to active voice change as per NS' request
GJR: removed disclaimers from Navigability section
NS: one thing that puzzled me is that there is no "where am i" feature described
GJR: janina's famous "huh? factor"
NS: needs a bullet item
GJR: tried to cover with "previous/current/next item" -- does it need a bullet point of its own?
JS: what is currently in draft is more akin to outline of page
NS: summary and context refreshing -- want summary before explore, when in it may need refresher "on where am i?"
NS: 2 things: summary of content and contextual refresher (say current)
NS: only section where first person is used "We need an example of such a plugin so we can evaluate what a11y features need to be added to the existing editors. "
GJR: changed to "An example of such a plugin is needed so that one can evaluate what a11y features need to be added to the existing editors."
NS: much better
PB: what do you mean by "all items in a author-defined category"
GJR: such as that provided by the headers/id association for HTML tables, and the grouping mechanisms defined by ARIA, such as labelledby and describedby.
JS: add as footnote?
GJR: yes, think best handled as footnote
PB: need to get AT vendors to review this
JS: that's our next step
NS: take to main Open A11y WG first or to vendors?
JS: ideally, in parallell
PB: last paragraph about editable content will need to be expanded;
Magnification Use Case Review
NS: short, no comments
JS: no comments either
GJR: no comments -- nice, short and sweet
Braille Use Case Review
NS: general comment -- both discussion of braille and tactile graphics -- should we change title to reflect that or change content to focus exclusively on braille -- my preference is to change title
GJR: Structure to Tactile Conversion???
NS: braille special case of tactile conversion
JS: that's the capital B
NS: NFB recommends capital B if referring to Louis Braille and lower case braille for referring to the specific braille code
JS: general tactile representation is lower case b
NS: in case of "An Expert Handler should be able to provide braille data for braille display output by generic Assisstive Technology (AT). " which would you capitalize?
JS: the first -- one problem is there aren't many refreshable tactile graphic displays -- at least not affordable ones that would provide the tactile equivalent of what appears phosphorescently on the screen
JS: expanding title might suffice
NS: mentioning Unicode symbols a bit out of place -- should state that this is an issue and that one solution would be to use unicode
GJR: please make that request/comment to Vladmir on the handlers list?
NS: ok, will do
GJR: understand why in there -- want to use unicode over individual character sets
NS: me too, but not well integrated -- will propose new verbiage and address to VB via the handlers list
NS: not sure why "exclusively" is emphasized
[scribe's note: the word "exclusively" is no longer emphasized; change made in real time]
GJR: need to replace use of "a11y" for "accessibility" inline in text
Resolved: the title of this section will be "Braille Display, Embossing and Tactile Conversion Use Cases".
Flow of Control Review
NS: missing period at end of first bullet item
[scribe's note: period added in real-time]
JS: good with it
PB: fine by me
GJR: will effect that change
PB: "expert handler registers itself" -- what does that mean?
NS: at install time
PB: like an extention to firefox? -- add to list of extentions?
NS: yes -- don't know how appropriate extention mechanism should work
NS: for example, if have a web browser, register plugin or extention in accordance with application and platform; details not appropriate, but "Expert handler registers itself
PB: during some sort of installation process
NS: during installation,
[scribe's note: change of first bullet point's first sentence effected in real-time]
Structural Issues and Finalization
NS: now that i've thought about it, i think a list of authors would be appropriate, rather than inline notations -- at beginning would be best
NS: have a nagging feeling that the document needs another paragraph
JS: don't want to go too far towards implementation -- need requirements
NS: one or 2 sentences at end -- "The pros and cons of individual mechanisms needs further investigation by all stakeholders."
PB: not sure if second list first bullet should be one or 2
NS: can imagine that EH presents view of DOM that converts DOM tree into something simpler that an AT can use directly
JS: feeds into logical ordering or mapped to something AT knows how to handle
PB: thought EH something that is not translating specialized markup into something AT understands, but enabling AT to interpret specialized markup
NS: the 3 bullet points represent 3 ways an EH might work; first one problably a bad idea because modifies DOM, but leaves AT out of loop, so more efficient; first bullet point means mapping a document instance to something simple through the DOM; in others DOM not involved -- either grab DOM and give to expert handler or point expert handler at DOM
GJR: requirements section: what level of granularity?
GJR: would like to keep abstract, but have at least 1 implementation example for each requirement?
JS: could be postponed until after meeting with AT vendors -- requirements will come out of decision of how the flow is implemented; layout use cases and scenarios "in order for this to be appropriately implemented..." -- good markup and flow;
NS: seems premature to have requirements document so early in the development process -- no external feedback -- need to find out what other stakeholders think
JS: can withdraw and put in next steps
GJR: will move issue to the Scratch Pad for the Unified Use Cases document
Topics for the 21 January 2007 Expert Handlers Conference Call
JS: think we are moving rapidly towards closing this document and pushing it outside of the Expert Handlers SIG
NS: will address a few issues: braille with Vladmir, as well as other changes noted in minutes
JS: mostly editorial clean-up
NS: next meeting should we try to finalize unified use cases?
JS: need to begin discussing who and when for discussions with AT vendors
NS: other issue -- when to bring to main Open A11y call
NS: GJR please put on agenda
GJR: will do
NS: question for GJR -- where do you envision the XHTML Access Module first public draft review being discussed?
JS: good argument for addressing at main working group meeting (tuesday at 2pm EST/1900h UTC
NS: ok, i can make that
GJR: will add discussion of XHTML Access Module to agenda for tomorrow's main Open Accessibility conference call tomorrow
JS: slated to hold a detailed discussion of the Collection API under D-Bus tomorrow, but it may not materialize
GJR: will put on tomorrow's agenda and can discuss based on who is in attendence
JS: pleased with progress on the Unified Use Cases document; beginning to look more and more like a good milestone
- adjourned: 2027h UTC
- Agenda for 2008/01/21 Expert Handlers Call