Matusow's Blog : Accessibility

Building Bridges to other XML-based Formats

jasonmatusow — Sat, 29 Mar 2008 08:04:53 GMT

I have repeatedly made the argument that it is bad logic that leads you to the conclusion that there should be only one document format. If you value innovation in document creation, and you want to see applications continue to advance rapidly, and you want to see broad-based problem sets be addressed creatively - then more innovation is good.

I have often heard that there should be just one document format...ODF...and yet it is just amazing to me how many document formats there are, and how many more seem to crop up on an ongoing basis. (remember the whole CDF discussion?) It would seem that the folks at the National Library of Medicine did not get the memo that they were to adhere to the singularity that is ODF. They had the temerity to go and solve for the very complex issue of creating an XML format that takes into account the needs of the scientific journal community. Specifically they did this with...

...the intent of providing a common format in which publishers and archives can exchange journal content.

They have focused on four challenges:

Archiving and interchange
Journal publishing
Article authoring
National Center for Biotechnology Information "Book Tag" (to describe volumes for the NCBI online libraries)

Microsoft has been espousing the belief that multiple document formats provide choice, innovation, flexibility, etc. etc. Moreover, in the context of XML, we fully anticipate that there will by a myriad of document formats created to solve particular problems.

So - at the heart of the document format discussion remains the concept of interoperability. The effective exchange of data to connect people, data, and diverse systems. And in the case of document formats...specifically the issue of effective translation of data from one format to the next.

Pablo Fernicola from Microsoft Research seems to have a new blog up in which he talks at length about the work he is doing in developing and authoring add-in for Word 2007 that builds a bridge between Open XML and the NLM format. Here is the link to the Technology Preview Release of the add-in.

I think this is a very cool thing, and it is absolutely what we have been talking about all along. We did this with the DAISY format (Nov 2007), with ODF (July 2006), and here is a link to the UOF (Chinese national XML format.

No matter what the outcome is of the current deliberations on Open XML, we will persist in our belief that diversity in innovation is a good thing and that goes for document formats as well as applications.

Applying the Interoperability Principles to Accessibility

jasonmatusow — Wed, 12 Mar 2008 02:15:17 GMT

As last week came to a close, I blogged about a few examples where Microsoft was applying the Interoperability Principles to its business. Much is being written about the role standards will play in the future of the software industry. It is important to understand that no software company or product can (or would want to) implement all standards. Or even support all standards in a given technology segment. All software producers will continue to build value-based solutions where competitive differentiation will remain critical to the success of their businesses.

Yet within the context of the production of commercial software, Microsoft has laid out a series of principles that will both enable and constrain design choices to some extent. Listening to customers, working with partners and competitors are activities that will take on even more importance (no matter how hackneyed it may sound) because it will be through those conversations that we can understand where real-world interop will be delivered and how the principles may be applied to achieve those goals.

So, let’s look at the world of accessibility technologies (AT). If there is a place where the industry (competitors and partners alike) should be focusing on delivering workable solutions – this is it. Rapid innovation of technology is essential to the social benefit delivered by things like text-to-speech, screen reading, alternative data entry devices, and a huge range of additional choices. In fact, if you look at the DAISY Consortium and the great work they are doing, you can start to see the complexities involved with matching AT with the pace of overall innovation in software/hardware from multiple vendors.

When you peel back the layers of the AT problem set, you quickly see that the interfaces, data formats, and protocols offered up by operating systems (“the platform”) are critical to the success of the AT vendors being able to produce technologies that can interact efficiently with the wide array of devices and applications out there. For example, the dozens of members of Microsoft’s AT vendor program provide hundreds of AT products for the Windows platform alone. (general info from MS on AT)

Microsoft has been watching a very interesting piece of work in ISO in a technical committee known as TC 159/SC4 – Ergonomics of human-system interaction. Before I move on – it is important to note that this is not JTC 1 (Joint Technical Committee 1), that is a joint effort between ISO and IEC. ISO does carry on its own business as well, and the work on a specific accessibility standard has been happening there. Microsoft has had limited involvement in the work of TC 159/SC4 up to this point. But they are in the final stages of a specification known as ISO/FDIS (final draft international standard) 9241-171 – Ergonomics of human-system interaction – Part 171: Guidance on software accessibility. The overall goal of the specification is to provide guidance on the design of software to achieve as high a level of accessibility as possible.

What has caught our attention is a sub-section of the specification – section 8.5 to be specific. Section 8.5 specifies high-level functional capabilities that software platforms (operating systems), such as Microsoft Windows, must provide to enable AT software to interact with other software on the platform.

This is good standards setting – the specification does not name any one platform, or mandate any one solution. It does not require any specific technology or API. This means that each platform vendor remains free to adopt the technologies and APIs that fit the specific platform design. The specification is about “what” not “how.” So Windows, SuSE Linux, Red Hat Linux, Mac OS, Palm OS, Symbian, or any other operating system can implement an accessibility architecture appropriate to that environment as long as they are offering up the capabilities (interfaces) that AT providers may use.

Based on significant requests from consumer advocacy groups and governments back in the 1990s, Microsoft built in extensive accessibility APIs in Windows. The existing technology is known as the MSAA, Microsoft Active Accessibility, and has been used as the foundation for hundreds of accessibility solutions. Additionally, Microsoft has introduced a more advanced, newer technology known as User Interface Automation (UIA) in Windows Vista and the .NET Framework 3.0, and is working with 17 other industry participants to define future versions of UIA in the recently formed Accessibility Interoperability Alliance (AIA).

Applying the Interop Principles

The third principle was stated simply as “Enhancing support of industry standards.” This is a very simple statement but carries extensive implications. I’m not going to rehash the implications of this – check out my earlier blog post on that.

The rubber meets the road on a principle when it comes time to think about a specific technology segment and think about the role of existing standards, in particular international standards, vs. what the company is building for its products. 9241-171 makes sense, and is drafted in a way that is inclusive for all operating system producers. Maximizing the benefit of innovation to citizens with disabilities comes from encouraging a standardized set of behaviors while encouraging all vendors (using all development models) to innovate rapidly and still bring competitive products to market.

Microsoft will support the ISO spec even though we were not the authors, nor are we currently particularly active in that committee. One way Microsoft will support this standard is to prepare a formal specification that describes the set of services provided by Windows to enable AT software to interact with other software on Windows. This technical report will make it easier for application developers to use the accessibility services provided in Windows. We are encouraging other platform vendors to produce similar technical reports.

Community is Part of Interoperability

As always, an important measure of a standard is the recognition of that standard by others, and the use of it for implementing real-world products. Even though the ISO standard isn’t final yet we can already see that 9241-171 is garnering serious attention in other accessibility standards work.

· ETSI references 9241-171 extensively in their Draft Technical Report 102 612, being developed as part of the EC’s eAccessibility Standards Mandate

· According to a note in the ETSI draft report Spain will replace their related national standards with 9241-171 when it is published

· It looks as if the TEITAC (advisory committee to the US Access Board on Section 508 standards) will recommend that the Access board harmonize with ISO 9241-171 in their update of the Section 508 standards

Time will tell how well 9241-171 is adopted in IT products, but based on the quality of the work done by TC 159/SC 4 in drafting the standard, and the interest we already see in it, we expect to see major improvements in the interoperability of accessible software products as platform, AT, and application vendors follow the guidelines laid out in 9241-171. The result will be a significant increase in the IT products more fully accessible to users with a broader range of abilities.

Good Standards Work - Bad Public Transparency

jasonmatusow — Wed, 05 Dec 2007 09:06:44 GMT

I absolutely knew we were going to see a posting like IBM's Rob Weir's latest. There was simply no question about it. My personal opinion is that greater transparency in the dispositions of comments for the Open XML BRM would be a good thing (see, I can agree with IBM occasionally). Brian Jones from Microsoft said the same thing in his blog today. That's nice...doesn't mean a thing because it is not up to Microsoft how that process will be handled. Nor is it up to IBM, nor is it up to Ecma, nor is it up to anyone else other than ISO/IEC JTC 1. Rob seems to think that Microsoft manipulated this outcome - ok...prove it. Please.

The thing that is ironical about this is that Ecma TC 45 is working diligently with The Project Editor and in a disciplined, thorough manner are working through the comments. They are doing good standards work and are seeking to improve the specification based on the comments submitted from national bodies (remember, mostly with comments from IBM - Rob Weir himself no less).

In truth, the process only dictates when the final dispositions document is to be completed. There is no mandate for early sharing of the dispositions. The fact that they are being made available ahead of time is to make sure that the National Bodies have as much time as possible to work through the dispositions. IBM did a great job during the balloting phase launching a veritable denial-of-service attack by flooding the process with the same comments over-and-over. The result is that every comment must be considered, and responded to, from every National Body (by the way, for standards laymen this is not typical. This goes above and beyond what is required, but TC45 and the Project Editor know how much attention is being paid to this spec.). The result is the need to have extra time to consider all of the dispositions.

IBM has membership in National Bodies around the world - they are an extremely mature company when it comes to their standards work, and know darn well who, and what rules, are governing the BRM process. Furthermore, as members of those committees they get to see the comments. In fact, Rob was kind enough to mention that he would be willing to share those comments with other National Bodies. Which, by the way, would seem to be a bit out of line - but that is probably neither here nor there.

As for the ODF process comparison - seems like an Apples to Oranges discussion to me. Ecma and OASIS have different processes - yep, I totally agree. That is a true statement. Also - caution, snarky comment - with all of that transparency Rob, why is it exactly that there was no BRM for ODF, and the comments went entirely un-responded to..oh yea, and that ODF has now progressed so far beyond the ISO ODF 1.0 spec as to be legitimately called a new specification, but has yet to be submitted back to ISO....ok, that is just tit-for-tat and probably useless.

Microsoft respects the process as defined by JTC 1. Full stop. We will continue to work in as constructive a manner as possible with Ecma, the Project Editor, SC 34, and JTC 1.

Interoperability For Accessibility

jasonmatusow — Sat, 17 Nov 2007 03:34:00 GMT

I have been on the road the past week, and it has kept me from sitting down to write about two steps Microsoft has taken in the past week and half, and what I see happening around accessibility technologies.

Just to make sure I have my terms clear - accessibility technologies (some refer to them as AT - yet another acronym) are generally any technology used as a means for citizens with disabilities to utilize computers/applications. From my limited understanding of the specifics of how this works, the majority of work is in dealing with inputs and outputs (seems obvious). So, either data entry (alternative keyboards, mice, use of optical technology), or alternative screen output (braille readers, text-voice, etc.). I'm sure there is more - but those are the basics. Furthermore, who might use these technologies is not limited to those with physical disabilities. Some would suggest that these technologies are critical for helping illiterate citizens, or the aging population, or others use computers to better their lives as well.

So, two things were announced this week by Microsoft. The one I have already blogged on was the open source project to build a translator for Open XML to DAISY XML. Users will be able to "Save As" DAISY from Office. By bringing this technology mainstream the opportunity for rich documents to be made available for use by a broader community is a very powerful thing. If you wonder at how important this is, just recall the discussions of importance for document formats to be accessible during the Massachusetts ETRM discussions a while back.

The effects of that can be clearly seen in the strong push (mean $ spent, and resources dedicated) by SUN and IBM to get cracking on converting a Microsoft technology (MSAA) into what they are calling iAccessible2 (work being done at the Linux Foundation). I think it is great that everyone is paying more attention to these issues, as the real winners in this scenario are those who need technology the most.

So, the DAISY work is one item. The other is related, and arguably more important. Microsoft has committed itself to working on interoperability for accessibility technologies. In order to do that, you need to dig a layer deeper - and think about how Windows and Linux as platforms relate to the accessibility story - and how interop is important there.

Enter the Microsoft/Novell relationship, and the fact that the newest piece of technical collaboration between the two firms is around...yep, you guessed it...accessibility. This is something that the entire Linux community should be happy about.

1) Microsoft is making its User Interface Automation (UIA) specification available under the community OSP (MS promises not to assert patents necessary to implement UIA in perpetuity, against anyone in the world).

UIA is the next generation of accessibility technology. It takes AT work out of process - meaning that customers will have a better long-term experience with greater application choice at the same time that AT Vendors will have greater return on their development investment.

2) Novell will build (with input from MS) the UIA framework on SUSE Linux - allowing it to interop with the Linux Accessibility Toolkit (ATK) which ships with SUSE Linux, Red Hat Enterprise, and Ubuntu Linux.

3) This release of technology, and development, will be done in such a way as to complement, not compete, with AT work that is being done by IBM, Sun, and others as they work on iAccessible2 as well as other Linux-related projects.

Brief Analysis

I always had a good relationship with my parents, but when my cat Snooky died I....oh, wrong kind of analysis.

This is a long blog post already so I will be brief.

The DAISY announcement should highlight yet again how important the idea of translation is to the document format discussion. Other than the rhetoric around ODF, there is no supporting the idea of single format - it is not practical, and it is detrimental to innovation. Translation, translation, translation - software is endlessly malleable and flexible.
I've said this before - interoperability is about connecting people, data, and diverse systems. If you break that into its component parts, it means looking at an issue holistically. Interop for accessibility will not be solved by any one specification or standard. It will be solved based on implementations in products, collaborative agreements/projects between vendors, IP structured for collaboration, and standards based on quality specifications. All of these elements are becoming evident in the AT space.
The Novell/Microsoft agreement continues to add value for customers and for the industry as a whole. Not only did the announcement of last week talk about 30 new customers who are moving to the Novell/MS solution - but it spoke of momentum around virtualization, systems management, directory, identity management, and doc format interop. Now, accessibility can be added to this list.

Interoperability is never going to be "solved." Every new technology, every new product or dev project, will create new interop challenges. The real measure is based on consistent, specific, actions that contribute to an overall commitment to interop. And, like any other facet to business - each move has to have a business case behind it that makes sense otherwise there is no return on the investment.

Just Sittin' - Pickin' A DAISY: translation and doc formats

jasonmatusow — Wed, 14 Nov 2007 15:31:00 GMT

In case you missed the news on this yesterday - Microsoft and the DAISY (Digital Accessible Information SYstem) consortia announced that Microsoft Office will support "Save As" DAISY using Open XML files in Office XP, Office 2003, and Office 2007. This is going to be done via a translation project hosted on SourceForge (yes, that makes it an open source project).

Before I share my take on the news as it applies to the Open XML discussion in general - let me say that this is just a rock solid thing to do because it is going to have such broad, positive implications for delivering value to citizens with disabilities. It is going to improve access for uses beyond the traditional view of someone who is sight-impaired. This can help with illiteracy, or with richer text-to-audio use for any use.

So, how does this tie into the discussions around the JTC1 process under way today.

1) TRANSLATION is fundamentally where interop happens for document formats. I can't emphasize enough how bogus I think the one document format discussion is. In the "there can be only one" arguments I have heard over the past 18 months for ODF - where exactly does the DAISY XML format fit in? Should the DAISY folks abandon their work on DAISY XML and just roll it all into ODF? Or, should the community working on ODF work to create translation to DAISY XML? I'm in favor the translation option. Software is fundamentally more flexible than any other medium - there is NO requirement for uniformity in order to offer the value of interop along with the value of unique innovation.

2) The open source project for this translator will be picked up for INDEPENDENT IMPLEMENTATION. Application vendors, non-commercial developers, etc. are going to be able to pick up this translator and create solutions that have nothing to do with Microsoft Office. I have written on the fact that Open XML is already seeing broad pickup by implementers - and this is going to only emphasize the value of doing that even further.

3) DOCUMENT FORMAT OPENNESS is valuable. No one is doubting this and it is just as true for Open XML as it is for ODF. The long-term outcomes from this collab with DAISY are going to simply prove that further.

The work on the ballot resolution process continues to move along towards February. Great, fine, good. Clearly, for the sake of the specification, the improvements made through the comments will be of value. But, the realities of the marketplace are showing both the adoption of the specification (which is the single most important measure of the quality of technology and specification) and the flexibility it has made available to all vendors.

In case you are interested...here is some of the coverage: