UAWG telecon -- 29 Nov 2007

yes, i can

<scribe> scribe: Gregory_Rosmaita

<scribe> ScribeNick: oedipus

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

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

- DRAFT -

UAWG telecon

29 Nov 2007

Attendees

Contents

Accessible style issues for group documents

Alternate View

Summary of Action Items

Scribe.perl diagnostic output