W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 2010

Minutes: User Agent Teleconference for 20 May 2010

From: Jim Allan <jimallan@tsbvi.edu>
Date: Thu, 20 May 2010 13:50:23 -0500
To: "'UAWG list'" <w3c-wai-ua@w3.org>
Cc: <klink@google.com>
Message-ID: <001201caf84d$4df48080$e9dd8180$@edu>
Minutes online: http://www.w3.org/2010/05/20-ua-minutes.html


User Agent Accessibility Guidelines Working Group Teleconference
20 May 2010

See also: IRC log http://www.w3.org/2010/05/20-ua-irc 
Attendees
Present
    JimAllan, KimPatch, Jeanne, GregL, SimonH, MarkH, JonasKlink
Regrets
    kelly_ford
Chair
    Jim_Allan
Scribe
    allanj, gl

Contents

    * Topics
         1. Google Chrome discussion with Jonas Klink
    * Summary of Action Items

<trackbot> Date: 20 May 2010

<AllanJ> Chrome Accessibility Developers site

<AllanJ>
http://sites.google.com/a/chromium.org/dev/developers/design-documents/acces

<AllanJ> sibility
Google Chrome discussion with Jonas Klink

<Greg> Jonas of Google, based in Moutain View, CA. Developer for 4 years at
Google, on a wide range of features, including initial work on accessibility
features that have now been taken over by a team Now focus on community and
overall story. He's part of access engineering team, based mostly in
Mountain View and some in Santa Monica.

<Greg> Introductions all around.

<Greg> Jonas will serve as a resource to UAWG as much as he can, and will
see if others on his team will participate.

<AllanJ>
http://sites.google.com/a/chromium.org/dev/developers/design-documents/acces
sibility

<Greg> Jonas gave an overview. He wrote and maintains an accessibility
design document, which is available on chromium.org.

<Greg> It contains introductory guidelines and goes into detail on the work
he's done.

<Greg> At an interesting point, not as far as they'd like to be, but
development has been slow as for a long time he was the only resources.
Adding API to a multi-process browser has been complicated.

<Greg> Working with screen readers and moving between focusable content with
screen readers should be working fully soon, including the virtual buffer
screen readers require.

<Greg> ARIA support should work on Chrome whererver it's supported by
WebKit, and hope to go beyond that.

<Greg> Work ongoing on MSAA, most places now.

<Greg> Full page zoom in place.

<Greg> Extensions support high contrast, but not Windows high contrast mode.

<Greg> He posts workarounds in his document where he can find them.

<Greg> Jonas has looked at UAAG. Their primary goal has been to be similar
or better support than Firefox; he's worked with David Bolter from Firefox
to try to identify what Firefox does, including in obscure circumstances, to
try to be consistent.

<Greg> They have not worked with Microsoft/IE yet.

<Greg> Kim asked about link numbering; Jonas says it does not exist yet but
interesting concept.

<Greg> Jim asked about HTML5 video, and his concern that there are divergent
interefaces. Jim would like to see a rich set of controls native to the
browser, which the content author can use or skin, or to which they can map
custom controls. Will Chrome provide a rich set of controls?

<Greg> Jonas will look into that question, ask the people in Kirkland
working on the audio and video tags.

<Greg> Jim notes that they hope this will make it into the HTML5 spec, but
certainly will be in UAAG.

<Greg> Jonas notes that, Chrome (Chromium) being open source, he tries to be
as open as possible on accessibility.

<Greg> Jeanne asked about Google's exciting news about protocols on video,
wondered how it handles captioning.

<Greg> Part of Jonas' team is responsible for captioning.

<Greg> They have a close working relationship with YouTube.

<Greg> Kim asked about keyboard shortcuts and discoverability, and about
conflicts between shortcuts in browser and content. Any plans to let users
have easy access to discover and adjust keyboard shortcuts?

<Greg> Jonas says keyboard shortcuts are tricky. Try not to conflict with
browser's shortcuts if they can avoid it, but Google Docs for example does
override browser behavior to provide user-familiar shortcuts for document
editing.

<Greg> Jonas would like to see more keyboard customizability, but probably
more in Chrome OS where they have more control.

<Greg> "AccessJacks" effort at Google allows adding keyboard overlay to Web
apps. In early phases. Trying to standardize between web apps and eventually
want to support greater customizability.

<Greg> Google staff have tried to enumerate shortcuts, but can't provide
shortcuts without conflicting with some browser in some language.

<Greg> Kim suggested ability to share user customizations.

<AllanJ> /me good question!!

<Greg> Jonas said the idea has come up, but just an idea at this point.

<Greg> "AccessJacks" lives on Google Code site, and is live in some
products, and Jonas is revising docs to be easier to start with.

<Greg> Jim notes portable profiles are a UAAG20 success criterion.

<Greg> Jonas notes extensions could potentially support roaming user
profiles.

<AllanJ> gl: are you specializing on chrome or all of google

<AllanJ> jonas: all of google

<AllanJ> scribe: allanj

gl: how closely to the groups including accessibility work together

jonas: a11y is a horizontal group, we belong to all and none
... may embed ourselves in a group, or consult.
... I work mostly with other product managers
... engineers are embedded in product groups
... i focus on research, and broad picture.

<scribe> scribe: gl

<Greg> Mark asks about accessibility to the visual document maps.

<Greg> "Density map"

<Greg> Jonas says no plan yet, would like input/suggestions.

<Greg> Mark asks about ChromeOS. What are they looking at in terms of
accessibility on devices like set top boxes running ChromeOS?

<Greg> Jonas notes that early set top boxes are running Android, so access
solutions in Android should work on set-top boxes, including self voicing,
etc.

<Greg> Re running browsers on set top boxes, have same keyboard model as on
desktop, but just starting to look at how pieces will fit together, re AT
etc.

<Greg> Mark asks about notification API that was in HTML5, and in WebKit. is
it part of Chrome?

<Greg> Jonas will look into that.

<Greg> Mark explained the notification API to let a script in content to
raise notification (e.g. you have new mail).

<Greg> Jonas says it appears to be an experiment one can enable via a
command-line switch, but little documentation.

axsjax

<Greg> Jonas clarified what I spelled AccessJacks is spelled "axsjax".

<Greg> Kim asks how we should report accessibility bugs in Google products.
Jonas said can send to him and he'll open as internal bugs,
klink@google.com.

<Greg> Simon notes his org is building extensions and using axsjax.

<Greg> Jonas asked how would be best way to inform UAWG about updates from
his end. Jim says sending email to the list.

<Greg> Discussion of how to get Jonas officially onto the working group, but
Jonas can contribute and participate without being official.

<sharper> Some initial stuff on YouTube
http://www.youtube.com/user/HumanCentredWeb but I'm still looking for the
AxsJAX demo

<scribe> scribe: allanj

gl: please give your impression of how accessibility is viewed at google

jonas: biggest problem is flat structure of company, and so many things
going on
... philosophy, want to do accessibility, but it needs to be productionized.
low latency, secure, etc.
... challenge to be useful and feasible to create and not slow down, or
break/weaken something
... google is very engineering centric
... work with product managers to specify a11y need, and make a play.
... a11y eng. team is growing
... finding a11y engineers is difficult
... likes to collaborate

<Greg> Does anyone in product groups have responsibility? He works closely
with all review entities within google, e.g. ui review. All new features go
through review process, where he gets to provide early feedback. then
testers live on internal testing list where new feature is announced and put
out for dog-fooding. Acc pieces identified Jonas works directly with product
manager to specify needs....

<Greg> ...They identify resource in their team doing the work, who often
gets paired with person from access engineering team. Just getting to level
where enough resources to work with the major products. Trying to get good
engineers is tough, the gating problem. He enjoys collaborating, he's
personally interested in low vision support in their Web apps. Think they
have a good solution which...

<Greg> ...he'll be able to talk about soon.

<Greg> Jim asks about keyboard access to tooltips.

<Greg> Jonas added such to Chrome UI, but would like to see it in browser as
well, considers it a pet peeve.

<Greg> Jim notes that most Web content has to invent or implement their own
mechanism, lots of code for something that the browser should handle.

<Greg> Jim notes that UAAG20 has a plethora of SC requiring "user has
abilities to" or "user has option". Jim asked where Chrome would expose many
settings.

<Greg> Jonas said Chrome hates options, keeps them to bare minimum, very
difficult to add new ones.

<Greg> Jonas says that instead of options, can be implemented as extensions,
but those can be difficult to find and find out about.

<Greg> He notes that roaming user profiles would allow extensions to follow
users.

<Greg> Kim reiterated need for sharing profiles; Greg noted need to be able
to share particular set of settings without replacing all the other settings
the user has chosen.

<Greg> Simon asked how Chrome might handle decentralized accessibility
concept coming out of HTML5 etc. The idea of extending the language without
formally defining them. Extend HTML5 spec but still validate. Crowd-sourcing
new elements in HTML etc.

<Greg> Jonas recognizes that as a huge accessibility problem.

<Greg> Jim asked if Jonas or his engineers could review UAAG20 and give
feedback, on what's easy, hard, feasible, infeasible, etc.. Jonas offered to
do so.

<Greg> Jeanne notes they'd love to see Google be one of the first
implementers of UAAG20. Roughly a year from finalization, so feedback is
important.

<Greg> Jim asked if AT vendors are actively testing with Chrome, and their
feedback.

<Greg> Jonas said NVDA and Serotek have been the most responsive. Google
also tests with Jaws and Window-Eyes as well.

<Greg> Not much exchange of info with the last two so far; working most
closely with the most responsive companies. Once it's working, will reach
out again to other companies.

<Greg> Re accessibility API on other platforms, Mac one being worked on.
Cocao being used so some is automatic.

<Greg> Other work on Mac in the roadmap. No resource for Linux yet, so that
will be last.

<Greg> Re IAccessible2, it is being implemented now, might be part of most
recent change, extending IAccessible with IAccessible2. Roles and states and
unique ID, window handles, etc., all supported this week. Yet to go is
IAccessibleText, form controls, etc., once virtual buffer is finalized.

<Greg> Should all be updated in the design document he pointed to earlier.

crbug.com google chromium bug tracker

<Greg> We are invited to submit bugs on crbugs.com, the official bug tracker
for Chrome and Chromium. Jonas does triage on all bugs coming in. There's a
change log online covering week by week, and spreadsheet tracking all
accessibility bugs in the main repository.

<Greg> Design document at
http://sites.google.com/a/chromium.org/dev/developers/design-documents/acces
sibility

<Greg> Changelog and issue tracker:
http://sites.google.com/a/chromium.org/dev/developers/design-documents/acces
sibility/tracker

<Greg> Anyone can file bugs, but if you don't have special access to the bug
tracker (not actively developing) then can only file summary and
description, can't provide categorization, and no way to cc a particular
person or team. Therefore best to email Jonas.

<Greg> Kim asks if there's anything Jonas would like from us, and Jonas said
mostly to spread the word on what does and doesn't work.

<Greg> Jim notes that the HTML5 task force bounced most of our issues back
to us to provide more details and specific recommendations.

<Greg> HTML5 has a lot of info on what browsers should do on handling HTML,
and some stuff on user interface expectations and behaviors. Consensus of
accessibility task force is to take that out of HTML spec and put into UAAG
space.

<Greg> Jim noted that we lack resources do to that, so might have engineers
from HTML5 or its accessibility task force work with us on that.

<Greg> Jeanne asked about HTML5 referencing/linking to UAAG, and would
certainly do so if they move behaviors here.
Summary of Action Items
[End of minutes] 
Received on Thursday, 20 May 2010 18:51:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 20 May 2010 18:51:07 GMT