User Agent Accessibility Guidelines Working Group Teleconference -- 20 May 2010

<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/accessibility

<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/accessibility

<Greg> Changelog and issue tracker: http://sites.google.com/a/chromium.org/dev/developers/design-documents/accessibility/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.

- DRAFT -

User Agent Accessibility Guidelines Working Group Teleconference

20 May 2010

Attendees

Contents

Google Chrome discussion with Jonas Klink

Summary of Action Items

Scribe.perl diagnostic output