Applying the Interoperability Principles to Accessibility

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.

Comments (2)

  1. hAl says:

    The Software Freedom Law Center claims that the OSP is incompatible with GPL licensing

    A particular phrase I find strange and which requires response from Microsoft:

    "They (developers) would also be unable to distribute their code for any type of use, as is integral to the GPL and to all free software."

    In the conclusions they state:

    SFLC recommends against the establishment of OOXML as an international standard and cautions GPL implementers not to rely on the OSP.1

    Clearly that conclusion show the intent of why the piece was written (especially seeing the timing but I think the statement that suggest GPL code that implements OOXML cannot be distributed under GPL should be addressed.