- From: Gregory J. Rosmaita <oedipus@hicom.net>
- Date: Thu, 29 Nov 2007 18:56:19 +0000
- To: w3c-wai-ua@w3.org
aloha! minutes from today's telecon can be found online at: http://www.w3.org/2007/11/29-ua-minutes.html and as plain text following my signature... the IRC log for the call is available at: http://www.w3.org/2007/11/29-ua-irc 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! gregory. ------------------------------------------------------------ - DRAFT - UAWG telecon 29 Nov 2007 Agenda [http://lists.w3.org/Archives/Public/w3c-wai-ua/2007OctDec/0054.html] See also: IRC log: http://www.w3.org/2007/11/29-ua-irc ------------------------------------------------------------ Attendees Present perente, Gregory_Rosmaita, AllanJ, KFord Regrets Catherine_Laws, Jan_Richards Chair Jim Allan Scribe Gregory_Rosmaita ------------------------------------------------------------ Contents * 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): http://www.w3.org/html/wg/tracker/actions/24 http://html4all.org/wiki/index.php/DraftStyleSheetIssues 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 accessibility <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 complicated 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 http://lists.w3.org/Archives/Public/w3c-wai-au/2007OctDec/0049.html 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