The W3C Web Accessibility Initiative (WAI) Protocols and Formats (PF) working group announced the second working drafts of ARIA specifications this week. Accompanying these specifications is a new high level ARIA Suite Overview of the effort that was created out of the WAI Education and Outreach Working Group.
There are a number of enhancements which developers and project managers should be aware of :
States and Properties:
- Features which reduce the code needed to add ARIA accessibility support: owns, activedescendent
- AJAX live region support: live, atomic, relevant
- Improved support for trees: level, posinset, setsize
- A datatype specifications for values
- A flowto mechanism to allow logical navigation of flow beyond DOM structure
- Ability to detect sorting mechanism such as in a grid column: sort
- The log role to support web chat sessions
- Enhancements to the RDF role taxonomy to accomodate AJAX
The live region support is clearly the most important. Live regions are portions of your page which may be dynamically updated, using AJAX techniques, without requiring a page reload. We now have a way to tell an assistive technology whether a region of the web page is live as well as how (atomic, relevant) and when (live) to handle the updates to that region. Through the use of the controls property an assistive technology may detect how one object controls another such as a live region. For example, a region may control an entirely different portlet.
These updates constitutes critical semantics that have been needed for web and desktop applications for some time.
I just finished reading Brian Bergstein's fine article, "Designers Work to make the Web Accessible," Aaron Leventhal, Cynthia Ice, and Becky Gibson gave a great interview. The article was heavily screen reader centric when in actual fact IAccessible2 has extensive mobility access features that well voice recognition and dictation systems as well as onscreen keyboards. IAccessible2 supports features that allow voice recognition systems to edit text in a document without having to simulate expensive system keyboard and mouse input functions. Furthermore, IAccessible2 support collections of named actions, and/or hypertext links, which may be exported by an application for enumeration in an onscreen keyboard.
Here are just a few of the recent articles that went out in latin america:
Here are a few of the many launched in China:
Again, many of these articles have been blind centric. I expect that is because our early demonstrations have been around screen reading. As IAccessible2 continues to grow we will see much broader assistive technology support.
Application vendors and toolkit providers are already jumping on board. Trolltech was one of the first as seen by their reference on the Qt blog. So, who uses Qt? ... Google Earth and Skype for starters. It would be nice to be able to improve access for mobility impaired uses for both products. Google Earth would be a great use of IAccessible2's IAccessibleAction interface.
A principle-based approach
WCAG 2.0 focuses on a principle based approach for all Web delivered content and applications and on core interoperability between assistive technologies and applications. It also removes the absolute restrictions on the use of non-HTML technologies. Instead, WCAG 2.0 offers some criteria for selecting technologies that are accessibility supported and can therefore be relied upon to be supported and enabled in the user's browser and assistive technologies. This approach should enable WCAG 2.0 to be a lasting Web accessibility standard and avoid becoming outdated in the near future. It is inevitable that new Web technologies will continue to be developed. Once they contain sufficient features to allow conformance with WCAG 2.0 and are supported by assistive technologies, then they are considered accessibility supported Web technologies and can be relied upon on WCAG 2.0 conforming websites.
Two other key positive features of WCAG 2.0 are the supporting documentation and test criteria. Even though the volume of supporting documentation seems overwhelming at first, the Quick Reference is a convenient tool that most developers will want to use to quickly index into the information that is most relevant to them. Testers and evaluators will be pleased to have documented test criteria for each technique. In a parallel effort, the W3C WAI-ARIA work will produce test suites with lots of source code which may be included in the plethora of techniques already provided.
The broader perspective
It has been said that WCAG 2.0 is more complicated than 1.0. There have been some improvements in the language since the last draft that should make it easier to understand. My strong belief, however, is that WCAG 1.0 is less complicated only because it addresses one simple scenario - static HTML websites. Given that it was the first specification of its type, this is understandable for a 1.0 version. We really needed a 2.0 version a couple of years ago as the Internet has changed significantly since 1999. It's not just about static HTML websites anymore. Fortunately, it looks like the wait is almost over. The WCAG working group should be commended on a fine job bringing this effort to its current state. Developing a set of accessibility guidelines that are testable and address a broad range of Web technologies is very challenging and is changing the way people think about accessibility.[Read More
Over the last few months, we have been working with customers on their open client initiatives, and have come to better understand their requirements in this space. It is clear to us that enterprise focus is on applications that leverage cross-platform capabilities such as Mozilla, AJAX, and Eclipse, rather than on native applications for Linux. We have been working in the W3C on ARIA as well as working with the Eclipse community on all aspects of the client from open standards to implementations. Our approach has always been one of shared contribution and investment with the open communities that we participate in. Our decision to focus our accessibility efforts above the Linux operating system itself should in no way be construed as lack of support for Linux as a client operating system or accessibility as an important characteristic. We have full faith that our efforts, combined with those of the broader Linux community and the projects that support it, will continue to strengthen the arsenal of accessible solutions based on open client infrastructure.[Read More
As you can tell from my blog I have been deeply involved with the ODF
accessibility effort at OASIS
and IBM. There have been a number of questions asked me about the accessibility of OOXML. This is no small request given that the documents are over 6000 pages long. That said, the University of Toronto Adaptive Technology Resource Centre recently published a white paper called Accessibility Issues with Office Open XML.
ATRC has been asked to review accessibility around OOXML in the ISO standardization review process in Canada. I recently had the pleasure of attending one of the calls as an invited expert.
While this is a lengthy document, and a good read for the accessibility community, the main point of contention I have with OOXML is it needs an accessibility review by industry as we have done with ODF 1.0. That review resulted in a new ODF 1.1 specification that not only addresses accessibility but also raises the bar over other standards. After all, access to office documents is what we call a "high impact" use case for people with disabilities. It is almost as important as web and email access. A look at the ATRC white paper shows what always happens when you do an accessibility assessment - you drum up numerous problems with the technology or specification in question. Why? - because people with disabilities need to have access to all the features of subject in question. So, how does this apply to this document?
As ATRC highlights, there are numerous parts of the specification that are ill-defined and refer to proprietary behaviors as in section 3.4. What is autoSpaceLikeWord95 and useWord97LineBreakRules mean? Imagine yourself being a non-Microsoft office application, on Windows, MacOSX, or Linux, and you wanted to support accessible access to text through the platform accessibility API. How would you do it? This is no different than an office application needing to render the content. I would also contend that an accessibility review could not be completed until these holes in the specification were filled.
OOXML is now a published specification (ECMA-376) submitted to the International Standard Organization's JTC-1 committee for fast-track (get it out fast no matter what state it is in apparently) consideration of its adoption as an international standard. If this gets approved by ISO you have to question the ISO standards acceptance procedures, given that only one company can implement the standard, and its commitment to accessibility - which in the past has been exemplary. I do hope that ISO lives up to its reputation and demands an international accessibility review and that Microsoft be required to address the findings. If not, the creation of an open standard will have had no impact on the status quo and people with disabilities will continue to be left out in access to other office applications and operating system platforms - and accessibility gaps will still exist in Microsoft Office. To the best of my knowledge blind users still don't have access to MS Office on the Mac.[Read More]
Recently, IBM announced its participation in the Open Office development effort
. One of the benefits to the Open Office community is that they will be able to benefit from our accessibility implementation in the Notes 8 Productivity Editors. In the Notes 8 Productivity editors we implemented a new open accessibility API called IAccessible2. IAccessible2 was contributed to the Free Standards Group, now the Linux Foundation
, in 2006. IBM is a big supporter of open accessibility standards and we are pleased to see Open Office benefit from the work.
I recently read an article about the donation, "IBM beats Microsoft over the head with its own code" which took a kernel of a fact -- that IA2 is an extension of Microsoft Active Accessibility (MSAA), a Microsoft-developed technology -- and in the interest of simplifying it for his readership, made a few mistaken conclusions about it.
Let me clarify by saying IAccessible2 is an accessibility API, which you can add to your MSAA enabled Windows application, to provide additional accessibility features needed to handle rich internet applications, rich text, and documents - in this case ODF. IAccessible2 in no way modifies MSAA. Microsoft has made MSAA available to industry as as a standard accessibility API for Windows and modifying it would break interoperability with assistive technology. Furthermore, Microsoft made MSAA available for all to use on Windows. IAccessible2 is derived from work we did on Java Accessibility and the UNO Accessibility API (which I discuss in an earlier blog entry). It is in no way derived from Microsoft work.
IAccessible2 does not just support screen reading. Accessibility features of IAccessible2 also assist alternate input solutions for people with mobility impairments. IAccessible2 also provides support for screen magnification solutions. AI Squared, developer of the industry leading ZoomText screen magnifier, provided valuable feedback in IAccessible2's design as well for this reason.
One of my functions is to co-chair the ODF Accessibility Subcommitee in OASIS. The accessibility subcommittee is pleased to see the article recognize our accomplishment in making ODF accessible and our recent work called “Accessibility Guidelines for Implementations of Open Document Format v1.1.”
I received an email the other day from a very respected leader in a major accessibility advocacy group. He wanted to know, after their endorsement in 2006, whether IAccessible2
has gone anywhere. Also, there has been a lot of discussion on TEITAC
with respect to how we get AT vendors engaged. So, I thought I would respond publicly for those companies I can talk about.
IAccessible2 is in or being implemented in these products today:
Two other major application vendors are adding it to their products as well. It also appears that KDE's QT library may be adding support for it on Windows as it is similar to the UNIX accessibility API. Even more encouraging is the size of these applications. These are not small apps.
Assistive Technologies adopters:
It is being added to the NVDA screen reader. ZoomText has added support for a lot of IAccessible2. We, and the Open Accessibility IAccessible2 working group continue to work with other AT vendors. Open Office and Firefox are a big driver for ATVs. These are high impact consumer products to which developers can have access to the source and see how it is implemented.
We are creating a new accessibility test tool that will be open source. It will be part of a new open source accessibility tools framework we are initiating. This tool will support Java, IAccessible2, MSAA, and Web 2.0 ARIA-enabled applications running in Firefox. It was designed with input directly from companies like Freedom Scientific. So, it will work with screen reader vendors products, and is designed to assist vision impaired as well non-vision impaired users. For example, a screen reader requirement was to process events in-process with applications to give the same response the AT would expect to receive from the application.
So, why is IAccessible2 so successful?
- We and the Mozilla Foundation provided assistance to ATVs to do the work
- A solid design with a gradual migration path to the new API. - Think why DOS users migrated to Windows over OS/2
- Regular architecture meetings with ATVs held separately with a strong focus in protecting their intellectual property
- Open standards
- Support by key, significant in terms of size, significant with respect to the needs of the consumer, open source products.
- Community building
- No hidden agendas
- Open source projects which generate business for the accessibility community (consultants, ISVs, ATvs, etc.)
- Corporate leadership
- No IP barriers to entry
- Support by major accessibility advocate groups
- Open Collaboration
- Interplay between standards and implementation - ODF standards, IA2 standards, AT implementation, app implementation - all done in parallel (an open coummunity effort)
Lack of these things is why it has taken other accessibility API efforts so long to take off or stumble. I also believe the availability of open source tooling will help dramatically. We modified the MSAA inspect tool internally to test Symphony support for IAccessible2 but then we had to throw the code away because MSAA inspect tool licensing prohibited our releasing derivative works. This set us back a good 6 to 7 months to create a new open source tool we will be releasing in the next quarter.
Since I have taken over accessibility strategy for IBM software I have pushed for one that is open and barrier free. In 5 years I doubt people will remember that IBM started all this (open accessibility on Windows) but I do hope we have a more barrier free, interoperable, accessible environment for which people with disabilities don't have to wait years to access. A look back at early accessibility API work on Windows showed it took years for adoption of that work by ISVs and ATs. IAccessible2 has been able to achieve stellar results in a very short period of time.
At long last we finally got the ODF 1.l Accessibility Guidelines
out for public review
. These are the first accessibility guidelines for office application developers.
These guidelines are intended for office application developers but they are also good reference material for people new to accessibility. The guidelines introduce the developer to a broad range of disabilities and the corresponding needs that must be addressed. Readers will see that there is a strong emphasis in supporting interoperability with assistive technologies. Full interoperability, is often overlooked when addressing accessibility. The ODF Accessibility Subcommittee focused on interoperability in ODF 1.1 and, as a result, you will see how this document directs office application developers to address the interoperability features in ODF 1.1. You will also notice a strong emphasis in preserving document structure when supporting assistive technologies. Structural semantics is critical to accessibility as access to structural information provides context to the user. Readers will also find a section on preserving accessibility information during the file conversion process.
Given the fact that ODF is totally open and lacks platform dependencies, it is important that ODF office application developers use these guidelines to preserve accessibility on each of the targeted operating system platforms even if accessibility is new to those platforms.
We look forward to your review.[Read More]
Some of you may have seen the announcement announcement about the Accessibility Tools Framework (ACTF) donation
. As many of you know, IBM promotes an open accessibility strategy in an effort to reduce the time that new technologies become accessible. In the past we have done this by initiating and leading: the Accessibility for Rich Internet Applications (WAI-ARIA)
; donating code to Firefox
to support WAI-ARIA; creating IAccessible2
and donating it to the Free Standards Group, now the Linux Foundation
; and contributing to Linux accessibility.
Part of the strategy was to address a growing need to have an open source accessibility tools framework. One reasoning was that propriety test tools on Windows prevented us from distributing a modified version of the Windows accessibility test tools of IAccessible2 to developers. Another reason was that creating test tools from scratch was a time consuming process. Why not take the ones we were creating, internally, and donate them to the industry to build upon, free of encumbrances. Also, due to the overwhelming success of Eclipse, we felt it was an excellent place to build a community around a reusable and extensible tools framework that provide developers, consultants, and new technology providers with a starting point. The result is ACTF.
In ACTF we will be donating new tools like "AccProbe" which will allow you to do IAccessible2, MSAA, and WAI-ARIA testing. We will have new browsers and validation tools as well. The best thing about it is that you can participate, or borrow what is there as you see fit ... and you don't have to sign a license agreement![Read More]
I was elated to find that Microsoft has added support for WAI-ARIA
in Internet Explorer 8
. Although I am sure support is not complete, this is a statement of commitment by Microsoft and it gives the effort support by over 90 percent of the Web browsers. IBM is already incorporating support for WAI-ARIA
in toolkits, like Dojo, which is being consumed by many IBM products to deliver a usable, accessible experience to people with disabilities for Web 2.0 applications.
The next question we need to ask is what ATVs support this level of WAI-ARIA implementation in IE 8. If we are going to start playing with this we need an assistive technology (AT). Hopefully, either Microsoft or AT vendors will divulge this information for developers soon.
I want to personally thank Microsoft for making this step forward.[Read More]
The net of the 2008 CSUN Conference
for me was that all of our hard work on Web 2.0 and IAccessible2
has resulted in widespread and growing adoption across the board. WAI-ARIA
was being implemented everywhere but many of the implementations have yet to be fully fleshed out. Our next step will be to help ATs revamp their UIs to better help developers and end users. As a result, I believe a more accessible and usable web and desktop experience will be had by all.
Web 2.0 Accessibility
WAI-ARIA: WAI-ARIA presence grew dramatically at CSUN this week. Until the Microsoft announcement on IE 8 for WAI-ARIA a number of companies had been working on supporting WAI-ARIA but not releasing it. That changed. Google Web Toolkit 1.5 supports WAI-ARIA as does Google Reader. GWT 1.5 should come out in a formal download within the next 2 weeks. Adobe indicated that Adobe's Spry framework for AJAX was adding WAI-ARIA support which will give us tooling support in Dreamweaver. The Apollo SuperNova screen reader/screen magnifier is adding support for it with IAccessible2 support targeted for later this year. WebAIM is adding support for WAI-ARIA as well. Also, the University of Illinois Firefox accessibility plug-in is starting to mature and there are a number of nice features that will help us in WCAG 2.0 support. Google had 2 sessions on WAI-ARIA this week and I saw Microsoft engineers attend at least 2-3 sessions I sat in where they announced to the room that they had support for WAI-ARIA in the IE latest beta. WAI-ARIA is a home run!
On the negative side, aside from Dojo I did not see any demos of any Google or software. I suspect they are not fully debugged. Yahoo and the Paciello Group gave a presentation on their WAI-ARIA implementation in Yahoo Mail and highlighted some of the challenges retrofitting an existing rich internet application. Also, developers are having problems with Window-Eyes and JAWS as they don't automatically switch in and out of application mode. Also, if you turn off browse mode in Window-Eyes a minor refresh can cause it to fall back into browse mode. I discovered Microsoft has a minor problem with the IE 8 beta where you have to turn on WAI-ARIA support in the registry. This is a beta so I suspect this will be corrected in subsequent drops.
- Mashup Session: My mashup session was full with some people standing. Unfortunately, CSUN instituted something new this week which required you to sign up ahead of time and many people were turned away. Many attendees commented that the need for personalization will be very important going forward to address this problem. For most, the mashup problem is new. Here is the mashup presentation.
- Fluid Session: Again, this was a full session. People are very interested in Fluid in that it has created a social network for collaboration of UX designers, accessibility engineers, and application developers. Matt King and I will be discussing how we might use some of its principles into usable access. A number of attendees stated that they wanted to join and participate in Fluid.
- Dojo Session: Becky Gibson's session was very well attended, especially given session given the lateness in the day on Friday. A lot of questions were generated.
- Browsers: In the mind of end users, Firefox was "top dog" at this conference with respect to their accessibility efforts. That said, application developers are looking to IE fully supporting of WAI-ARIA. Microsoft received a lot of well deserved, positive press for their announcement to support WAI-ARIA in IE. There was no word on Safari from Apple on WAI-ARIA support at the conference.
The IAccessible2 panel was packed! All major screen readers were implementing IAccessible2 support: NVDA, JAWS, SuperNova, and Window-Eyes. Additionally AccProbe and Freedom Scientific's Magic support it as well. There were a lot of great comments from the panel. Adobe would like us to address extensibility and assistive technology vendors and developers on how to implement support for IAccessible2. Also, Adobe had asked that there be performance enhancements for AT handling of large documents.
There was a strong emphasis by ATVs, like Freedom Scientific, that the fact that they were involved with the development of IAccessible2 that is something that they know will work. Representatives from GW Micro and Freedom Scientific stated that IAccessible2 is only one tool in their arsenal to provide access. Probably, most
Virtual World Accessibility and a look at 3D Internet
IBM gave a wonderful presentation on their research efforts to make virtual worlds, like Second Life, accessible to blind. They are creating an accessible Web 2.0 navigation panel, using Dojo, to Second Life and they discussed a number of tools they are using to make the environment accessible: leveraging social collaboration to add semantic tagging, assistive avatars, and a "virtual" cane to reach out and find objects to move to. ... Another packed session.[Read More]
I have been adding to a new wiki which is cataloging ARIA growth. I think people will be amazed by whose adopting it. Check out "Who Supports ARIA?
"" on the Mozilla web site.
It is nice to see more players like Adobe join in.[Read More]
Recently, IBM lost one of its accessibility heroes - Cynthia Ice
. It has taken me a very long time to formulate the words that would come close to conveying the impact Cynthia Ice has had on IBM and the type of person she was to me.
Working in the accessibility field is extremely difficult. It requires very specialized skills - including incredible persistence. Accessibility is often viewed as additional work that is not always planned for. It requires a person who is tough, committed, patient, and caring to deliver an accessible solution that is usable to our customers. To do this you must have tremendous passion for your job as there is always someone or something to trip you up. Furthermore, the quality of access must be even higher when you have such high end-user impact products as Lotus.
Cynthia has worked tirelessly to deliver Lotus products that are accessible and usable to our customers and employees. She has been a beacon of leadership in an area few are willing to venture. We owe Cynthia our deepest thanks and prayers.
Cynthia, Thank you for all you have done. You have made the world a better place.[Read More]
I had not reported on IAccessible2 adoption
recently. I was pleased to see Stephen Partridge's blog posting of Adobe Acrobat investigating support for IAccessible2
. This is sure to improve the accessibility of Adobe Acrobat. This is exciting news given the recent IAccessible2 Request for Comment
. IAccessible2 is an enhancement to the Windows Accessibility API Microsoft Active Accessibility. It bring the Windows platform capability in line with Linux. IAccessible2 is a proven technology with strong implementations in the recently released Firefox 3
and Lotus Symphony
A new, free, open source accessibility test tool is also in development called accprobe. I encourage developers to try it out and provide feedback to the Eclipse ACTF team.
WAI-ARIA brings Web accessibility on par, or better, than what is available for today's desktops. It provide the Web developer with the tools to deliver fully keyboard accessibility as well as full interoperability between web applications and an assistive technology either through the DOM. If the browser manufacturer chooses, it can make the interaction with the assistive technology even easier by mapping the new found WAI-ARIA meta data in the DOM to the accessibility API supported by the browser. While this will carry us very far with Web accessibility it does not take us all the way.
A number of critical shifts are under way in how we a web applications. Web developers are beginning to make use of complex visualizations and mashup technology to do rapid application development through re-use of existing web services. Many of the services may be inaccessible given that WAI-ARIA is new. Also, making complex visualizaions accessible, like a map or a pie chart, accessible is just a waste of time. Rather, we need to consider the fact that a one-size-fits-all approach to accessibility may not make a lot of sense.
The IMS Global Learning Consortium and ISO SC36 have been working on something called the Access For All standards. These standards define accessibility user preferences and corresponding resource meta data (data which describes the adaptability of a resource such as a web page or video) to meet the users needs. IMS and ISO have been working on new versions of these specifications which allow for better adaptation of today's content and for better adaptation to mobile devices. One of the features of this strategy is the ability to replace a resource with an equivalent alternative to a resource. One example would be to replace the map with an HTML alternative which conveyed the directions for the blind. These specifications have been adopted with limited success in the Learning and Education space. What is really needed is for the broader web to adopt a similar strategy.
I recently attended a Ubiquitous Web Face to Face meeting in Pisa, Italy. Aside from the beautiful scenery we actually managed to kickoff a new piece of work which was to incorporate Access For All personalization into the W3C Delivery Context Ontology (DCO). The DCO provides a model of the characteristics of the environment in which devices interact with the Web or other services. The delivery context includes the characteristics of the device, the software used to access the service and the network providing the connection among others. The W3C has a direct relationship with the OMA which defines standards by which mobile devices request information, such as web pages, from a server so that web content may be delivered in the form best suited for the target environment. The DCO defines the parameters by which a device requests this information. Assuming sign off from ISO and ISO, this effort constitutes the first mainstream effort toward being able to allow a user to specify personalized content irregardless of the device they are using.
Going forward, I encourage readers to watch this blog for other related work underway in the area of personalization.[Read More]