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.
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]
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.
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
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]
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
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.
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]
Accessible open computing took another positive leap forward to accelerate the accessibility of Rich Internet Applications with IBM's announcement to contribute AJAX Software Development Technology to Dojo. So, you might ask, why are we doing this?
Three of the biggest failings of accessibility efforts in recent years are:
- Failure to implement and validate your infrastructure
- Failure to ensure a workable, usable solution that interoperates with assistive technologies
- Failure to provide reusable, accessible component libraries to reduce the enablement work of developers
The intent of this work is to address all of these issues. This effort will allow the W3C WAI Protocols and Formats working group to have an interoperable test suite to validate its standards efforts. Firefox 1.5 and the sample web componentry provided on the Mozilla web site is a start. There is also test suite work going on at the University of Illinois. This library is targeted at robust industry reuse. As we progress with the standards effort, we can ensure that our specifications are well grounded in workable, interoperable solutions. This will facilitate moving the new specifications to recommendation.
Recently, Aaron Leventhal wrote a tremendous article called "Firefox: an open source accessibility success story." I strongly encourage readers to take a look at the story as it gives you some insight as to how a lot of passion and a little support from a large corporation can help transform an industry with open source.
A few years ago, David Boloker convinced me to leave IBM research to join IBM's Emerging Technology team in Software Group and establish ground breaking accessibility infrastructures to enable these new technologies to be adopted. To do this, I needed crack, passionate, accessibility veterans like Aaron to make this happen in order to allow these technologies to be used by people with a broad range of disabilities. Before bringing in Aaron, our goal was to make accessible rich internet applications a reality. This was well before AJAX added the excitement to "Web 2.0" applications. In order to address the accessibility of these applications I needed a strategy that encompassed browsers, open standards, documentation, industry awareness, component reuse, assistive technologies, and tooling. Going the IE route was not going to happen. Microsoft was focused more on XAML than web-related activities and they appeared to be investing little in IE at the time. The obvious choice was Mozilla and open source which would also leverage IBM's browser team. Mozilla also offered cross-platform opportunities.
I had known Aaron since his days at Raised Dot Computing and of his passionate work on Mozilla. Aaron was working at AOL at the time who had recently worked out a deal to adopt IE as their browser which left the Mozilla accessibility work unfinished. Aaron also owned the accessibility modules for the Mozilla foundation. After a period of time I was able to get Aaron on board.
Aaron's first task was to establish a Mozilla browser as an accessible alternative to IE on Windows and weave the rich Internet application accessibility support, I had initiated in the W3C, to prove the standards worked. What Aaron needed was assistive technology support and we were able to establish that through work with GW Micro and then later with Freedom Scientific. I can't count the number of hours that Aaron put in but it reminded me of the days IBM developers worked on OS/2 around the clock. In October 2005 IBM announced Firefox as an accessible browser which supported rich internet applications. This hit when the excitement about Firefox was huge and what happened next is largely due to AAron's passion for accessibility and the IBM announcement.
Aaron managed to gather NFB support for Firefox as an accessible browser. Aaron worked with Frank Hecker at the Mozilla Foundation to establish an accessibility grant program. Aaron also helped establish the first VPAT for a browser which clearly stated its compliance to U.S. Federal regulations. IE's compliance is buried in the compliance of the Windows desktop and other browsers just don't state compliance. The article states numerous open source projects around the Firefox browser created by this grants program. As a result of this work, Firefox is clearly being established as the most accessible browser. It has shown how open source development can be used to solve the most critical accessibility problems. It has also allowed IBM to consider many more open source initiatives in the accessibility space such as we are doing on Linux.
I was pleased to see the W3C announced the first working drafts of the roadmap and specifications addressing the accessibility of Rich Internet Applications. This was work I had initiated over 2 years ago in the W3C and it is nice to see that accessibility through open standards works. Although I initiated, and helped lead this, the end result is certainly a team effort by the W3C.
What is important about this announcement is that it also address the accessibility and usability of the Web by persons with disabilities by closing the usability gap between the web and rich graphical user interfaces much the same way that the new Web Content Accessibility Guidelines are meant to address the accessibility of all types of content which may be delivered over the Web.
As the article states, this work provides the tools the author needs to make these types of applications accessible and usable. This, in fact, addresses accessibility reform on the Web by allowing the author to add semantics to the web page to facilitate platform accessibility infrastructure support of your web application by the browser. It will also allow us to consider new web accessibiltiy test tools that are capable of handling both GUI and Web-based applications.
What is clear is the W3C has made leading a quantum leap into area that brings the usability of the web experience, for all users, in line with rich GUI applications without the overhead of supporting multiple operating systems.
I recently spoke at the annual NFB Convention, in Dallas, with Becky Gibson. Here is a summary of the meeting:
Rob Sinclair, the Microsoft Accessibility Director, gave a great presentation on Vista and the upcoming accessibility features. Vista is Microsoft’s first step toward adapting content to meet the needs of the individual. Rob showed a talking login as well as the Window-Eyes screen reader reading parts of the desktop. Rob stated he wanted to raise the bar in the accessibility space. Due to the audience, Rob did not show off their speech recognition technology which will be bundled with Vista. I saw this at CSUN and was quite impressed. The downside is the new Vista functionality, much which is not accessibility related, comes at a price.
Later in the meeting Joe Steinkamp, from the Texas Department of Assistive and Rehabilitative Services spoke on the resources required to run Vista which will be prohibitive for many individual consumers and businesses. Vista takes 2 gb of RAM and a 128mb graphics card. For those running screen magnifiers, 256mb RAM is required. Also, it appears that a dual core processor is required. So, unless your company is forcing you to go to Vista or you buy a machine bundled with it, I don’t see many in the blind community being an early adopter.
Rob plugged the new Vista Accessibility API, called UI Automation. UI Automation is a dramatic change from MSAA in that it is very focused on behaviors and automated testing. The behavior piece is a certainly good fit for automated testing. The challenge, as I see it, is the dramatic change from how other accessibility APIs work on legacy Windows, the Mac, Linux, and Java. When the user encounters a new UI widget they should be able to tell whether it is clickable, scrollable, togglable, and so on. This is good, however I am concerned over the lack of information that would indicate how the object would relate to other objects the user is familiar with - unlike what we are doing for Dynamic Web Accessibility in the W3C. Time will tell. At this point the major AT vendors do not support UI Automation. Rob recognized the need for a client API that did not run in managed code and that the work to do that had begun to address this. AT vendors do not want to rewrite as managed applications. It remains to be seen if this will be addressed in the Vista timeframe.
Becky Gibson and I gave a presentation entitled “Firefox and AJAX IBM’s efforts on accessible Open Computing.” In the talk we discussed why and how Firefox came to be accessible and support Rich Internet Applications. The talk was designed to convey how this open source accessibility project has advanced the accessibility and usability of the Web and the resulting accessibility ecosystem that resulted from this work. The Mozilla foundation, who at one time was not focused on accessibility now has one of the biggest supporters and in fact has instituted an accessibility grants program that has spawned such projects as Mac enablement and XForms accessibility support for Firefox. Additionally, Firefox is being enabled for Linux. This is a collaboration between Sun, IBM, and the Mozilla foundation.
Becky gave a demonstration of DHTML and AJAX accessibility and discussed her work on the Dojo open source accessibility project which she is leading for IBM. I finished up with a discussion of our work on Linux accessibility and the open source accessibility ecosystem growing around our Linux Screen Reader and full screen magnifier projects. The point being, open source accessibility projects are attracting developers worldwide to contribute and accelerate new solutions.
Finally, Joe Lazzaro, the lead for the state of Massachusetts Information Technology Division Department of Accessibility spoke on the move to the Open Document Format. Joe stated that the department will be following U.S. Public Law 508 accessibility guidelines. My take-aways from Joe’s speech is that the legislation has decided to hold the role out of ODF until it is accessible. The fight to make that decision was akin to the threatened Microsoft boycott led by Charlie Crawford back in 1995.
Joe said the group was evaluating two interim MS Office plug-in utilities to import/export ODF documents. They were from the Open Document Foundation and Sun Microsystems. Other than recent discussions around ODF I had not seen Joe in years. I was pleased to see the ITD group pick Joe to lead this effort.
The Open Document Accessibility (ODF) Subcommittee is developing a new document called Accessibility Guidelines for Implementations of Open Document Format (ODF) v1.1. This is currently out in draft form for review. To date the only guidelines like this have been developed for web user agents. We felt it necessary to to assist office application writers in now to fully utilize the accessibility features of ODF 1.1. The OASIS Technical Committee for ODF is currently taking the ODF 1.1 specification toward a fully recommended OASIS standard. IBM, Sun (Open/Star Office), and the RNIB (DAISY conversion) have signed up to support the standard. Through open standards contributions industry has been able to rapidly raise the bar on the accessibility of office applications. The new accessibility features of ODF 1.1 will make a more usable document format for people with disabilities.
I encourage review comments to be taken back to the ODF Accessibility Subcommittee.
I wanted to take a minute and point people to Frank's blog regarding Mozilla's presence at CSUN
. This is an indication of the accessibility ecosystem building around an open source project. Frank's enthusiasm is contagious.
I was pleased to see IBM's contribution, as part of the open source community, foster a new grassroots effort around accessibility and the Firefox browser. Students are getting involved with accessibility in college by simply being able to contribute to the open source effort. The result is innovation through being "open."
Like any good open source project, IBM is no longer the only contributor. Others can share the load while increasing the innovation by a lot of very energetic people.
I remember the first time I was able to make Screen Reader/2 speak the GUI and see people with disabilities be able to use it for gainful employment. The experience is adictive.
I want to thank Frank, Aaron Leventhal, and the Mozilla Foundation for pulling this energetic team together at CSUN.
I have been asked a number of times about XForms and accessibility. During the course of the blog I will highlight the accessibility features of XForms.
is a delarative markup. The engineers who designed XForms took the standard use cases for how we create forms and built in support for the standard actions performed in a web form. From an accessibility perspective, this means these functions should be available from the browser independent of platform. So, rather than guess what an onclick does on a form, the user should be able to access the available functions and Notification events that are used in that specific form as defined by the XForms standard.
- next and previous
- focus change
- help and hint
You are also notified of events which actually occur during form operation. These types of events allow applications, like a screen reader, to provide alternative modalities such as speech.
- Value change
- Select and Deselect
- Scroll First, Scroll Last
- Insert, Delete
- Valid, Invalid
- ReadOnly, ReadWrite
- Required, Optional
- in-range, out-of-range
XForms 1.0 support is being added to Mozilla
. Exposing access to this information will greatly improve the access of Web-based forms.