Please forward to other accessibility lists as appropriate.
Google will be returning to CSUN this year with two presentations
by Google engineers on Web Content and Interaction at Google. In
addition to the talks, we'll be available throughout the
conference to answer user questions and collect user feedback.
here's looking forward to catching up with everyone at CSUN!
Google Presentations (papers attached)
Title: Improving Access to Web Content at Google
When: Wednesday, March 12, 2008, 9:20 AM,
Location: Dallas - Marriott
Level: Intermediary/Advanced
[
content.html ]
Improving Access To Web Content At Google
Table of Contents
1 Improving Access To Web Content At Google
In this first part of our two-part coverage of accessibility at
Google, we will review our work over the last year in enhancing
the accessibility of Web content at Google.
The second part of Google's presentations at CSUN will cover the
accessibility of Web interaction, specifically in the context of
AJAX-based Web applications.
During this talk, we will cover progress on the following topics:
1.1 Making GMail more universally available.
GMail can now be accessed via a multiplicity of user interfaces
ranging from plain old HTML and highly interactive AJAX to
light-weight mobile XHTML.
The now enhanced and fully functional HTML interface is of particular interest to
screenreader users.
The HTML interface has been made functional
by:
-
Fully implementing the various options available under
user Settings --- previously, these were only available through
the AJAX interface.
-
Adding accelerator keys to commonly used actions.
GMail filters, a feature that allows automatic labeling and
pre-processing of incoming mail, is of particular interest to
screenreader users, since it makes for a clean inbox by
eliminating unnecessary clutter.
1.2 Google Books
Google Books provides full-text access to public-domain books.
The site offers a light-weight HTML interface that is
screenreader friendly alongside the original AJAX interface.
Once a book has been located, users can search within a book, as
well as navigate by pages.
Searching within a book populates the page navigation field with
the page number
where the match was found; this makes it particularly easy for
users to jump to a specific spot in a book and read the pages in
the neighborhood of the match to obtain additional context.
1.3 Mobile Google Calendar
Google Calendar offers a light-weight XHTML interface primarily
designed for mobile users on the go. But it provides an
effective means of calendar access for screenreader users as
well.
The mobile calendar allows one to quickly create new events, as
well as to preview one or more calendars using a light-weight
XHTML interface.
1.4 Summary:
And There Is More To Come.
This talk has focused primarily on the accessibility of
traditional HTML content.
The sequel to this talk will focus on the challenges of making
AJAX applications usable by access-enabling them via ARIA.
Creating usable, accessible HTML content is crucial when later
access-enabling rich interaction created through AJAX.
Thus, while basic HTML might sound old-fashioned and boring in a
world dominated by dynamic Web applications,
creating good HTML content is about returning to basics and
is a pre-prerequisite for creating rich interaction that
degrades gracefully.
Author: T.V Raman
<raman@retriever.corp.google.com>
Date: 2007/09/05 10:40:31
Title: Improving Access to Web Interaction at Google
When: Friday, March 14, 2008, 8:00 AM,
Location: Denver - Marriott
Level: Intermediate/Advanced
[
interaction.html ]
Improving Access To Web Interaction At Google
Table of Contents
1 Improving Access To Web Interaction At Google
Our first talk focused on the basics of authoring good HTML
content for creating user interfaces that degrade gracefuly.
In this second part of our two-part coverage of accessibility at
Google, we will review current work over the last year in enhancing
the accessibility of Web Applications at Google.
During this talk, we will cover progress on the following topics:
1.1 ARIA-Enabling UILibraries
AJAX applications are difficult to build and maintain without the
help of reusable libraries.
The best means of building in accessibility into such
applications is to enhance such libraries to generate the
appropriate metadata needed for accessibility.
In this talk, we will describe our experience in ARIA-enabling
core AJAX libraries at Google.
The presentation will cover the following topics:
-
What we built,
-
What we have learned,
-
Gap analysis --- what remains to be done.
In the process, we will also highlight areas that need more work
with respect to fleshing out the underlying ARIA specifications.
1.2 Building In Accessibility From The Ground Up
Here are some of the design principles that we used as a guide
while adding ARIA support to our UI libraries:
-
We would not change the primary visual look and feel except
for fixing bugs, i.e., we would not ask the library owners to
change the behavior of widgets to match how today's adaptive
technologies work.
-
We would add full keyboard support to all widgets as a
usability enhancement, rather than as an accessibility fixup.
-
All widgets would be automatically ARIA-enabled, with no
explicit intervention required by users of the libraries.
-
Widgets should provide the necessary hooks for application
authors to enhance the default level of metadata available in
a generic widget.
1.3 Design Consequences
Applying the design principles enumerated in the previous section
resulted in the following:
-
HTML authors using our access-enabled libraries can be
mostly unaware of ARIA-specific bits.
-
Basic usability features such as keyboard access is
available everywhere.
-
The resulting consistency within Web applications built
against access-enabled UI libraries makes it much easier to
test resulting applications for accessibility. This final
benefit is in fact more generally true about usability
testing.
1.4 Gap Analysis
The area of biggest impedence mismatch between today's access
technologies and
the default look and feel of Web applications
can be attributed to the following:
-
Screenreaders rely on applications setting focus explicitly.
-
Web applications draw user attention by using visual
highlights, rather than explicit focus changes.
-
It is often difficult to get screenreaders to react unless
one sets focus explicitly to the item to be spoken.
-
Setting focus explicitly is often impossible in Web
interaction since that can significantly degrade the
overall visual experience.
These gaps can be bridged to a certain extent using ARIA live
regions --- however, at the time of writing, support for these
ARIA features within screenreaders is still under development.
Author: T.V Raman
<raman@retriever.corp.google.com>
Date: 2007/09/05 10:57:19