I just completed a very hectic week at the California State University, Northridge Center on Disabilities' 21st Annual International Technology and Persons with Disabilities Conference
. For those not in the accessibility community this is the largest technical conference on accessibility in the United States.
The major theme at the conference seemed to be around the use of open standards and open source to advance accessible computing for persons with disabilities. Firefox
, recently endorsed by the National Federation of the Blind
, was probably the hottest topic at CSUN. Firefox sessions were overflowing and the Mozilla Foundation
had their own booth at the conference. Handouts at the Firefox booth evaporated withiin the first couple of days. What was most interesting is the accessibility ecosystem building around Firefox. Aside from the IBM announcement of its accessibility contribution to Firefox last year
, a plethora of young talent was showing their Firerfox extensions. One such person, Charles Chen, is working on Fire Vox, a self-voicing browser
The clear message being that through open source accessibility can be advanced without waiting for proprietary solutions.
An Open Document Format
Panel, led by Sun Micrososystems
, was held on Thursday which included myself, Peter Korn, Sun's Accessibility Architect; Janina Sajka, principal of Capital Accessibility and chair of the Free Standards Group
Accessibility Working Group; Myra Berloff, Director of the Massachusetts Office on Disability; Accessibility Architect & Strategist at IBM; Malte Timmermann, Technical Architect for OpenOffice.org
. TV Worldwide
and their AT 508 channel
videotaped thes ODF Panel Session
. The discussion covered:
- the definitions of open standards and open source
- Who uses ODF
- Who is working on its accessibility and the timeline
- Accessibility of ODF
- The history and future of ODF in the State of Mass.
Audience participation was excellent with a lot of very inciteful questions. What was clearly conveyed was that the events surrounding Massachussetts and ODF have been a positive transformation for both the commonwealth and the industry. Through a rapidly emerging open standard we are having very visible transformation around the awareness of the need for accessibility and the opportunity to "raise the bar" on accessibility through an open standard.
Becky Gibson led a presentation on AJAX
accessibility which made use of the Dynamic Web Accessibility
standards work in progress at the W3C. It showed how IBM's leadership helped is helping to drive new opens standards which will drive not only the accessibility of applications like AJAX but also improve the overall accessibility and usability of the web. While IBM initiated the work early adopters showed other early adopters, like Victor Tsaran at Yahoo
, who is developing new web componentry that will improve the overall usable access to the Yahoo site. Like the Firefox session, lead by Aaron Leventhal and Glen Gordon (Freedom Scientific
), the Yahoo
DHTML session was overflowing. Linux
accessibility was gaining momentum as well. Both Sun and IBM demonstrated early versions of their screen readers (Orca
on Linux. George Kraft (IBM) demonstrated IBM's pre-alpha open source screen magnifier
, called gScope. Myself and George Kraft gave a presentation on the IBM Linux Accessibility Project which covered how IBM was contributing code to the open source community to fill gaps in the Gnome Accessibility Project
; API extensions to the Free Standards Group; and enablement to Firefox. Sun continues to lead the Gnome Accessibility Project effort and IBM is joining the effort to accelerate its readiness for end user adoption.This would not be possible without open standards and open source contributions.
While the theme of "open" stole the show I was very pleased at some of the advancements on Windows Vista
. It appeared that many of the key AT vendors were running on Vista. Screen Reader access to Vista used, primarily, a combination of MSAA
and screen scraping to read the desktop. What was most impressive about Vista was its voice recognition support. It was the best demonstration I have ever seen on Windows
of voice recogniation navigation and dictation. Although this is a demo, if it is good as they showed, my hat is off to Microsoft
for doing a superb job of helping users with mobility impairments through quality voice recognition.[Read More
The HTML working group has been working on building accessibility into XHTML 2 from the ground up. Of these, there are two cross-cutting technologies
which will improve the accessibility of a number of existing W3C standards efforts through the use of modularization:
- Role attribute and Meta modules
- Access key replacement called the access element
The Role attribute is now being used to assist in the enablement of Dynamic Web Applications. The W3C WAI Protocols and Formats working group
is developing a new role taxonomy
to be used as common roles designed to support platform accessibility APIs across the Windows
Today's HTML access key is designed to be an attribute on an HTML element whereby the author specifies a key on a keyboard to either give the element focus or to activate the element. Access key has the following serious deficiencies:
- Not every device has a keyboard.
- The author has to figure out what keyboard mapping to use so that his/her selection does not overlap one consumed by the target browser or operating system
- There is no descrliption as to the purpose of the access key
The access element in XHTML 2 is like "semantic sugar" around XML events in that it provides a higher level semantic binding layer that is in-fact deterministic. It has the following advantages and features:
- Assigns navigatio by role or by a target id whereby the target id takes precendence
- Where there is more than one role matching the access element, focus tracking would sequence through each element having the same role in a circular fashion following document order
- By default, an access element sends a focus event to the target element
- The author may assign a tittle attribute which acts as a description of the access element
- The author may choose a particular event handler to be triggered such as an activate by making declarative reference to use of events
- The author may optionally provide a key binding suggestion for which it is up to the user agent and end user to accept or override
I hope to see these move into the XHTML 1.X namespace so that we can incorporate these features in today's markup without using a separate namespace. They are also applicable to other markup like SVG and thus solve a number of problems facing today's web content.
Today, IBM released a full screen magnifier to IBM's emerging technology alphaWorks site called gScope
. gScope is the first full screen magnifier solution on Linux to use of the new composite extension
to X. Composite allows for redirecting of drawing commands to an off-screen buffer and then uses a compositing manager to decide how the windows will be arranged on the screen. While this facility can be used to create things like translucent windows it also may be used to allow for fast magnification.
Screen magnifiers on Windows have used drivers to redirect drawing calls into free memory on the card and then perform direct transfers to the screen using memory transfers on the card. This makes screen magnification fast. gScope uses composite to capture drawing calls redirected the desktop to create a managed off-screen buffer of it. gScope then works with the composite manage to copy the end result to the desktop in a magnification operation using the video hardware.
Before composite, magnification was peformed using system memory and the results provided were slower. The new magnifier will allow for magnification levels from 2 to 16. It can operate in full-sceen, line, lens, or docked window modes. In the spirit of open source this will come with source code and documentation. While this is an alpha release it is robust enough to allow distros to pick up the work. Strategically, the best place for this is in the Window manager as there can only be one composite manager running at a time. By providing an open source solution, KDE
and other UNIX desktop providers may get magnification for low vision users sooner rather than later. This fills a critical gap in an accessible Linux desktop offering.[Read More
Open Document Accessibility subteam had its first meeting today. Technical Accessibility leads from industry and accessibility advocacy were present. Sun and IBM brought along leads from accessibility architecture, strategy, and research.
The first deliverables from the group will be to perform an ODF accessibility gap analysis of competing document solutions and produce use cases to improve the usable access to documents. We will use this analysis to take industry beyond the level of accessibility experienced today.
I have had opportunities to work with most of the members on various standards efforts and research projects such as for Java accessibility
, W3C WAI
efforts, and middleware transcoding for seniors - but never together as one team.
I expect a home run to be hit by this group. Together, with our assistive technology vendor relationships, we will make a difference and raise the bar. Having ODF as an open standard will result in the broadest industry impact.[Read More
The most visible accessibility battle since the threatened boycott of Microsoft products is now center stage in the state of Massachusetts. It is center stage because the state of Massachusetts wants to move to an Open Document Format (ODF)
for which accessibility has not yet been fully addressed. To prevent its adoption those who supply a claimed compliant accessible office suite are pushing to have it overturned. While accessibility issues exist with this new format and its deployment it is important to note that these problems can be fixed. I can, in fact, remember when the proprietary office formats the state currently uses were not accessible at all. With effort, the accessibility story will improve. So, the real questions that need to be asked are:
- Can an accessible solution be provided?
- If so, can the time needed to do this be warranted?
- Can an accessible solution be provided in the interim?
- Can work in this space produce more accessible solutions?
- Can the cost of an accessible solution targeted at open standards and open source solutions benefit the user?
On November 5th I attended an ODF summit sponsored by IBM and Sun at the IBM Learning center in Armonk. The event was clearly about history, preserving state sovereignty, and putting a roadmap together for an accessible solution. My presence here helps to answer these questions.
1. The answer to this is of course yes. IBM is in fact doing that now for Workplace.
2. To answer this question it is important to understand the motivation behind Peter Quinn's move to take the state from proprietary to open formats and from proprietary to open source. In other words how did the state get to where they are today. This was captured in his "Open Format Freedom Fighters Forum" keynote. The state has a $24.4B dollar budget: 90,000 employees and contractors, with an annual IT spend of $700M. In 2003 it's challenges were massive legacy applications, limited maintenance, lots of heterogeneity, few sustainable processes, and the need to preserve history in a format that is accessible by all. This created a "perfect storm" analogy that seldom comes around.
The state's path to open standards and open source is an effort to bring some "common sense" to the commonwealth where they can build solutions that everyone else can have. The CIO office wanted to share code across state boundaries but the lawyers prevented it. They also wanted to preserve history in their documents. Much of the states documents are in proprietary document formats. Newer proprietary formats are not always backward compatible. Over time the loss of state history becomes a serious concern. Peter gave the open standards analogy of a toilet for which I will try to summarize:
Today you buy a toilet and no matter how many features it has you may install it in your house without a lot of worry. The reason is that all houses have a standard drain pipe, standard wax seal, and standard water hook ups. Now if you follow the "Gates model" you go out and buy the new Microsoft toilet that requires a special sized drain pipe when you build your home. Twenty years later the toilet breaks and you need to go buy a new one. You find one you like and you bring it home for installation and discover that the new toilet does not fit the drain. You find that in order to install it you need to buy the special "Balmer adapter." This assumes someone is still selling the adapter. The state's concern is best captured in a recent David Berlind article
. Simon Phipps (Sun) summarized it in one of his witty one-liners: "ODF is about avoiding corporate Alzheimer's."
The concerns of the state go far beyond saving money on licensing costs for proprietary solutions. Preserving history and bringing sanity to the state are more than valid reasons for the state's moving toward an open document format. To do this, the state should take the time to produce an accessible solution. It was clear that Peter Quinn wanted to make that happen.
3. An interim solution can be defined; in fact they have an accessible solution now. The state should execute on a parallel track to work with industry to build an accessible solution.
4. There is definitely an opportunity to build a more accessible solution. The existing office products are considered accessible because assistive technology vendors support them. However, just because a company claims they have accessibility support does not always mean they have a usable solution. At IBM the accessibility and usability of PowerPoint documents is a real problem. We have an opportunity for the industry to build more accessible document formats and think solidly about how they can be delivered interoperably with assistive technologies to improve their usability. We have an opportunity to garner user involvement up front and use that to impact the design of the accessibility support. We can also do this on more than one operating system. Members of OASIS
at the meeting agreed to form a subcommittee to address the accessibility of ODF.
5. Today blind users of IT will go out and purchase a screen reader. The cost of that screen reader can run up to $1400. Some assistive technologies are customizable and others are not. If solutions were open source it gives an opportunity for users and industry to enhances the assistive technology solution without waiting for the latest update. Furthermore, users would not be required to purchase such solutions. The use of open standards for interoperability allows for commonality of the infrastructure. This is a real problem on Windows where platform evolution has resulted in a plethora of proprietary APIs
, used for accessibility, and is arguably one of the reasons for the high prices of Windows assistive technologies. Comprehensive open standards for accessibility, like those being developed for Gnome, reduce the cost of ensuring an interoperable solution as ell as the time to market for an assistive technology. When I worked on Screen Reader/2 it took us 3-4 years to build a screen reader. At this time, no comprehensive accessibility API existed. When we developed the Self Voicing Kit for Java it took us 6 months to build a working solution and with a greater level of accessibility. This was because we had developed a single, engineered, accessibility API.
Despite the obvious benefits for moving to open formats, Peter has an uphill battle. The senate oversight committee wants to remove control of how IT is specified away from the state's IT department. Peter Quinn had 3 bullets to describe this in his pitch:
- creates total gridloc
- defies logic
This debate most assuredly will rage on. Meanwhile, members at the ODF Summit are forging plans to meet the state's ITD accessibility goals. Some of these members include IBM and Sun with extensive accessibility skills and resources.
Like many in the industry I have been reviewing and helping to define what accessibility features appear in UI Automation (UIA)
. UIA addresses a number of gaps in Microsoft Active Accessibility (MSAA)
At a high level some of these gaps are:
- access to text
- access to tables
- role and state implementation restrictions due to integer sizes
- some reduction in enablement by the author
- use for automated testing
Microsoft's challenge will be to move people to it. Today, accessible Windows applications are based on the use of a plethora of API and reverse engineering mechanisms. These consist of: MSAA; Proprietary COM access to an applications Document Object Model (MS Office, Corel, IE, etc.); the Java Access Bridge; graphics engine hooking to access to text, carets, and selected information, and more.
In the near term Microsoft is working to map MSAA to a single UIA API layer but due to problems with MSAA's specification implementations may vary and the end result will be that this will be unrealistic. At the moment access to UIA by an assistive technology is through managed code. This requires AT vendors to rewrite from scratch or integrate a managed extension to their assistive technology. Access to legacy applications by an assistive technology will result in a performance hit. ATs will have to communicate from a managed application across boundaries to legacy applications resulting in slower access. A positive step forward would be for Microsoft to release an unmanaged client API version for assistive technologies. Like any mature company Microsoft will be forced to support their legacy infrastructure or risk breaking the accessibility of existing applications. In short, this will be a long process.
While a significant step forward for Microsoft, there are some rather significant gaps in UIA that need to be addressed:
- Performance: The performance problem will be a real barrier to implementation on large documents where large amounts of information must be cached and processed by screen readers. To address this for Linux, IBM is working with the Free Standards Group to extend the accessibility API to support large documents defined as the collection interfaces. These interfaces run in the ATK bridging layer without additional work by the application developer.
- Device Independence: Support for multiple actions for device independence. These are provided in the Java Accessibility API as far back as 1998 and are now in the Linux GAP architecture.
- Support for relationships: This also was provided in Java and now in GAP. These are essential for diagrams, flow charts, groupings, etc.
One of the things that would have given UIA more traction would have been to get UIA into the open source community to get more backing as a cross-platform accessibility API where we would focus on a Linux implementation. I had originally suggested this to their director earlier this year and he expressed interest resulting in this public commitment
. Unfortunately, industry has yet to see a license agreement to review after months of waiting and we were forced to move on to alternatives.[Read More
Well, I just got back from SCUBA diving in Fiji where my wife and I went diving on the Fiji Agressor II. Here is the captain's log
. The vis. was great at 125 feet. We had a great shark dive at Nagali Pass where I saw the biggest green moray. Initially I thought the reef moved but it turned out to be a moray with a diameter of about 18 inches and 8-10 feet long. It felt like flashbacks of The Deep
On Tuesday this week I was interviewed on the the Computer America Talk Show and spoke on DHTML accessibility. For those that are interested here is the link:
Craig Crossman was a great host.
IBM's AlphaWorks site recently launced an accessibility topic
to host technologies that aid in the production of accessible solutions and which themeselves are assistive. AlphaWorks is a great venue for this effort as developer's can take these for a trial run, provide feedback to the developer or researcher, and in some instance decide to license the technology. I used alphaWorks when we wanted user feedback on the Self Voicing Kit for Java. Often, researchers develop technologies in a vaccum due to a broad range of obstacles. AlphaWorks is a way to get over the hurdles.
A number of technologies are currently posted on the site. I will discuss three:
aDesigner: This is a disability simulator for people with vision impairments. What I like about aDesigner is it is the only tool I am aware of which can simulate some visual disorder such as the effects of aging on the cornea and how it distorts visions for our aging population. It also simulates issues with color blindness which are difficult to perceive for those that are not impaired.
KeyboardOptimizer: Operating systems have a number keyboard accessibility options to help users with motor disabilities to type more easily and accurately. They depend on the user configuring these settings manually. There are also numerous settings that may need configuring to address your needs. Your needs may also change over time. This technology adapts to the individual as they type. It monitors how you interact with your computer and adjusts the keyboard response to meet your needs. This technology, developed by Shari Trewin
and is an accumulation of years of research.
Web Adaptation Technology: This is a project led by Vicki Hanson
is a technology that adapts web content for Seniors. This project originally sarted as a Web transcoding server research project for which I was a technical lead, in 2001, called the Web Accessibility Gateway
. Today this is an add-on to Internet Explorer. We have a number of IBM customers using this and it is has a number of adaptions for seniors including: magnification, TTS of selected text, smart page linearization, varying color schemes, and the KeyboardOptimizer.
Should these technologies appear in IBM products or would you like to use them yourselves? You decide. I encourage developers to provide feedback to these researchers.[Read More
Well, accessibility awareness has hit the mainstream. The November 3, 2005 IBM Systems Journal
is dedicated to accessibility.
As an author I just received my early copy. The article I co-authored covered accessibility requirements for users with vision impairments
. Section 10, "Lessons learned - Microsoft Windows Today" covers the evolution of accessibility on Windows. Windows accessibility has evolved over time and it provides an excellent example of what can happen when a comprehensive accessibility architecture and strategy are not employed up front. Today, producing accessible solutions can be a very expensive proposition on Windows due to interoperability problems.
I look forward to reading the article entitled Semantic triage for increased Web accessibility
since we are using semantic web concepts to address the accessibility of Dynamic HTML.[Read More
Today, IBM announced one of its accessibility contributions to the open source community
to be realized in the release of Firefox 1.5
Let start with Internet banking. Banks need to support a broad range of customers, including seniors, blind, low vision, and mobility impaired users. All of these customers have difficulty using a mouse. Web authors can now create the keyboard functionality, look and feel, and accessibility of the GUI. Users, accustomed to the keyboard navigation of a GUI will appreciate this for two reasons.
- GUIs hide information until you need it (menus, scrollable spreadsheets, expandable, collapsible trees
- User can tab to significant areas of their document, including GUI like widgets and then use the arrow keys to navigate within the widget (spreadsheet, menu) rather than being forced to tab to every active and visible element, that could be hidden by these widgets, or worse being forced to access alternative content reducing the user productivity.
Another business opportunity is education. Imagine a college, who has to get their students registered for classes, manage their scholarships and loans, view the school calendar, or possibly manage their own dynamic calendar. My own daughter will be attending college for the first time this year and I am keenly aware of the opportunities for this technology. Students want to use Windows, the Mac, and Linux to access the same information. Site administrators have to address all of these issues and having to support a fat operating system GUI for all these operating systems that is accessible just is not in the cards. Like a GUI, RIAs can hide much of the information until it is needed without having to navigate through pages of static content. For users who are blind this is a huge productivity gain. Also, these UI can be spoken with rich information, as in a GUI. For example, a blind user can hear their screen reader announce they are on a menu and it as a popup. A user who is blind may also hear verbose contextual information such as: you are on a notebook tab x 1 of 2.This is clearly a paradigm shift.
As the article states, this is part of an ongoing effort in the W3C
which IBM is leading to make RIAs accessible. Like all W3C recommendations this will need to have industry implementation. Firefox is the driving factor in making this a reality. Furthermore, IBM is working with AT vendors to support the technology. Currently, GW Micro
and Freedom Scientific
have versions of their screen readers in private beta using Firefox and users are raving about it. With these efforts around Firefox in place, developers can now start to develop accessible RIAs today rather than wait.
Going forward, Firefox is uniquely positioned to deliver the business opportunities of RIAs. It runs on multiple operating systems. Authors can enable their web content once and render it Firefox on multiple operating systems. Going forward, Firefox is being geared to support the accessibility infrastructures on both Linux and Windows.
The accessibility standards targeted at supporting RIAs may be rendered on Internet Explorer as well as Firefox and in fact make use of the keyboard support and the ability to drive magnification like Firefox. Unfortunately, Internet Explorer currently does not support this new emerging standard with screen readers. Businesses and federal agencies evaluating their browser strategy should take another look at Firefox 1.5 when it's released with the benefits of RIAs in mind.
See the HTML Accessibility Preview
for more information on the Firefox accessibility effort on RIAs.[Read More
alpha. We were able to achieve the usability and accessibility of Windows desktop applications:
- keyboard access just like their GUI counterparts
- contextual information in line with their GUI counterparts. (Number of tabs in notebook announced. Tree depth of a focused tree element, etc.)
- Role and state information announced as you would find in a GUI
We showed this to technical leads at Yahoo and AOL and the opportunity for creating accessible, Rich Internet Applications and delivering desktop solutions on par with a rich desktop applicaions was apparent.
Completion of this project will accelerate the standards effort. As we speak a cross-cutting, self describing role taxonomy and accessibility property specficationa are getting close to working draft based on proven implementations. Industry involvement to the standards effort is now growing with the addition of Adobe. The work being developed is cross-cutting in that it has applicability to:
In the current Deer Park Alpha
of Firefox, XUL makes use of the same accessibility extensions for XHTML to enable some of the custom GUI widgets found in the chrome.
Another side-benefit of this work is the creation of a new role called "presentation." The use of the presentation role tells the browser that there should be no accessibility API support for a particular document element. This can be applied to table elements to indicate that the content is only presentational and for assistive technologies not to process the table elements as a table. This eliminates the need for authors to use a special style sheet to reproduce table formatting. DHTML often uses tables to produce the visible formatting needed for rich GUI-like elements. Indicating to the user agent and assistive technology that an element is only presentational removes the burden of guessing when to treat markup as presentational vs markup containing significant semantics which might impact the user experience.[Read More
Due to a large investment by IBM and the Mozilla community. Firefox is becoming as assessible as IE on Windows. The latest GW Micro private beta for Window-Eyes has support for Firefox, including support for the up-and-coming W3C accessibility effort to support scripted web content.
To find out more about Firefox accessibility check out the Accessible DHTML Preview
. Aaron Leventhal
is leading the Firefox enablement effort in Mozilla comunity.
Window-Eyes screen reader beta testers have indicated that they have faster access to the Web than IE.[Read More
Some readers may have been following the progress of the accessibility of Linux desktops. The two main desktops being targeted for accessibility in the industry are Gnome and KDE. Both desktops use on the accessibility architecture defined by the Gnome Accessibility Project
. The architecture builds off work IBM did with Sun on the Java Accessibility API back in 1998.
There are a number of, what we call, "gaps" in the total GAP solution. These are in the areas of assistive technologies and accessibility infrastructure performance. To date, the main screen reader on the platform, Gnopernicus
, and the provided magnification solutions are not what users come to expect on a Windows system. Gnopernicus, is not scriptable which allows developers and end users to customize the audio interface. Magnification, today, is also limited to a window rather than full screen.
A shining star on the platform is the Gnome Onscreen Keyboard
which benefits from GAP. GAP provides the list of named actions on accessible objects as well as a list of all named hypertext links in applications. The breadth of support on the Windows platform is lacking in these areas.
A more pressing issue which effects the quality of screen reader support is the provision for solid, performant document access for large applications. The problem areas are Open Office and Firefox. The accessibility architecture on GAP attempts to restrict people from gaining access to document structure. The existing API depends on numerous cross process calls to get access to information in large documents resulting in inadequate performance. Also, the use of the GAP ATK API
is inadequately documented making it difficult for application developers and assistive technologies, new to the platform, to discover how to enable their products or write new assistive technologies. The performance of Open Office accessibility is also impaired by using the Java Access Bridge to implemant an accessibility API bridge between Open Office and the ATSPI
. ATSPI is the CORBA-based communication layer through which assistive technologies acquire the accessibility information from the GAP architecture.
To address these issues, IBM has recently become active in the open source accessibility effort through its work in the Free Standards Group. IBM is in the process of proposing API extensions to ATK
and the ATSPI
to improve performance and improve access to large documents. Also, while being dormant on the screen reader front since Screen Reader/2 and the Self Voicing Kit for Java, IBM is developing plans for an open source Linux screen reader.
Also, last year IBM released Via Voice TTS for Linux through Wizzard Software
. It is available in Simplified Chinese, German, Spanish, Finnish, French, Italian, Japanese, Mexican Spanish, Brazillian Portuguese, Traditional Chinese, US English and UK English. We felt releasing Via Voice was essential for Linux due to its high quality at high speeds and the breadth of languages it supports.[Read More
DHTML Accessibility Accessibility is rapidly becoming a reality. A Technology Preview
may now be seen on the Mozilla site. The demonstrations should be viewed with the latest nightly build of Firefox. These examples will work with the latest version of the Window-Eyes beta.
CSUN has posted the HTML version of our CSUN pitch
. Which describes the technologies and implementation techniques. This presentation introduces the developer to the taxonomies being created which describe GUI componentry for DHTML accessibility. The taxonomies and their corresponding schemas will provide the framework for creating custom components and providing a mechanism for self-description. The plan will be to use these taxonomies to drive browser adaptation to support native platform accessibility APIs and tool validation in the future.
What is most exciting about this work is a fundamental paradigm shift whereby web pages can behave like a GUI while being fully accessible. The user agent can then map the meta data provided to the accessibility api on each platform without additional heavy lifting on the developer's behalf.
IBM is driving this effort through the W3C Web Accessibility Initiative with the plan that this be an open standard for all to use. Firefox is the leading implementation mechanism for this standard.[Read More
Last week I attended CSUN's 20th Annual International Conference "Technology and Persons with Disabilities."
The demonstration was rendered in a nightly build of Firefox while being spoken by the Window-Eyes screen reader
, from GW Micro and while being magnified by the Windows Magnifier.
When entering the menu, Window-Eyes announced "menu activated." It was able to read each of the menu items as well as the state of those that were disabled.
Spread sheet navigation announced changing row and column header inforamtion as well as whether the user were on a row header, column header, or spreadsheet cell. When an enter key was performed on a cell, Window-Eyes would announce the column header followed by the editable cell and its contents. It would echo text being entered. When cell editing was complete it announced the new contents.
The Window magnifer followed user focus as the spreadsheet cells and menu items were navigated.
This paradigm shift showed that it is now possible to deliver the kind of usability and accessibility that we can expect from an accessible GUI today in a web page. This allows for the delivery of accessible dynamic applications on multiple operating systems without the weight of a GUI.
The industry response was fantastic. We have seen interest from SAP, Google, AOL, Sun and others. Roundtable discussions included the construction of reusable open source DHTML widgets which could be incorporated into tooling for reuse by the industry.
It shows what you can do through open standards and industry cooperation.[Read More