W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2005

RE: DHTML Accessibility - Fixing the JavaScript Accessibility Problem

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






graycol.gif
(image/gif attachment: graycol.gif)

pic24299.gif
(image/gif attachment: pic24299.gif)

ecblank.gif
(image/gif attachment: ecblank.gif)

Received on Thursday, 17 March 2005 15:09:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:36 GMT