Wednesday July 25, 2007

Aaron Leventhal - Best Accessibility Architect

My friend and colleague, Aaron Leventhal, has just been honored by Google-O'Reilly Open Source Awards for his tremendous work leading the Mozilla accessibility project. I'd like to quote their description of Aaron:

In addition to his years of work in desktop accessibility and Braille transcription, and his more recent work on Mozilla accessibility in general, Aaron has been instrumental in bringing Mozilla Foundation grant funding to bear on accessibility issues - funding such good works as the Orca screen reader's support of Firefox, and most recently NVDA's support of Mozilla Gecko on Windows.

Congratulations Aaron for this very well deserved award! (2007-07-25 19:54:34.0) Permalink

Final(?) draft of the Accessibility Guidelines for Implementations of Open Document Format v1.1 available

In addition to our peer-review of the OASIS Open Document Format, the OASIS ODF Accessibility Subcommittee is also charged with development of Accessibility Guidelines relating to ODF. I'm delighted to report that what I hope is the final draft of the Accessibility Guidelines for Implementations of Open Document Format v1.1 is now available. This ~50 page document describes the accessibility features of ODF v1.1 and how applications that implement support for ODF should utilize them. It also contains some information for authors, but primarily it is for ODF implementors. It also contains a fairly lengthy glossary of terms, and a description of accessibility and assistive technologies, as we don't presume that all ODF implementors will have that knowledge.

After we do a final check of this draft, we will post it prominently so that all ODF implementors will likely see it (and hopefully thoroughly read it and abide by its recommendations!). (2007-07-25 18:42:28.0) Permalink

Tuesday July 24, 2007

University of Toronto white paper "Accessibility Issues with OOXML"

Jutta Treviranus, Director of the Adaptive Technology Resource Centre and Dr. Stephen A. Hockema, faculty member of Information Studies - both at the University of Toronto - have just published the white paper "Accessibility Issues with OOXML". This paper describes some of the accessibility challenges that people with disabilities face with office documents and office formats generally, and then notes the accessibility issues that they have found in OOXML. Treviranus & Hockema note in the overview of the paper:

Even though they state that their work is a "cursory glance", rather than a "thorough accessibility review", their paper notes a number of specific technical issues, some of which come from their inspection of the ~6,000 page OOXML specification (and others from the Microsoft white paper "Accessibility of Ecma Office Open XML File Formats").

Here is the two paragraph introduction to their paper:

And here is the one paragraph conclusion of their paper:

There is quite a lot more in between introduction & conclusion, but I fear I wouldn't do it justice trying to summarize here. I encourage you to read the original yourself! (2007-07-24 16:54:53.0) Permalink Comments [1]

Thursday July 19, 2007

Mr. Happy goes to Washington

This week I attended the fifth Telecommunications and Electronic and Information Technology Advisory Committee Meeting in Washington DC. It was a good, interesting, hard, and productive meeting. A colleague who I have tremendous respect for – Andi Snow-Weaver of IBM who co-chairs the Web and Software (and Content and Authoring Tools) subcommittee – took the opportunity to publicly thank me for some of my work on her subcommittee. Specifically, to thank me for being the first person of several who were given the task of reviewing a document format against a set of draft content standards we were discussing (ODF v1.1 in my case).

I've been working on accessibility for more than 15 years now. In that time, I have been honored to receive on behalf of Sun the American Foundation for the Blind Access Award for Java Accessibility work, and the Helen Keller Achievement Award for GNOME accessibility work. I was had the opportunity to speak on behalf of UNIX and open source accessibility at the 2003 Trophee du Libre when the Sun-funded GNOME On-screen Keyboard received the award in the accessibility category.

But I was frankly gobsmacked when Andi presented me with the Mr. Happy award for doing the ODF v1.1 accessibility review. The award is the Mr. Happy character realized as a gel pack you can heat up or chill for use on sprained muscles - especially for children. She stated that it was for the "bumps and bruises" that I might experience working on accessibility standards. I became "Mr. Happy" for the rest of the meeting. It is an experience, seared in my memory, that I will, um, treasure always.

By the way, I want to note here in this space that Andi's work on the Web and Software (and Content and Authoring Tools) subcommittee has been tremendously helpful. In fact, so much so that she reminds me of another Roger Hargreaves character - his Little Miss Helpful.

(Andi, don't say I never thanked you...) (2007-07-19 16:22:09.0) Permalink

Saturday July 14, 2007

Continuing the conversation with Gray Knowlton, Group Product Manager for Microsoft Office

Gray, I want to thank you again for taking the time to continue this conversation through your latest blog comment. I know that others reading these blog postings appreciate it as well - several folks have told me that they find the discussion useful and illuminating. I appreciate your candor, and I feel that with this reply you have answered all of my questions. Thank you.

Also, I very much appreciate your comments about the importance of being supportive of the energy and enthusiasm and contributions of folks new to the field. I've said so privately, but let me reiterate publicly: Reed, I apologize if anything I have said has made you feel uncomfortable, was unwelcome, felt harsh or critical. The IT accessibility effort needs the energy and enthusiasm and contributions of folks new to the field - folks like you and many others I have had the pleasure of meeting. In no way do I want to discourage your work.

Gray - you have graciously invited me to contribute to the Ecma OOXML accessibility effort, and I'm glad that you have found at least some of the questions I've raised thus far to be useful contributions. I'm sorry, but alas I must decline your invitation to particulate in a more formal way. I am quite busy with other work - with contributions to ODF accessibility, and contributing to the development of open source and free access solutions (and the growing community of users/developers around that). I am also deeply involved in the Section 508/255 Refresh activity, where I have the distinct pleasure of working on with, among others, several dedicated folks from Microsoft's accessibility team. Then of course there is my "day job" at Sun...

I'm glad to hear that you plan to take my questions and criticisms constructively, with the aim of improving OOXML accessibility. Accessibility work is never done; perfect accessibility remains an elusive goal that we all of us must continue to strive toward. It does feel a little odd, though, for a Microsoft representative to invite contributions to the Ecma OOXML work from an OASIS ODF subcommittee co-chair whose company is not an Ecma member. Microsoft, an OASIS member, declined to participate in the OASIS work on ODF. In fact, I note that this is the second time it has been suggested that I contribute accessibility expertise to a new Microsoft standards effort, when there is an already existing standards effort in that area that Microsoft refuses to join.

Separate from my lack of standing in Ecma, and in addition to being rather busy at the moment, there is another reason that I am not motivated to become further involved with Microsoft OOXML accessibility. I have several times before tried to contribute to Microsoft accessibility efforts, and each time before been disappointed. In 1995 - shortly after Microsoft reacted to a major blow-up in the disability community in Massachusetts over a different CIO's decision to standardize on the (then inaccessible) Windows 95 desktop - I attended a 3-day Microsoft accessibility summit. At that summit I spoke passionately and at length about the things I felt Microsoft needed to do to truly address accessibility concerns in their OS and applications and tools. Later, in 1995/1996, I accepted a Microsoft invitation to Redmond for a couple of days of meetings and presentations to Microsoft OS engineers to help develop an accessibility architecture for Windows. In both cases, I came away feeling that my remarks and energy fell on mostly deaf ears. The suggestions I made in the 3-day summit were little acted on. The accessibility framework I attempted to contribute to became MSAA - a tremendous disappointment to me and others who had hoped for a comprehensive accessibility framework that would eliminate the need for all of the reverse engineering & special casing work that AT products still have to do today in Microsoft Windows. So please forgive the skepticism that I bring to these discussions; they are informed by a decade-long history I have with Microsoft on accessibility.

Shifting gears, there are a few things that you said in your comments yesterday that I'd like to respond to. In replying to one of my questions (also quoted below), you said (with emphasis added):

I'm sorry, but I must strongly disagree with the notion that ODF v1.0 had "no accessibility support". Please note that I have never suggested OOXML had no support for accessibility. Rather, I believe there are important questions as to how complete and sufficient that support is. But you and Microsoft have just now made that claim about ODF v1.0. I'm sorry Gray, but to me this is just a continuation of Microsoft attacks and disinformation about ODF that began in Massachusetts nearly two years ago. Especially coming from someone who says he has no accessibility background and expertise, it truly calls into question your assertion from your most recent reply, where you said: "I'll happily continue to engage with you on the topic as long as we’re both helping to contribute to accessibility, rather than the Open XML vs. ODF Debate; that’s not something I’m interested in participating in."

As I noted at the beginning of discussions around ODF accessibility in 2005, ODF v1.0 was "based on standard web technologies like SMIL for audio and multimedia, and SVG for vector graphics, which have and continue to be vetted by the World Wide Web Accessibility Initiative processes". I further noted that "we also know that two of the existing applications that currently read/write ODF can export Tagged PDF files in support of PDF accessibility, and Adobe has already conducted some tests to verify that accessibility across that translation is preserved (and thus must exist in the original ODF file)." While I didn't say so at the time, please note that, like OOXML, ODF v1.0 was derived from an earlier file format which had many years of expert accessibility attention paid to the application that creates files in that format. This is precisely why, after a thorough evaluation of the ODF v1.0 format for accessibility, the OASIS ODF Accessibility subcommittee only found 9 accessibility issues to correct.

In your comment yesterday, you also wrote: "I sense that this post is an attempt to use this report against Open XML in the future; for example, to have information you can use in an ISO committee meeting to criticize the specification." Accessibility has become a theme, a subtext in the larger debates around acceptance of ODF or OOXML by various bodies and governments and customers; in the debates about the suitability of ODF or OOXML for use in various places. As the market for office suites runs to the tens of billions of dollars a year, it comes as no surprise that some folks who are partisans to one format or the the other may seek any advantage they can to further their favored format. As I noted in November of 2005, it was Microsoft who brought accessibility into these debates, by attacking ODF on accessibility grounds.

I said in my first posting about your report, "Since the start of the discussions around office document accessibility nearly two years ago...I have seen NO clear and technical discussion of the accessibility of the Microsoft OXML format. Rather, in meetings I've been part of, Microsoft representatives have simply stated that since Microsoft Office is accessible... it is automatically the case that the underlying file format fully supports everything needed for accessibility." Your report represents the first actual review of OOXML accessibility after nearly two years of office document accessibility debate, and so therefore it is naturally the subject of a lot of interest and scrutiny.

Bottom line: when it comes to the acceptance of OOXML - in standards bodies or governments - I think there are three related things going on with respect to accessibility:

1. The accessibility of office documents has appropriately become a significant issue - in Massachusetts and worldwide. In response, Sun, IBM, the Royal National Institute for the Blind, the Institute for Community Inclusion, Design Science, and several individual disability experts and users with disabilities did a tremendous job analyzing the ODF v1.0 spec for accessibility. The resulting contributions to ODF v1.1 led us to say that "we believe that ODF will meet or exceed the accessibility support provided in all other office file formats as well as that specified in the W3C Web Content Accessibility Guidelines 1.0". The Commonwealth of Massachusetts made it clear to Sun and IBM that they would not accept ODF v1.0, but instead insisted that the OASIS standards body make ODF v1.1 - with the results of our accessibility improvements - an OASIS standard before they would move forward with the plans set forth in ETRM v3.5 to deploy OpenDocument Format for their office documents. Given the issues that your project has highlighted in OOXML, the fact that there are unanswered accessibility questions (such as those I have highlighted with respect to DAISY and Braille conversion), and the fact that there has been no authoritative accessibility review of OOXML to date; I think it is reasonable to ask why the Commonwealth of Massachusetts should add OOXML to their set of acceptable document standards? If the Commonwealth insisted that ODF 1.0 wasn't acceptable - that only the standardized output of an accessibility peer-review of experts and technical individuals/users with disabilities would meet their needs - then shouldn't any other proposed format have to meet the same standard? Shouldn't Massachusetts insist that Ecma standardize on an OOXML v1.1 with accessibility improvements before OOXML can be deployed? Why should another document format receive less scrutiny? Why should another document format be held to a lesser standard?

2. As was done in Massachusetts in 1994/1995 with the threatened embargo of Microsoft products due to the lack of Windows 95 accessibility, disability advocates in Massachusetts have raised the consciousness of folks throughout the world; this time around the importance of office document accessibility. They have made it clear that the needs of people with disabilities should be thought of and addressed in advance of a standard being accepted. They have made it clear that people with disabilities should be part of the standardization and review process (the adage "nothing about us without us"). They have, in essence, raised the bar on accessibility. I've seen recognition and appreciation of this in Denmark, and Belgium, and France, and England - everywhere that I have traveled and met with disability group and government document accessibility standardization folks. In each of these places, the folks adopting ODF have made it clear that they plan to use ODF v1.1 instead of ISO/IEC 26300 (ODF v1.0). They all want the version resulting from the accessibility peer-review. Yes, ISO standardization of ODF is important to them; many European organizations place an important emphasis on ISO standards. But the ISO imprimatur of ODF wasn't sufficient for the folks I met with; they required the results of our accessibility work before they would use it. For those governments and customers who care about accessibility, this higher bar is entirely appropriate and should be used.

3. At some point the standards bodies themselves will come (are coming; perhaps have already come) to recognize the importance of accessibility concerns as a pre-requisite for standardization. As I noted previously, a principle established by the European Council eAccessibility Resolution of February 2003 is that people with disabilities should be empowered "to take more control over the development of the mechanisms for delivering eAccessibility", and "by support for their increased participation in standardisation bodies and technical committees". One can argue whether it would be fair if ISO - or more appropriately, the countries who vote on ISO standardization - were to raise the bar on accessibility for one office document standard (e.g. OOXML) after approving an earlier standard without such an accessibility bar (e.g. ODF v1.0). In fact, I've heard Microsoft representatives make that very argument. But that bar should appropriately be raised; and when it is raised it will require more of those that come after than those that came before. This is ever the case when we raise the bar on something, and insist that things be changed - whether it is recognition that slavery is wrong, or that women should have the right to vote, or that "separate but equal" isn't at all equal, or that affordable access to technology and government documents is a basic right of citizens in the Information Society. It would be a poor argument indeed that U.S. presidential candidates in 1920 shouldn't have to take into consideration womens' votes since in 1916 Woodrow Wilson didn't have to worry about them. And please remember, there are more document formats & format revisions in the ISO queue. Do we make the comparison argument indefinitely? When ODF v1.2 (or whatever) comes to ISO for standardization, a raised bar should of course apply to it. Likewise to any new PDF standards. And if Microsoft's XPS "XML Paper Specification" goes through Ecma and on to ISO, a raised bar should apply to XPS as well.

So to conclude this current exchange... thank you again for taking the time to illuminate the work your team has undertaken thus far on OOXML accessibility. Thank you for making it clear that you feel that a more complete accessibility evaluation of OOXML is needed, and that you intend your white paper to be the start of that work. I look forward to hearing more from you, your team, and an OpenXML Developer effort to thoughtfully and thoroughly analyze the accessibility of OOXML.

I make no apology for increasing accessibility requirements, nor for my advocacy of them. Next week at the 5th public meeting of the Telecommunications and Electronic and Information Technology Advisory Committee, I will continue the work of raising the bar on accessibility - working with my counterparts at places like Adobe, IBM, Microsoft, and others in industry; with expert users from the disability community including the American Council of the Blind, the American Foundation for the Blind, Communications Service for the Deaf, the National Federation of the Blind, Paralyzed Veterans of America, and other notable organizations; and with disability experts from U.S. Universities, from independent consulting firms, and from the international community. Raising the bar on accessibility and building architectures to make technology more accessibility is what I do. It is what I have been doing for the last 15 years.

People with disabilities - especially folks with severe disabilities like blindness and total hearing loss and severe physical impairments - face some truly severe barriers in technology. It is morally incumbent upon the people developing technology - like the two of us - to work diligently to remove those barriers. I'm sure you will agree that we must continually raise the bar on accessibility ; continually challenge ourselves to do an increasingly better job ensuring that everyone has the fullest possible access to and use of the products, technologies, and standards that we create. When it comes to technology for people with disabilities, we should not accept any backsliding on what is possible. Nor on what is acceptable. (2007-07-14 13:25:54.0) Permalink

Monday July 09, 2007

Talking with Microsoft's Gray Knowlton about MSOXML accessibility

Late last week, Gray Knowlton wrote a lengthy blog comment, sharing some of this thoughts about my review of the Microsoft white paper "Accessibility of Ecma Office Open XML File Formats" that Gray posted to the OpenXML Developer website. Given the importance of the office document accessibility, and the attention that ODF and MSOXML are getting with respect to accessibility, I wanted to continue the conversation directly in my blog (vs. buried in a comment to his comment). The rest of this is written directly to Gray...

First, Gray, thank you for talking the time to have this discussion - and thank you for correcting my misspelling of your name (oops!). You mentioned that you undertook this review "in part to educate a few individuals who claimed that “Open XML does not support accessibility”" but that "it was not intended to be a definitive guide to accessibility of Open XML". Can you tell me, has Microsoft - or anyone else - done a thorough review of MSOXML accessibility? Education, and "correction" of "significant misunderstandings" is one thing; a thoughtful and thorough accessibility review is another. Is this white paper the former, or the latter? If as you say it is the former, what about that thoughtful and thorough accessibility review?

Gray, at the start of your blog comment you say "I’m not sure that the “who did this?” question matters as much as your post seems to indicate", and you spend several paragraphs describing your (non-accessibility) background at Microsoft and Adobe. You also noted the name Reed Shaffner, as "a member of my team specifically focused on the accessibility of the Microsoft Office system", though you don't mention whether he was involved in writing this white paper (by the way, is this Reed Shaffner the author of these two blog posts? the new hire from Duke University who last year was a college senior and who presented a paper Linking Pgm allozyme and nucleotide variation in blue mussels at a Colorado Evolution conference?).

The reason I raise the question of authorship of the white paper is to better ascertain the level of accessibility expertise involved in the review. MSOXML has gone through the ECMA standards process, and is up for vote and adoption by the International Standards Organization, and is being evaluated by many countries and U.S. States for use and standardization in their organizations. Knowing whether a thoughtful and thorough accessibility evaluation was done on MSOXML has an impact on folks in many of these places.

Elsewhere in your comments, regarding my question about the use of WCAG 1.0, you note: "We are aware that the WCAG1.0 guidelines might not be the most appropriate of benchmarks today, but there are few finalised alternatives. I do work with our accessibility team on evaluating Open XML against the developing standards, and as I am sure you are aware we are active participants in these processes; however it would not be appropriate at this point to publish anything until those efforts are completed." I understand that issue, but then why do you use the XML Accessibility guidelines, which are only in draft form? It doesn't seem consistent to me...

And speaking of questions, I hope that we can continue this conversation, and that you might address the other questions I raised in my review. To quickly summarize them:

Blog question #2 (unaddressed):When and how will the accessibility failings cited in the paper be fixed?

In your evaluation, you note that MSOXML fails to support WCAG 1.0 checkpoints 4.2, 5.2, 9.4, 10.2, 12.1, 12.2, and 12.4, and that MSOXML only partially supports checkpoints WCAG 1.0 checkpoints 6.4, 8.1, 9.1, and 11.1. Some of these have quite significant impacts on folks with disabilities, including especially those who use assistive technologies to access office documents. For example, WCAG 1.0 Checkpoint 9.4 requires that you have a logical TAB order through all of the links, form controls, and objects within a document. Without this, keyboard only users won't be able to get to and manipulate all document content; screen reader users may miss some sections of content altogether. Another example: WCAG 1.0 Checkpoint 12.4 requires that all labels be explicitly associated with the objects they are labeling. Without this, blind folks using screen readers have a lot of trouble figuring out what a control is when they TAB so it - imaging hearing "edit field; edit field; edit field" as you TAB through a form, instead of "name edit field; address edit field; city edit field".

Blog question #4 (unaddressed): How does MSOXML meet accessibility needs outside of WCAG 1.0 & the W3C XML Accessibility draft? How well does MSOXML support translating into DAISY and Braille?

Perhaps your comment "The scope of the original project was not intended to provide the more significant contribution to the accessibility community you describe in your post" answers this, but it wasn't clear to me from your reply, and I don't want to make poor assumptions (misspelling your name is bad enough!). Does Microsoft know how well MSOXML supports the requirements of DAISY book creation? How well is supports the creation of Braille publications? How well it meets other accessibility needs? Does Microsoft have any experienced accessibility people looking at MSOXML, evaluating against accessibility needs independent of W3C accessibility specs?

Blog question #5 (unaddressed): Is there a difference between the phrases "supported" and "fully supported" in the white paper? When the white paper says that a provision is only "partially supported", what is missing?

Since you use "supported" in some places, and "fully supported" in others, it strongly implies there is a difference. Is there? Is merely "supported" less than full support? And when you note that MSOXML only "partially supports" an accessibility checkpoint, you don't say what is missing. Could you please elaborate on that missing support?

Blog question #6 (unaddressed): Why is the white paper so lacking in clear "supports" statements about the XML Accessibility guidelines?

The style change from the white paper text about WCAG 1.0 vs. XML Accessibility checkpoints almost suggests two different authors. But whatever the reason for it, it leaves a reader like me unable to form a clear picture of how MSOXML stacks up against the XML Accessibility checkpoints.

Separate from these questions - which I hope to read your answers to soon - I want to touch again on this comment of yours: "the scope of the original project was not intended to provide the more significant contribution to the accessibility community you describe in your post, but I posted this project to OpenXMLDeveloper.org specifically for this reason. I do hope this project can become the contribution that you and others have expressed interest in evaluating." Many people - me among them - are not in a position to review a 6,000+ page specification. Microsoft has been working on accessibility for at least the past 20 years, and is the author of that that massive specification. Shouldn't Microsoft have its experienced accessibility experts working on this, rather than hoping that others work on it for you?

On a different topic, I'm curious about your comment regarding my P.S. about an accessibility problem I noted in the PDF edition of the white paper. You said: "I am somewhat embarrassed to have not used the tools in Acrobat for making PDF documents more accessible. I did create a Tagged PDF, as you noted, but I haven’t installed Acrobat on my new hardware yet, so I did not have the ability to edit the PDF to correct this easily." Did you use Word 2007 to create the white paper, and the Export to PDF function to create the PDF? In other words, is this the result of a bug in the accessibility functionality of Word 2007's PDF export feature (as you say that you need Adobe Acrobat to "edit the PDF to correct this easily")?

Finally, fair is fair. You asked me a question:

First, let me forward you to Andrew Kirkpatrick of Adobe, who writes the Adobe Accessibility Blog, and who along with me and 40 other folks is a member of the Telecommunications and Electronic and Information Technology Advisory Committee providing recommendations for updates of accessibility standards issued under section 508 of the Rehabilitation Act and guidelines under Section 255 of the Telecommunications Act. Perhaps you met Andrew during your time at Adobe? In any case, Andrew and Adobe are the experts on PDF accessibility, not me and Sun...

That said, please let me observe that PDF/X-1a (also known as ISO 15930-1:2001) and PDF/X-3 (also known as ISO 15930-3:2002) are "graphic technology standards" for use in "prepress digital data exchange". They are subsets of the full PDF standard. They are not for editable office documents; rather they are for the final step in a print document's life prior to being sent to the printer (whether that document started out life as a spreadsheet or a glossy 4-color magazine advertisement). Mathematical equation editing happens upstream - in places like office documents or other formats dedicated to preserving all of the semantic meaning of the equation. Likewise the gathering of form data.

Anyway, where I believe it makes sense to ask these questions is with PDF/A-1 (also known as ISO 19005-1:2005). This is a "document management" standard, which is described as an "electronic document file format for long-term preservation". It is here (rather than while in transit to a printer) that the preservation of accessibility information is important, and where our accessibility attentions make sense. I haven't yet read that standard, so I can't speak to what W3C specifications it does or does not incorporate. As I find out more, I'll post the answers here. (2007-07-09 20:45:12.0) Permalink Comments [6]

Wednesday July 04, 2007

Vacation!

For the first time in far too long, I took a vacation. My wife and I went to Hawaii. We went diving in Kona with Dive Tek Adventures, snorkeling in Hanauma Bay on Oahu, and we explored the results of Pele's wrath in Puna on the Big island. Here is a brief travelogue, with lots of photos!

We dove with Dive Tek for two days. They were incredibly accommodating, moving their normal 7:30am departure time to to 9am so that we could drive in from Naalehu without having to get up at 0-dark-30 in the morning. They also got us special steel tanks - 116cuft for my wife, and 92cuft for me (as opposed to the normal sized aluminum-80s). This meant our typical dive lasted over an hour (being in 78-82 degree F water, with 3mm full wetsuits helped too).

On our first day of diving with Dive Tek we went to "Hoovers", a site named John P. Hoover, author Hawaii's Sea Creatures and Hawaii's Fishes and a number of other great books. Our dive started with a Eagle Ray encounter, followed by a pair of dolphin sightings. We saw an incredible school of fish. We saw them coming, we saw them up close, and then we saw them swiming away. This was followed by a large cornet fish. In addition to the fish, there was a lot of neat stuff on the sea floor. A careful scan turned up this sea star. While we didn't see any nudibranchs on this dive, we came across the most amazing egg rose of a Spanish dancer. If you look closely you can see the individual eggs. Also among the rocks were eels. We saw both a white mouth eel (here is another photo, up close), and a moray eel. And while we didn't see any whales, we did see what one had left behind...

On our second day with Dive Tek, we started our day with a dive in Octopus Garden Cove. At about 80' depth, you see off in the blue a garden of eels, waving in the water. If you are still and wait long enough lying on the bottom, the closer ones will start to come out of their holes. Just incredible! On this dive we saw a bunch of Crown of thorns starfish. They would grasp a rock like some giant, spiked hand. In fact, their thorns/spikes are quite long and pointy! I love this fish photo, with our dive guide Jeanine in the background. Jeanine warned us that some of the sea slugs would spew a sticky mucus if disturbed. Unlike the previous day, on this dive we saw some amazing nudibranchs, including this divided flatworm. In this cool series of pictures we see another nudibranch that is rapidly heading down a rock. He was reaching toward this pencil urchin. Also hiding in crevices in the rocks was this moray eel. As I got close, the eel backed away from me. One of the other folks diving with us shined his HID light on this frogfish - an amazing end to a fabulous dive!

On our final dive with Dive Tek, we went to a spot called High Rock (which is an underwater pinnacle just 40' below the surface). There isn't a lot of soft corals in Hawaii, but I came across this neat white soft coral at the start of the dive. Soon after, this Butterfly fish appeared. One great thing about diving with Jeanie, she would point out neat stuff to us throughout the dive. Moray eels are common in Hawaii, and High Top was no exception. I had trouble with the flash on my camera (the external Sea and Sea YS-90DX that I use with my Canon PowerShot S50 in it's WP-DC300 underwater housing decided it didn't want to turn on). But I managed to use the built-in flash on the camera, through the housing, to get some light on the eel. Unfortunately the built-in flash isn't adjustable, so the lighting wasn't even. That same uneven lighting effect can be seen here, lighting the rocks that this soft coral was growing from (it is truly amazing just how much red is present, but not visible underwater without a bright light). On this dive my wife found a nudibranch, and you can tell that the rock it is traveling on is quite red (assuming you have a flash...). This dive also ended on a high point, as another diver called us over to see an octopus hiding in the rocks. And with that, we made our way to the stairs that Dive Tek kindly put out for us.

I also took a bunch of photos during our day of snorkeling at Hanauma Bay. Being nor more than 10' under water, there was plenty of sunlight penetrating the water. Unlike diving, however, as a snorkeler, I was much less a natural part of the environment, and fish would commonly swim away from me when I dove down to take their picture. Sometimes I would get lucky from a distance. And then there was this fellow who got all curious about me. He kept close to me, and hung around me for much of my snorkeling trip. In the middle-outer bay, I came across a cleaning station (the small blue & white fish is cleaning the others, who are all hanging out waiting their turn). I mentioned that a lot of light penetrates at this shallow depth, as is evident from the colors on this fine fish. As I started heading back in to the beach, I saw another colorful guy, but he was bashful and didn't want his picture taken. He was briefly joined by his smaller, colorful friend. But it was getting late, and so we headed in hoping to make it to Legend Seafood for Dim Sum. Unfortunately, the fabulous fish had been too tempting, and we missed our lunch...

Of course, there is more to see in Hawaii than what is under water. While we didn't get to see flowing lava on this trip, we did spend time in Puna on the Big Island, where there is a lot of amazing "new land" to check out. Here in this forest of trees and other things we came upon a lava tree. During a lava flow some time back, the lava surrounded a still-standing tree, which then died from within, leaving a hollow lava tree shell. Elsewhere in Puna, we could see coconut impressions left in the cooling lava. We went to Kalapana where a lava flow in 1990 wiped out the town and the beach. While only 17 years old, this new land is already sprouting life. Walking through the black moonscape of the lava field, we would frequently come upon ferns growing in the cracks of the brittle, glass-like lava. As we approached the Ocean's edge, we saw a field of newly planted coconut trees in the distance, behind a small thicket of ficus. Incredibly, in this thicket of ficus we found a gecko and a salamander (the green gecko is barely visible, hiding along the horizontal branch toward the left side of the photo).

Our trip to Hawaii was amazing, if too short. I hope we manage to return soon... (2007-07-04 20:46:17.0) Permalink Comments [1]

Tuesday July 03, 2007

Reviewing the "Accessibility of Ecma Office Open XML File Formats"

Since the start of the discussions around office document accessibility nearly two years ago - with the publication of Commonwealth of Massachusetts' Enterprise Technical Reference Model v3.5 in September 2005 specifying the use of OpenDocument format for office documents - I have seen NO clear and technical discussion of the accessibility of the Microsoft OXML format. Rather, in meetings I've been part of, Microsoft representatives have simply stated that since Microsoft Office is accessible (only when running on Microsoft Windows, and for the blind only when running with expensive 3rd party assistive technologies), it is automatically the case that the underlying file format fully supports everything needed for accessibility. This has been the first, last, and only word on the accessibility of MSOXML even while many European countries and American States have considered standardizing on an office file format - and grappled with accessibility concerns arising from that consideration. And while several folks I know in the accessibility field have contemplated undertaking such an evaluation of the file format, the 6,000+ page specification for MSOXML proved an effective deterrent.

That finally changed yesterday morning, with the publication of the "Accessibility of Ecma Office Open XML File Formats" white paper at the OpenXML Developer website. This welcome - if late - development allows us to finally start to have a real technical discussion of MSOXML accessibility, and to start to compare MSOXML accessibility support to what is in OpenDocument Format v1.1.

The 38 page "white paper discusses the Accessibility features of Open XML and using the Web Content Accessibility Guidelines 1.0 and XML Accessibility Guidelines ." It begins with this cover text:

This Microsoft-proffered document goes through each of the checkpoints of the May 1999 Web Content Accessibility Guidelines v1.0, and the 3rd Draft, October 2002 XML Accessibility Guidelines, and describes whether and how MSOXML supports these checkpoints. One particularly nice thing this document does for many of the checkpoints is to illustrate in XML precisely which MSOXML tags one would use to support that checkpoint. For example, for Checkpoint 1.1 of WCAG 1.0, on pages 7 & 8 the white paper shows how to use the tag to annotate shapes, grouped objects, and line/arrows with text equivalents, and the tag to do the same thing for images, charts, and 3D objects. These XML fragment illustrations are present for most of the provisions that Microsoft claims MSOXML supports.

While a very welcome contribution to the discussion of office file format accessibility, this document raises a number of new questions, even as it answers others:

1. Who did this review? The white paper contains no list of authors, nor even the name of one or more groups at Microsoft. The only person associated with this document is Gray Knowlton, an openxmldeveloper.org member with no bio, and only one posting to the website to date. He appears to be a Group Product Manager for Microsoft Office, focused on Technical Product Management. What about people with accessibility expertise at Microsoft? I presume at least one of them was involved, but with what background? What about folks from the disability community. Was anyone with technical background from a blindness organization invited to contribute? Anyone with physical impairment expertise? Anyone making assistive technologies? Anyone making file conversion software to take office documents into Braille or DAISY? It is difficult to trust a document that has no attribution. Given the high stakes involved, it is difficult to accept something without peer review from experts that don't stand to profit from the results of the review.

2. When and how will the accessibility failings cited in the paper be fixed? While the white paper introduction notes that the "adoption of Accessibility in the Open XML standard will help many technology providers carry forward the information stored in billions of existing documents AND preserve the information in that document intended to enable accessibility", it is silent on the question of whether how MSOXML accessibility support itself will improve. For example, the white paper notes that MSOXML fails to support WCAG 1.0 checkpoints 4.2, 5.2, 9.4, 10.2, 12.1, 12.2, and 12.4. The white paper further notes that MSOXML only partially supports checkpoints WCAG 1.0 checkpoints 6.4, 8.1, 9.1, and 11.1. Some of these are particularly important for blind users needing to understand the context of table cells and for good Braille and DAISY transcription of tables - issues we found in ODF v1.0 and fixed in ODF v1.1. Will these things get fixed in the future? If so, when? By whom? With what outside review (if any)? To appear in what update of the specification?

3. Why use WCAG 1.0? It is widely recognized that WCAG 1.0 is very old. The Web Content Accessibility Guidelines v2.0 is in ""last call". The white paper uses a draft of the XML accessibility specification, but then oddly doesn't do the same with WCAG 2.0, relying instead on a document that is over 8 years old.

4. The white paper notes in many places that many of the WCAG 1.0 checkpoints are inappropriate for an office document (this is separate from the checkpoints noted above that the document says are either not supported or not fully supported). This suggests that the document author(s) don't feel that WCAG 1.0 is a fully appropriate standard to use. Yet there is no discussion about this - about why those standards were chosen and not others. Also no discussion about the accessibility purposes to which one might put an office document (e.g. meeting the needs of Braille or DAISY transcription).

5. The white paper sometimes uses the phrase "this checkpoint is fully supported in Open XML file format", and other times the phrase "this checkpoint is supported in Open XML file format" (as distinct from the phrasing "this checkpoint is partially supported in Open XML file format". Is there a difference between "supported" and "fully supported"? For those checkpoints that are merely "supported", what is missing (if anything)? Further, in many cases for checkpoints that are "partially supported", often the white paper doesn't state what is missing. Without undertaking a thorough reading of the 6,000+ specification, it is difficult to know exactly what is missing. Without knowing who did this review and wrote this white paper, there is nobody we can ask this question of...

6. In the review of MSOXML against the XML Accessibility guidelines, there is no definitive statement on whether and how MSOXML supports the first 8 checkpoints (1.1 through 3.2); only summaries of what those checkpoints say. For many other XML Accessibility guidelines checkpoints, there is some description of what MSOXML does, but no definitive statement about whether that means that the checkpoint is "fully supported", "supported", or "partially supported" by MSOXML (or yet some other thing). Does this mean that MSOXML fails to support those checkpoints? Does it mean that the checkpoints are inappropriate for an office document? Something else? It just isn't clear.

In addition to these important questions, this white paper nicely sidesteps what I believe is the intent of WGAG 1.0's Guideline 11: "Using W3C technologies and guidelines", and most specifically checkpoint 11.1 "Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported." Unlike ODF, MSOXML makes almost no use of existing W3C standards. Instead of using the W3C XForms specification for embedded forms, it invents its own XML terminology for forms. Instead of using the SVG specification for vector graphics, it uses its own vector graphics encoding. Instead of using the MathML specification for mathematical equations, it uses its own math encoding. Instead of using the W3C date format, it invents its own (and perpetuates a leap year bug from the first releases of Microsoft Excel, rather than having the software that converts from .xls into MSOXML calculate the correct value). Yet oddly, on this topic, the white paper claims that checkpoint 11.1 is "partially supported", with the checky claim that "the Open XML file format has defined namespaces and elements and use [sic] them." This lack of re-use of existing (and accessibility-vetted) W3C XML standards is perhaps the main reason for the MSOXML specification running to 6,000+ pages, and is repeatedly cited by ISO voting members in their objections to the Fast Track ballot of MSOXML.

P.S. a final note: I was disappointed to see that the PDF edition of this white paper failed to make full use of the accessibility features of PDF and be a properly tagged document. The first 8 words of the document appear doubled to screen readers: "AAcccceessssiibbiilliittyy ooff EEccmmaa OOffffiiccee OOppeenn XXMMLL FFiillee FFoorrmmaattss" (2007-07-03 17:07:48.0) Permalink Comments [1]

Sun's OpenDocument Format plugin for MS Office now shipping

As my colleague Malte Timmermann has pointed out earlier today, the Sun ODF Plug-in 1.0 for Microsoft Office is now available for download, free of charge.

The plug-in is an extension to Microsoft Office that allows it to read and write ISO standard ODF files. It supports Office 2000, XP, and 2003, and works on Windows XP and Vista. It adds to MS Office the ability to read and write ODF text, spreadsheet, and presentation files (.odt, .ods, and .odp) - the ISO standard editions of MS Word, Excel, and PowerPoint files. Furthermore, ODF text files (.odt) can be made the default format for MS-Word thanks to this plug-in (and double-clicking on an ODF text file on the desktop would automatically open it in MS-Word).

Addressing the accessibility concerns of existing MS-Office users was one of the key reasons behind Sun's development of the ODF plug-in, and I have been one of several folks involved in testing the accessibility of this plug-in (along with several beta testers whose employees with disabilities were likewise doing accessibility testing). I'm delighted to report that all aspects of the plug-in - from installation through to operation from within MS-Office - works very well with commercial Windows AT products. The ODF plug-in works very well with screen reader and screen magnifiers and voice recognition/dictation systems and text-creation assistance applications. It likewise works well with the basic accessibility features built into Windows - with themes for folks with visual impairments and with the limited MS-Windows built-in AT like Narrator* and Magnifier. This means that existing users of MS-Office can move to ODF without sacrificing any of the accessibility they have achieved, because they need never leave MS-Office.

* Note: Narrator doesn't read MS-Office content, because Microsoft doesn't support its own screen reader with its own office applications, unlike UNIX distributions like Solaris and Ubuntu, which ship with a screen reader that is able to read (and Braille) office application documents. Unfortunately the ODF plug-in is unable to change this, so Narrator won't read ODF files anymore than it can read Word, Excel, or PowerPoint files. (2007-07-03 13:33:53.0) Permalink Comments [5]