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
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
http://www.w3.org/TR/css-beijing - 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
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