W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 2007

DRAFT: UA Telecon Minutes 29 November 2007

From: Gregory J. Rosmaita <oedipus@hicom.net>
Date: Thu, 29 Nov 2007 18:56:19 +0000
To: w3c-wai-ua@w3.org
Message-Id: <20071129185440.M62836@hicom.net>


minutes from today's telecon can be found online at:


and as plain text following my signature...  the IRC log for the call is 
available at:


as usual, any corrections, comments, misattributions or gaps in the 
minutes should be logged by replying-to this post on list...

thanks, and congratulations to jan and mrs. jan!

                                   - DRAFT -

                                 UAWG telecon

29 Nov 2007


   See also: IRC log: http://www.w3.org/2007/11/29-ua-irc



          perente, Gregory_Rosmaita, AllanJ, KFord

          Catherine_Laws, Jan_Richards

          Jim Allan




     * Topics
         1. Accessible style issues for group documents
         2. Alternate View
     * Summary of Action Items


   JA: CLaws will be joining later
   ... Jan is out today and perhaps for a bit - has a new bundle of joy -
   4 weeks early, everyone doing well

   WG: congratulations to JAN and Mrs. JAN!

   scribe's note: WG = working group
   GJR stylesheet action item update (crossover with 2 other actions for 
   2 other WGs):

   comparative stylerules exposed: http://tinyurl.com/yt68z7

Accessible style issues for group documents

   <AllanJ> GJR: discussing current status of work, collaborate with M.
   Cooper and HTML WG

   <AllanJ> GJR: also working with PF for accessible collaborative tools,
   and placed in style guides

   <AllanJ> GJR: use overflow technique from WCAG 2.0 C7 for increased

   <AllanJ> GJR: still negotiating with all parties as screen reader can
   only read 11 named colors.

   GJR thanks JA for minuting his comments

   JA: KF, printed out notes from f2f and there was an action item on
   alternate view?


Alternate View

   KF: went off on a tangent during f2f: talked about collective thinking
   with respect to the fact that if UAs develop more features based on
   actions users taking on web content (find feature, for example) what
   kind of expectations/requirements do we need to give to ensure those
   features are compatible/available to those using alternative views --
   for example, today in IE and FF, different screen readers keep user
   from getting full experience -- getting view provid
   ... with more robust features may not be so simple;
   ... find feature where number of instances of word or string in
   document instance -- AT vendor has to rebuild alternate view (sighted
   user can follow color coding)

   JA: google highlighting feature -- when do search will highlight
   search terms for you to indicate where search string is located;
   sighted user would use scrollbar to find instances, otherwise have to
   read through entire document instance

   KF: architecturally, UA could communicate selected/highlighted state
   thorugh accessibliity API, then AT has to calculate what to search
   for; no clear solution today, but emerging trends in UA dev going to
   be a larger trend; will become more of an issue -- only so much
   wizadry can add to UA chrome -- actions on content one of most
   important aspects; used example of NYT (nytimes.com) which has script
   that enables user to double-click on any word and gets a diction

   JA: keyboard accessible?

   KF: no; not even in caret browsing mode of FF
   ... need to write this up; whether it is a guideline or technical
   notes to existing GLs -- would like to ensure that when people create
   chrome that this level of awareness is included -- have to think about
   x,y, and z; AT vendors shouldn't have to recreate all of this in
   alternative view, because then they are acting as a browser; emerging
   problem that i'd like to see us give more recommendations -- may all
   be P2 requirements, but something need to keep on front

   JA: when google does highlighting, does it appear in DOM?

   PP: yes -- google toolbar or searches?

   JA: thinking of toolbar, but when use search interface and choose to
   view PDF as HTML

   PP: tweaaking stylesheets for effect

   JA: putting class on items

   PP: or just putting style on individual elements

   JA: would that be available to MSAA or IAccessible2

   KF: might get highlighting -- depends on implementation -- DOM
   awareness, etc.

   PP: not selection state change -- just highlight -- probably a span
   with style set; DOM node asserted event, but that's about it

   KF: for AT product is a lot of work to determine what is relevant and
   needs to be reported

   PP: indistinguishable from any other DOM mutation; may need scripts
   for searching for certain types of mutation events -- programmatically
   distinguishing may be impossible

   KF: if google doing something relevant to user base, AT has to write
   custom code -- very page/domain specific code

   PP: even with toolbar, logic would be "if toolbar that does searching
   changes, treat this as change"

   KF: this is just one scenario -- many other scenarios that are more

   JA: for instance?

   KF: go back to nytimes scenario -- or skype -- skype has add-in for IE
   -- inject onclick attributes to any phone number found on page; may
   also have add-in for FF; generic problem: making onClick behavior
   keyboard accessible, but another example of modification of page and
   then changing nature of page content; can be done with scripts, too;

   JA: way to genericize this to a guideline? accessible in that trying
   to provide equivalent fucntionality

   GJR: need not just functionality but awareness of functionality

   KF: ... can solve problem by going to individual AT vendors -- would
   rather go a step above -- user agents recognize that vast majority of
   what is being done depends upon AT to use alternative view -- need to
   get equivalent feature set for alternative view

   JA: falls into a bunch of diff guidelines -- 1.1 device independence
   -- inform that it is there, navigatable, etc.

   KF: if existing GLs already resolve issue, maybe need to explicitly
   tie them together

   JA: is there a greater issue we haven't addressed

   <AllanJ> GRJ: watch UWA, Ubiquitous Web Applicaiton

   GJR: one palce to watch is UWA -- has taken ownership of what used to
   be called device indepence -- XML Events -- XML Events draft dropped
   the purpose element for generic handlers

   KF: need to digest GJR's data dump
   ... try and determine what more we need to do over next few weeks --
   will write something up and post to the list summarizing my thinking


   takeaway from previous pointer: i am a member of the HTML WG and
   currently serve as the liaison between the HTML WG and the AUWG and
   UAWG -- MichaelC is also involved in (or at least closely monitors)
   HTML5 work, and he has done an excellent job of keeping tabs on
   developments in that arena as they may affect WCAG and ARIA; i think
   it is essential at this point in the process, that the AU, GL and UA
   working groups (and possibly the EO working group) immediately

   * Authoring Guidelines for HTML5
   * Authoring Tool Conformance Requirements for HTML5
   * User Agent Conformance Requirements for HTML5


Summary of Action Items

   [End of minutes]
Received on Thursday, 29 November 2007 18:56:37 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:35 UTC