From The Linux Foundation
Jump to: navigation, search

Minutes of the Open A11y Expert Handlers SIG Call 2008/01/14


  • Neil Soiffer (NS/chair)

Agenda Review

Agenda Addenda

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

For Reference:

Introduction Review

NS: start review with general introduction -- no comments on that; anyone else?

GJR: introduction or abstract?

NS: introduction makes most sense

JS: agree

PB: agree

  • 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: yes

JS: yes

NS: as in case of headers/id in TABLE

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

Navigability Use Case Review

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

PB: agree

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

Requirements Section

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

NS: ideas?

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?

GJR: discuss at general meeting -- the main group may want or need to draft a review or comments; think XHTML Access Module discussion most pertinent to IAccessible2 and AT-SPI

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