- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Thu, 17 Mar 2005 08:12:57 -0600
- To: "Roberto Scano (IWA/HWG)" <rscano@iwa-italy.org>
- Cc: techlunch@smartgroups.com, w3c-wai-gl@w3.org
- Message-ID: <OF025C66F3.E7381016-ON86256FC7.004BE49C-86256FC7.004E170B@us.ibm.com>
Great questions Roberto.
1. User Agent and device support
If the web application developer *wishes to support* a platform which does
not have JavaScript then they will have to provide alternative content.
Again, it will be up to the web application author to make this decision.
This problem exist today for more than just JavaScript. For example, each
browser has different levels of CSS support and the author will need to
plan for the discrepancies among user agents. Microsoft has not updated
their CSS support and it is incredibly outdated at this point. This limits
what you can do on IE translating to more work on the web application
developer.
When IBM targets platforms to deliver web applications they have to look at
their HTML, CSS, JavaScript, DOM support, device capabilities, etc. User
Agent support of EcmaScript certainly makes the JavaScript portability
problem less - but all are factors. In most cases, determining the level of
support by a user agent can be done by examining the requester's user agent
information from the request header. At the server, there are many
decisions made before the actual content is sent to the user agent. Not
that this is the case for you but there has often been a misconception that
this is only a JavaScript issue.
We will discuss in the presentation on how we will require less JavaScript
in the future through the introduction of declarative markup and new W3C
standards.
2. Accessibility API support
This is another terrific question. As you will experience in this
presentation, it is up to the W3C to provide the content which can support
the accessibility api on the platform. What we have done in this effort is
add additional meta data to the web content to allow the author to provide
information needed to support the accessibility API on the platform. From a
W3C user agent perspective this information is provided in the Document
Object Model so that an assistive technology may use the information
directly or so that the User Agent may take the information and map it to
the Accessibility API on the platform. As part of this work we did an
assessment of Gnome and Windows accessibility information and provided meta
data in the the web content to that these APIs may be supported by the user
agent. In our example we have Firefox mapping this information to the MSAA
on Windows. As a result we were immediately able to drive the Windows
magnifier. We also have Window-Eyes responding to and reading information
in the web page as if it were an actual accessible GUI application on
Windows. These new custom web widgets actuall behave like you would expect
in a gui raising the usability and "ease-of-access."
Cheers,
Rich
Rich Schwerdtfeger
STSM, Software Group Accessibility Strategist/Master Inventor
Emerging Internet Technologies
Chair, IBM Accessibility Architecture Review Board
blog: http://www-106.ibm.com/developerworks/blogs/dw_blog.jspa?blog=441
schwer@us.ibm.com, Phone: 512-838-4593,T/L: 678-4593
"Two roads diverged in a wood, and I -
I took the one less traveled by, and that has made all the difference.",
Frost
"Roberto Scano
(IWA/HWG)"
<rscano@iwa-italy To
.org> Richard
Schwerdtfeger/Austin/IBM@IBMUS,
03/09/2005 03:56 <techlunch@smartgroups.com>,
PM <w3c-wai-gl@w3.org>
cc
Subject
RE: DHTML Accessibility - Fixing
the JavaScript Accessibility
Problem
Great. There will be a demo-page?
What about alternative versions for no-js browser (like my pocketpc)?
Btw, as in other w3c recommendations and also in ISO/TS 16701, where
suggest to use accessibility API granted by O.S. (eg. MSAA, Java
Accessibility API).. in case of javascript, who set these API?
If we refer to the only javascript that could be defined as "standard"
(ECMAscript), ECMA has the role to define these guidelines.
----- Messaggio originale -----
Da: "Richard Schwerdtfeger"<schwer@us.ibm.com>
Inviato: 16/03/05 22.39.45
A: "techlunch@smartgroups.com"<techlunch@smartgroups.com>,
"w3c-wai-gl@w3.org"<w3c-wai-gl@w3.org>,
"w3c-wai-gl@w3.org"<w3c-wai-gl@w3.org>
Oggetto: DHTML Accessibility - Fixing the JavaScript Accessibility
Problem
I want to take the opportunity to tell people about a session Becky
Gibson
and I are hosting at 8am, Saturday, at the Hilton during the CSUN
conference. This session addresses one of the most important issues for
accessibility on the web which is fixing what is perceived as an
accessibility problem with JavaScript and yes we will show you a
working
solution which we believe should excite the audience by virtue of the
fact
that we are addressing not only the accessibility but the usability of
web
applications and how this solution is applicable to multiple desktop
environments including Linux.
Here is a brief introduction for those able to attend:
JavaScript is found on over 50% of all web sites today, dramatically
affecting the ability for persons with disabilities to access web
content.
An increasing number of web applications are utilizing JavaScript to
mimic
desktop widgets like menus, tree views, rich text fields and tab
panels.
Web developers are constantly innovating, and future applications will
contain complex, interactive elements such as spreadsheets, calendars,
organizational charts and beyond. Until now, no accessibility solution
has
existed for these advanced web applications -- even if a web developer
wanted to do the right thing.
Custom widgets are not a new problem. For years, desktop GUI frameworks
have made it possible to develop accessible versions of custom widgets
through several methodologies. First, GUI frameworks allow developers
to
make any widget focusable and tab navigable. Second, GUI frameworks
provide
accessibility APIs to facilitate interoperability with assistive
technologies such as screen readers. These APIs allow a developer to
provide the information that assistive technologies need -- such as the
"who, what and where" of any custom widget that a user can interact
with.
IBM is leading an effort in the W3C to create a similar accessibility
solution for JavaScript-based web applications. This session will show
how
the problem is being solved and how you will actually end up with a
much
more usable as well as accessible web application. Using standard XHTML
technology in today's browsers it will show how you can create a rich
desktop experience on a web page. We will be demoing a web page with a
real
menu and editable spreadsheet in the Firefox browser and show it being
spoken by Window Eyes and magnified using the Windows magnifier. This
session will cover the W3C road map for fixing this problem in the near
term and the longer term plans to integrate more accessibility
technology
into W3C specifications. The end result will be a much more accessible
and
usable experience for all. For those wishing to deploy easy-to-use
applications through your browser, this is a must see.
Time and location: 8:00 AM, Saturday at the Marina room in the Hilton
Hotel.
http://www.csun.edu/cod/conf/2005/proceedings/2524.htm
Rich Schwerdtfeger
STSM, Software Group Accessibility Strategist/Master Inventor
Emerging Internet Technologies
Chair, IBM Accessibility Architecture Review Board
blog: http://www-106.ibm.com/developerworks/blogs/dw_blog.jspa?blog=441
schwer@us.ibm.com, Phone: 512-838-4593,T/L: 678-4593
"Two roads diverged in a wood, and I -
I took the one less traveled by, and that has made all the
difference.",
Frost
Attachments
- image/gif attachment: graycol.gif
- image/gif attachment: pic24299.gif
- image/gif attachment: ecblank.gif
Received on Thursday, 17 March 2005 15:09:25 UTC