From The Linux Foundation
Revision as of 21:20, 10 June 2008 by Ptbrunet (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/06/09


  • 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

New Business

GJR: Rich Web Applications Backplane Incubator Group (RWAB XG) update - RWAB an open standard as well as open source project, using ubiquity xforms model for common script libraries and IDLs for XML Events 2, XForms, and other scripting-dependent web applications using AJAX output by the dojo toolkit, which is ARIA-enabled thanks to Becky Gibson's team's work; also useable by the Yahoo! User Interface (YUI) Library - which itself is being ARIA-enabled

scribe's note: more details and links to follow on-list

PB: dojo - a set of widgets (combo boxes and sliders) developers can use for Web 2.0 interfaces

GJR: will post info about XG to list

Minutes of Expert Handlers Conference Call 2008/06/09

Topic 1: Continuation of Discussion from 19 May 2008

NS: PB added to last meeting's minutes a proposal for string for device, buffer size (40 or 80 for braille cells), string for speech

PB: GJR, didn't you have a concern about buffer values of -1?

GJR: had red flag about negative buffer values, but can't remember precise comments off the top of my head

NS: might want to have Australian braille with UK braille as backup - have to enumerate every single potential braille; worries me;

NS: MathPlayer doesn't do braille translation, rely on third parties - have interface to call them; braille translation interfaces varied greatly (where are tables for localization) -- added parameter depends on device one is using; in more formal standard want escape hatch for things that don't know up front when dealing with other types of markup -- may be info that needs to be passed to markup that we are not aware of, so having an "escape hatch" useful

PB: in IA2 to an extent - text attribute specification and object attribute specification, so consistent from app to app; end up with common set everyone will implement; application specific sets should be used for unrelated unique values

NS: attributes communicated how?

PB: IA2::get_attributes - attribute value pairs

NS: IA2 defined notion of attributes and left open potential values for them

NS: dealing with braille, one set of attributes; might need others on the fly; might be able to send info to

PB: string for device - AT knows how to talk to Braille or TTS device, but doesn't have expertise to form string, so call EH telling what type of app talking with, size of buffer

NS: device in future (touchscreen grid) -- may put tactile display on it of some sort - attributes different from buffer size (width and height) -- need to know "what to put on this portion of screen" or tells where to break

PB: AT doing this?

NS: yes, AT says "have this markup, have this (non-linear) device, have some markup, have translation for markup, so tell me what it is going to be"

NS: like idea of attributes - can you pass around attribute collections in IA2? if have call, could you build collection of key value pairs?

PB: any particular object with focus if text object, can query for attributes of text at this outset; if paragraph object, might have object attribute determining margin

NS: read-only attributes of particular...

PB: string for device call/signal want to pass in info/attributes of the device; not rendering of ML;

PB: add another parameter or another call (expert handler)

VB: interface for device, not ID -- may make easier and more extensible

VB: like a thin device

NS: slightly more complicated, but yes, if pass interface EH can go back and query attributes for that interface; common high-level interface events which can be queried

NS: precedent in IA2 for passing interfaces? string for device instead of first parameter being enumDevice is interface pointer, EH could use pointer to interface to query device's parameters (how many cells available)

VB: type of device - after that can have interface with display; interface gives display info

PB: interesting - not aware of that kind of swap; now, AT becomes server and app becomes client (COM server and COM client) -- need to check to ascertain if can switch role, so app can have COM server and COM client interface

PB (post meeting): An AT can be both a COM server and a COM client.

VB: easiest path to solution -- pass COM IUnknown interface to what knows

JS: similar to W3C ubiquitous web specs - trying to cater to capabilities and preferences

PB: should be workable that way -- AT pass interface to app "if you want to know anything about this thing you are creating a string for, here is where can be found"

JS: Ubiquitous Web activity at W3C may provide basis

GJR: RichS authority on Ubiquitous Web

JS: PF has good relations with Debbi Dahl, co-chair of the Ubiquitous Web WG; may be willing to speak with us at a telecon

PB: will ping RichS on ubiquitous web approaches

NS: OK - have questions and people to ask about them

NS: one thing missing from IA2 and MSAA is strings that get sent back when say "tell me what is at cursor" are always plain text strings -- can't get emphasis to TTS

PB: where text attributes come into play - query text attributes and user sets what notification to receive

NS: onus on the AT to know that should query for emphasis tag to do something special

PB: unless knows has another protocol with expert handler

NS: assumption is speak the text, drop the emphasis

NS: description in plain text = might say Blah Blah Blah

PB: if knows attached to braille device call device string with all answers built into it

NS: kind of almost a missing convenience feature -- have text, here are tags for text, respond appropriately

GJR: 2 approaches: extra query for text attribute or triggering by element recognition

NS: include tagging without string for device?

NS: AT have to look for EM element

PB: no mechanism in IA2 now for this type of string -- AccessibleName AccessibleDescription (longer in length), IAccessibleText - returns text as seen on screen; need another method to tailor to device

NS: TTS as device

GJR: CSS embossed (paged media) - there should be a way to import stylesheet that is tailored to the user's natural language preference which can be loaded as an overlay to provide localized output for user

GJR: CSS aural/speech - often used for in-line declarations especially in wikis and blogs (<abbr title="Accessibility" style="speak:spell-out;">A11y</abbr>)

GJR: extra query for text attributes needed if attributes are inline style attributes;

GJR: CSS3 braille/embossed module? should be able to IMPORT a stylesheet that matches the users pre-defined localized braille conventions

NS: so, interface needs to be told "render page as if for embossed media"

GJR: yes, something i have to follow up along with other issues with APH - put link in minutes

NS: not sure practical way of dealing with this

PB: text attributes reflect CSS rendered on the screen

GJR: @media type - specific media rules for specific media types: print, aural

NS: MSAA and IA2 have no way of getting at info

PB: assume that's correct

GJR: UAAG 2.0 requirement to have all information about text and characteristics in the DOM or available as API calls for Accessibility APIs

NS: keep discussion going forward through use of handlers list

Topic 2: Upcoming Meetings

JS: gone rest of june (japan then seattle)

VB: can't make 23 july 2008

NS: scheduling -

NS: calendar: current proposals: no meetings on 16, 23, and 7 july

RESOLVED: Next Handlers Calls: 30 June 2008 and 14 July 2008

  • NO meeting 16 June 2008
  • NO meeting 23 June 2008
  • NO meeting 7 July 2008