Accessibility Strategy and Architecture
schwer 120000D6E4 518 Views
In addition to device independent events, XForms also provides another powerful feature by its model-view-controller design. XForms separates content from presentation while embedding relevant meta data in user interface constructs.
XForms provides the following meta data:
label for the user interface control
hint help text for the user interface control
help help text for the user interface control
XForms also encourages intent-based authoring by introducing these constructs:
group to group a set of user interface controls
switch , and case which can be used to hide or reveal logical groups of controls
case includes a Boolean attribute called selected that allows the group of controls within that case to become active. This is important to assistive technologies, such as a screen reader, which would monitor the document to determine when to speak selected elements. If none of the cases within the switch are selected, the first case in document order becomes active by default. How those elements are rendered visually is of no consequence. The semantics are preserved.
For an in-depth look at XForms a great book to read is:
XForms: XML Powered XForms by TV Raman
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.
- 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.
schwer 120000D6E4 Tags:  msaa firefox accessibility uia aria windows iaccessible2 fsg gnome odf 3,524 Views
I recently visited Andy Updegrove’s blog, following our IAccessible2 (IA2) announcement, and I noticed his question regarding why we chose to create an API other than UI Automation (UIA). I have had similar questions asked both publicly and privately. The answer to that begins in March 2005.
At CSUN 2005, I approached Microsoft with the idea of producing an industry standard, unencumbered, royalty free, accessibility API. Industry needed a comprehensive, standard, accessibility API to support solid interoperability between applications and assistive technologies. We had a 2 pronged strategy. Microsoft, I was sure, would push for the API being UIA and if this was not successful our alternative was a new accessibility API we were creating out of project Missouri that you all know now as IAccessible2.
At this time, the UNIX accessibility efforts were such that a new API was tenable although we would have, and did, take a lot of heat for suggesting it. That said, we felt it worth the effort to make this happen. We were willing to use UIA even though we had reservations which I discuss later in this blog entry. An indication that this effort was going on can be seen in a June 2005 Microsoft announcement. By October 2005, we were unable to make this happen and we had to cut and run because it would hold up our UNIX accessibility efforts in the Free Standards Group (FSG) as well as our new office suite enablement work for Workplace.
At this juncture I told Microsoft that we would take an alternative approach to achieve the goals I outlined above. Shortly after, the State of Massachusetts laid down the aggressive timeline for ODF accessibility and Missouri kicked into high gear across IBM. If we had stuck with UI Automation we would not have met the states needs, as you will soon read. Also, through industry contribution, UNIX accessibility had now matured significantly and going back to UIA would be similar to a slash and burn effect for that platform. Apple was in a similar situation. Fortunately, in the background we had been creating IA2. The goals of that project are defined in my previous blog entry.
My reservations about UI Automation then and today are multi-faceted and this is a result of a similar situation which happened when Microsoft released Microsoft Active Accessibility (MSAA) in 1995. So, let me digress:
MSAA (formerly OLE Accessibility) was designed with Assistive Technology Vendors (ATVs) input but with little contribution by the developer community creating a chicken and egg problem. Upon release it had little to no ATV support because application vendors did not implement it. This was because ATVs did not support it and because very little guidance was given to developers on how to implement it. As a result, MSAA had great promise but suffered from a number of gaping holes such as: support for rich text; tables (spreadsheets, etc.); hypertext links; relationships; and multiple named actions. Over the years industry vendors have produce a plethora of proprietary APIs, including Microsoft, to expose the information needed to fill the holes. ATVs have had to aggregate support for all these APIs and less reliable, dated, engineering techniques like “screen scraping” to produce an offscreen model. The result has been a nightmare for Assistive Technology Vendors (ATVs) and application developers to support and the results are often unreliable. In fact, one could argue that no single, comprehensive, standard, accessibility API for Windows exists.
Microsoft developed UI Automation with the intention of filling these holes but many similar problems exist today. Today, assistive technology participation in UI Automation appears to be limited to design time. Currently, the major ATVs don’t support UI Automation (UIA).
UIA is divided into a provider(application) and client side (ATV) API. The client side portion runs in managed code called the Common Lanugage Runtime environment. Today UIA requires ATVs to rewrite all or part of their software to run in a managed environment to access them. This has prevented widespread ATV adoption of UIA and thus application vendor support. Microsoft needs an unmanaged client-side UIA implementation, which ATVs can support, but that is not currently available for Vista or XP. Given the absence of an unmanaged UIA API and the extremely few applications that support UIA, we believe UIA really needs more ATV testing to prove readiness for wide scale adoption. Microsoft's challenge will be to get large applications, like MS Office, and ATVs to support UIA to work out any defects.
Now, all this said, the Vista desktop needed to be accessible. Vista access by screen readers is a combination of MSAA and screen scraping. In short, access to the Vista desktop is like XP today. Screen scraping is limited to the unmanaged environment. For managed applications Microsoft provided some basic UIA to MSAA mapping and some text access but the accessibility is limited. Consequently, support for managed applications is currently dependent up on a limited client side unmanaged API layer. Due to the limited number of managed applications, there is little business justification for ATVs to support them.
Getting back to IA2, I will turn the clock bat to 1997 when IBM and Sun got together to collaborate on a new accessibility API for Java – now called the Java Accessibility API. You can learn about the early work in my 1998 CSUN pitch with Phill Jenkins. The presentation includes a link to guidelines I created to assist developers. A new Java Accessibility API was needed because of MSAA’s dependence on other technologies, like offscreen models, which were not available on other platforms. Additionally, IBM created a pure Java Screen Reader called the Self Voicing Kit for Java to test the implementation on Swing with a real, scriptable, screen reader. This work is something both Sun and IBM are very proud of as it is also the basis for the work on UNIX, UNO, and IA2. The API works. Java’s accessibility problems today are not with the API but the transport layer in the Java Access Bridge. The use of MSAA and IA2 would be an excellent replacement.
We do believe that more work is required for application vendors to use UIA. With IA2 we complement MSAA, as is, and we have fully tested ATV support today. To validate this I refer to GW Micro's endorsement of IAccessible2:
"MSAA provides a great base for allowing applications to make themselves accessible. However, over the years it has become apparent that MSAA lacks important information needed to make certain elements accessible. IBM has taken the lead on extending MSAA, using the new IAccessible2 interface. IAccessible2 resolves the major holes left with MSAA by enhancing it, not replacing it. Switching from MSAA to other standards, such as UIA, is possible in the future, but is likely to be a very expensive endeavor. IAccessible2 allows you to keep existing MSAA support but then allows you to enhance in areas that MSAA falls short. GW Micro has been working with IBM to fully integrate IAccessible2 into its screen reader, Window-Eyes. Having Window-Eyes support IAccessible2 allows application developers to test using serious accessibility tools. IAccessible2 completes MSAA."
-- Doug Geoffray, Vice President of Development, GW Micro
The effort to enable IA2 supporting applications on other platforms is significantly smaller than with existing APIs. We have heavily designed and tested IAccessible2 to work on an entire office suite and with input from the Mozilla foundation who would implement this on Firefox. As indicated here, and Peter Korn's web log, IAccessible2 is not new in that it is derived from working APIs we helped design and implement on UNIX and Java. Also, IA2 was designed with the help of ATVs like Freedom Scientific and GW Micro during its implementation on IBM's Productivity Editors for Notes 8.
During the design of IA2 we added support for W3C ARIA unlike UIA. We believe changes to UIA are required to support Web 2.0. Going forward, IAccessible2 is an open standard and will allow others in industry to enhance it as new technology warrants. Proprietary APIs are much more restrictive and this kind of participation is very difficult. We believe they can both exist on the same platform as both are built on top of the COM transport layer.
An important benefit, for ATVs, is that they can continue to run in-process to get the performance enhancements they have realized with MSAA. This may prove difficult with the provider/client side architecture in UIA. For the non-techies running "in-process" is like talking to the person next to you vs. shouting across a street. The noisy interruptions will cause the conversation to take a lot longer to complete.
In short, because UIA has not been used by major application vendors and ATVs we believe it will take some time to be fully realized. In the mean time IAccessible2 will already have been implemented to support large rich desktop applications and W3C ARIA with full ATV support. UIA's immediate benefit may be for managed applications.
Beyond the planned IA2 support in Firefox 3 and our productivity editors in Notes 8 (Open Document Format support), we will be adding support in Eclipse. That work has just kicked off. By implementing it in Eclipse any application built using Eclipse will be able to make use of IAccessible2 and more usable access. This will allow us improve the usability of things like of rich model-based authoring tools for persons with disabilities in our Rational product line. Many vendor products work on Eclipse. IA2 will make the already strong accessibility of Eclipse more usable by persons with disabilities on Windows and once implemented it will be easier to make Eclipse fully accessible on other platforms.
I should point out that there are other vendors planning to support IA2 and I hope they will be making those announcements in the near future.
It is our hope that Microsoft will join the Free Standards Group and participate in IAccessible2. The effort dramatically improves the interoperability problem, between ATVs and application vendors, on Windows which does nothing but help Microsoft. Also, due to IAccessible2's synergy with MSAA, Java, UNIX, and UNO accessibility the uptake should be swift. Microsoft's experience in the area would be greatly welcomed and they could benefit from future accessibility innovations produced by the FSG. Like IBM, I believe Microsoft would like to move on to other accessibility challenges which have not garnered as much attention today. Here is the opportunity. I am cautiously optimistic.[Read More]
schwer 120000D6E4 Tags:  wai-aria jaws iaccessible2 web accessibility nvda 1 Comment 3,763 Views
WAI-ARIA introduces additional semantics necessary to make Rich Internet Applications fully accessible, and usable, to assistive technologies. It also may add the needed punch to improve the usability of static documents by people with disabilities. We hope to bring WAI-ARIA to last call status in the first quarter of 2009. Already it has huge implementation support and on line education. One of the most important resources now established for WAI-ARIA is CodeTalks. This site is extremely active with code samples, references to educational videos, and online collaboration growing daily. Another critical resource is the Google Group Free ARIA. Many from the W3C WAI WAI-ARIA community and CodeTalks communicate on Free-ARIA.
The lack of appropriate tooling to validate Rich Internet Applications against WCAG 2.0 is a serious problem. To address this gap two efforts are being kicked off. One I am pulling together is the Accessibility Tools Task Force in the Open Ajax Alliance. Here we are developing best practices and rules to aid test and development tools in valdating these types of applications and assisting developers. Participation in the Open Ajax Alliance is free and participants are asked to sign a minimal agreement. Another effort being kicked off is the WA-ARIA Firebug Accessibility Dashboard Project which can be followed on CodeTalks. This effort is being led by IBM and the Mozilla Foundation under Aaron Leventhal and is designed to assist authors using the Firebug IDE to produce accessible Rich Internet Applications.
In 2008 we have seen a dramatic enhancement in the accessibility API support in browsers driven by the need to support WAI-ARIA. Firefox 3 added IAccessible2 support on Windows and ATK support on Linux. Microsoft is in the process of adding UI Automation support to Internet Explorer.Finally, in 2008 we are starting to see advancements in assistive technologies user interfaces to make Web 2.0 applications more usable. Jaws 10 released on November 3 with a host of user interface enhancement to support WAI-ARIA. Some of these usability enhancements included automatic forms mode switching, WAI-ARIA landmarks, and early support for Ajax live regions.
With WCAG 2.0 out and these advancements I expect 2009 to be a year where we see the usability of the Web to take a dramatic leap in usability by people with disabilities as products start to adopt it.[Read More]
schwer 120000D6E4 Tags:  wcag 2 web2.0 personalization accessforall wai-aria 3 Comments 5,553 Views
I want to thank you all for coming. It is a pleasure to be back in the U.K. and I would like to thank the RNIB for inviting me to speak to you today. I come to you from the great state of Texas. I have been living in Texas for roughly 13 years. What I have been told is the United States is divided into two main areas - Texas and, well, everybody else. We also have great spicy food and I was told that well, England does not and I heard this from a colleague from Sheffield. He mentioned something about national food being “bubble and squeak.”
He did say, however, that what I really needed to try was "mushy peas." That was not the type of food I would think a country should be bragging about. Well, I am happy to say I did try them and they were quite good. Although you might consider serving hot sauce with it.
Seriously though, all of us do have a lot in common. We work in one of the most challenging fields in the computer industry – accessibility.
Those working in the accessibility field compare it to the legend from Greek mythology of King Sisyphus, who was cursed by the gods to repeatedly push a huge boulder up a hill for all eternity, only to watch it roll down again. As you, no doubt, experienced with your success, persistence, passion, and determination can lead to tremendous rewards along the way and make pushing that rock just a bit easier. That is no different than how we are approaching the rapidly changing Web environment.
My career in accessibility began in 1990 in the halls of the IBM Watson Research Center. At this time industry was switching from a text-based interface to one that was graphical. Screen reading technology, at the time, could easily gain access to the text on the screen but when it was converted to graphics the concern was that it would all come to a halt. Just imagine the fear that a blind individuals had when faced with the prospect of losing their jobs, or one of the vehicles for basic communication with friends and colleagues. In 1991, Joe Lazarro published an article called “Windows of Vulnerability” in Byte Magazine that described this fear as the industry moved from DOS to graphical interfaces such as Windows and IBM’s OS/2. Quietly, I had been working with a team of engineers at IBM to create the first Screen Reader for graphical user interfaces, which provided blind users with access to OS/2. By the way, graphical user interfaces are known in the industry as GUIs. In December 1991, I published an article called “Making the GUI Talk” in Byte magazine, that showed the community how we made it work. That day the earth shifted to meet the needs of users with disabilities. I recall my boss, Jim Thatcher, walking into a government building in Washington to discuss the loss of access to computers by blind users. When Jim approached the meeting room, stacks of the magazine containing the article greeted him at the door.
This early innovation was based on capturing what was drawn on the screen, using reverse engineering to guess what it represents such as a menu item or a button, and reproducing a textual representation that could be read to a user. Since this time we have defined new standards that allow desktop application developers to provide the textual information as well as semantics and structural information representing the rich desktop interface to assistive technologies.
This resulted in a much more reliable and usable experience. The first of these standards were the Microsoft Active Accessibility in 1995 and the Java Accessibility Application Programming Interface, a collaboration between IBM and Sun, in 1998. Looking back, both pieces of work were seminal in that they formed the foundation on which applications provide the necessary information required by assistive technologies for over a decade. If implemented properly, an assistive technology can ask for the information they need rather than guessing.
In 1999, the Worldwide Web Consortium published the first Web Content Accessibility Guidelines, which became known as WCAG 1.0. At the time WCAG 1.0 was published, the Web consisted of static documents where the idea of a dynamic page meant reloading a new one. Also, navigation of a web page, by a person with a disability was archaic, slow, and tedious requiring constant tabbing to navigate to get to anything on the page. Even worse, the markup language used to code Web pages, HTML, was not entirely keyboard accessible. This was largely because it was expected that the user would spend most of the time using a mouse for navigation. It was a time where the concept of making something accessible was limited mostly to adding alternative text and rudimentary semantics found in HTML; where usability for people with disabilities was an afterthought; and where you restricted the technologies used by the web site author to meet compliance. The Web experience, for many, was a step back from what users experienced on the desktop. Yet, the ability to access such a tremendous amount of information was so compelling and necessary that these drawbacks had to be accepted. That is changing. Like in 1990, another paradigm shift is now under way. It is called Web 2.0.
Today, this new accessibility information is provided in a new specification from the World Wide Web Consortium called the Web Accessibility Initiative Accessible Rich Internet Applications or WAI-ARIA. It is changing the way industry thinks about accessibility. WAI-ARIA is a way for authors to provide semantic “sugar” to a web page to allow a browser to support the accessibility services provide by an operating system which are used by assistive technologies. We call this “interoperability.” Prior to WAI-ARIA, industry’s notion of accessibility was more in line with what you needed in static HTML documents (headers, alternative text, and structural elements). With Web 2.0 applications authors create new user interface elements, such as a folder tree and notebook panels, where information is hidden until you are able to use it and the accessibility of the page changes as you operate it. This semantic “sugar,” or meta data, allows the author to tell an assistive technology, such as a screen reader, that the object is a folder tree and whether or not it is expanded. And it uses the document structure of HTML, and semantics, to tell you where you are in the folder tree hierarchy. We call this the “user context.” With WAI-ARIA we can also tell an assistive technology and the web browser the common landmarks on the page such as the main content, the banner, a search region, or the navigation section.
Prior to WAI-ARIA, keyboard navigation was limited to the use of form elements and anchors, which were all in the tab order. Everything else in HTML was not keyboard accessible. Imagine a mobility-impaired user having to tab through 1000 links on a page to get to the last link. With WAI-ARIA, keyboard accessibility is similar to that in the desktop environment where the Tab and Arrow keys can be used together to create a more efficient experience. All HTML elements can be keyboard accessible without requiring that they be included in the tab order. This constitutes a paradigm shift to one where you tab to significant elements on the page, such as a menu, which manage the information you see, and use the arrow key to navigate within. This is a huge step forward as now a Web page can have accessibility and usability, normally found only on the desktop, benefitting all users.
A second challenge will be better tooling designed to test the accessibility of Web 2.0 applications. Today, our accessibility test tools are largely geared to:
This, as we can all see, is quite a limitation. Rather, tooling must now consider
IBM has taken an open community approach to tooling. Through the Eclipse Foundation, we first provided an Accessibility Tools Framework to this open source tool platform and provided accessibility tool plug-ins for Web and Java applications. Most recently, we have started a new tools effort in the Open Ajax Alliance called the “Accessibility Tools Task Force.” We have pulled together in an open setting, many of the major tools providers including Microsoft, Deque, ParaSoft, Mozilla, Adobe, and educational institutions. Our intent is to deliver a collection of rules and reporting best practices to assist Web application developers in producing accessible solutions. In fact, we expect this work to be integrated not only into test tools but also into development tools used to create Web applications.
The third challenge comes with what is called “the programmable web” and the extensive use of rich graphical content. I believe these come hand in hand. Today the notion of how a Web application is built is changing rapidly. Today companies, and individuals, are creating reusable web application fragments through the use of web services as the new Application Program Interfaces or APIs. These APIs, listed at programmableweb.com, totaled 1,145 at the time I wrote this presentation. Last year at this time there were only 600. Companies, and in fact individuals, mash them up, hence the name “mashup,” into their own application leading to rapid application development. These services are then wired together in your web page. For example, you may choose an address of a customer contact on one side of your page and then an airport location on another side of your page. The address information from both supplies the source and destination of a travel route that is used to configure a graphical map in another. In this case, the source and destination may be provided through a web service that accesses this information in a contact and transportation data store respectively. The combination may then be wired to configure a Google map using their web service. This highlights a number of problems for users:
These issues require us to look at accessibility at a much higher level. It requires us to look at the basic fabric of how the Web is constructed. In order to solve this problem we need to step away from the one-size-fits-all approach to accessibility where a single web page must be readily accessible to all users as-is. We must step outside our constraints of thought and think of the Web as one that should be flexible and personalized. To address this we need to look to the learning and educational space where they are dealing with delivering solutions based on inclusive design.
A flexible and personalized web is one where the user specifies how they would like to see the Web delivered to them. Imagine a Web where accessibility becomes a preference rather than a solution and what is accessible depends on what the user deems to be accessible or usable. To do that you would need to also know something about the capabilities of the resources forming your page.
For example, does the video on a page support closed captioning? Does the video support closed captioning in the language I speak? If not, do you have one that does? Great, give me that one!
Is your resource a complex visualization, such as a map? I prefer a text equivalent, such as the textual driving directions. Do you have one? Great! I will take that one and I can give it to my driver too.
Do you support large fonts? Great, please deliver the page in large fonts and in high contrast if you have it.
These concepts are not fantasy. In fact there is a specification called the Access-For-All specification from the IMS Global Learning Consortium and it is used in some new learning systems being developed like those by Angel Learning, Teacher’s Domain, and a project called Fluid led by the University of Toronto. What is not there is a standard way to use these specifications to arbitrate personalized content on the Web. This is now in the early stages. In the World Wide Web Consortium Ubiquitous Web Applications Working group we are in the process of harmonizing a core set of Access For All preferences into standards that define how content is delivered to all devices.
This is a first step toward making your mobile device a truly personalized digital assistant. We must then define standards for how we access the personalized information and tag the accessibility capability of resources, such as a map, to deliver a form that is consumable by the user. When that fabric is in place and is widely adopted companies, like IBM, will be able to deliver a personalized experience to all users.
The Web is, and continues to be, the most important vehicle for delivering information to all users. Its power is rooted in its open pipeline to the masses. Looking forward I encourage all of you to become part of that open community. The ability to contribute to open standards and open source has allowed innovations like WAI-ARIA to move the web ahead at tremendous speed and advance accessibility for all to new heights. I encourage you all to participate and set the course for a Web without barriers.
Working together, pushing that rock up the hill gets a lot easier!
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 perspectiveIt 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]
W3C Releases Working Drafts of New Specifications Addressing the Accessibility of Rich Inernet Applications
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.[Read More]
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 :
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.
schwer 120000D6E4 666 Views
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:
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 and Gnome desktops.
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:
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:
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.
schwer 120000D6E4 648 Views
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:
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:
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]
schwer 120000D6E4 607 Views
A reader commenting on my blog asked if I would mind blogging some time on the definition of accessibility and the scope of problems that are being addressed in the industry?
At the most basic level, accessibility is about people being able to access and use a product or solution. A primary focus of accessibility is access by people with disabilities. The larger scope of accessibility includes benefits to people who do not have a declared disability or for those who dont. I would like to first address the near-term work being done in the accessibility space.
Tremendous effort is being put into operating system and desktop solutions to accommodate users with disabilities. The biggest change, which began in the mid to late 90s has been a move toward engineered APIs that allow Assistive Technologies (ATs like screen readers) to access desktop application. Additionally we are seeing a move toward integrating these ATs into operating systems. For example, the Mac desktop, the Gnome desktop, and Windows are moving to incorporate more ATs. Furthermore, the move toward engineered APIs is improving access for what I would call declarative disabilities those where people declare they have a disability. Some of the considerations for bundling solutions are: security, lack of an AT solution provider, and the opportunity to have integrated solutions with which to test the accessibility of applications and accessibility infrastructure.
The second wave, which began only in the past five years, is a move to support persons with non-declared disabilities. The biggest focus in this space has been the senior population for which IBM has been a significant contributor. As we get older we begin to experience varying degrees of disabilities. This may include, but is not limited to, varying degrees of mobility impairment, site degradation, hearing loss, and cognitive impairments. This population often does not wish to admit they have a disability or may not in fact believe one exists. Therefore, their disability is not declared. I worked on a large middleware research transcoding project for seniors which was designed to take any web page and transform it to meet specific access solutions such as magnification, increased white space between text and lines, linearized content to reduce horizontal scrolling, speech, magnification, varying color schemes to compensate for reading impairments, and other transformations. This was a precursor to an IBM service offering called the Web Adaptation Technology. This technology goes well beyond enablement and enters the realm of solutions which are tailored to the end user for ease of use. This leads into the next wave which is just now starting to take hold.
Accessibility continutes to move into the mainstream. We are using accessibility technology to help with mainstream solutions that are not just for persons with disabilities. Meta data we are incorporating into web content to address DHTML accessibility is being considered for building knowledge into the web content transformation process. For example, web content which incorporates role meta data (what the object in a web page is such as a calendar or spreadsheet and its corresponding properties) can be used to adapt content to different devices phones, pdas, etc.
In the next few years I can imagine legislation going beyond enablement, like IBM, and focusing on ease-of-use. Enabling applications for accessibility does not necessarily make them usable.
We also need to focus on the broader population in the areas of learning disabilities. Not everyone uses the same process for learning. Our systems need to adapt to these different needs. When we can do this we should see a dramatic increase in user productivity.
While I have not addressed all accessibility issues, I hope this addresses this persons request.
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]
schwer 120000D6E4 Tags:  ajax odf fsg accessibility aria firefox windows iaccessible2 msaa 1 Comment 3,330 Views
IBM and the Free Standards Group (FSG), today, announced IBM's donation of IAccessible2 to the Free Standards Group. IAccessible2 is a new accessibility API, developed in the project codenamed Missouri. In developing IAccessible2 we had a number of goals in mind:
Project Missouri constitutes one of the largest, and perhaps the largest, accessibility efforts in the history of our company. It was named Missouri as the State of Massachusetts laid down the gauntlet in front of IBM to "show me" an accessible solution for ODF in 2007. It's creation constituted a multi-continent design and development effort between IBM Productivity Editor developers in Beijing, accessibility engineers in Austin, and assistive technology vendors in Florida, Georgia, Indiana, and Wisconsin. The accessibility engineers from IBM's Software Group Emerging Technologies Accessibility Architecture and Development team are industry accessibility leaders in the areas of ARIA, Firefox, Linux, and Java with some working on accessibility for 20 years. Project Missouri is a true testament to IBM's commitment to accessibility as is the donation of IAccessible2 to the Free Standards Group.
The FSGs acceptance to make it an open standard will speed up the process to make future industry innovations accessible. At the Free Standards Group Accessibility meeting yesterday two large enterprise companies joined the IAccessible2 standards effort - Oracle and SAP. All companies who innovate and who are committed to accessibility desire a vehicle to make those innovations accessible. The Free Standards Group Accessibility group now develops accessibility API standards for both Windows and UNIX. When a new technology is developed participating members have a vehicle, if needed, to extend the existing standards to meet their needs and with help from accessibility efforts from across the globe.
IAccessible2 includes support for rich Tables, editable text, documents, relationships (critical for AJAX, model-based authoring tools, etc.), extensible roles (key for ARIA), hyperlinks, selection, multiple descriptive actions (critical for mobility impairment and onscreen keyboards). Going forward we will be contributing developer guidelines, and open source tooling to aid developers.
Most importantly, IAccessible2 will have support by assistive technology vendors which removes a critical barrier to adoption.
In summary, IAccessible2 is a key ingredient in the convergence of rich Web and desktop applications. It supports usable access for people with disabilities on Windows, while reducing developers' efforts to support accessibility on other operating systems. With a rich open accessibility ecosystem in place with the FSG for accessibility API development we should now be able to move on to broader usability issues rather than fighting interoperability problems with assistive technologies in the native platform.
schwer 120000D6E4 2,059 Views
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]