- 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