If you come to Washington D.C. right now, chances are you will see big poster ads by Adobe. This is because Adobe recently launched their Open Government initiative. As stated on their web site:

As Washington takes steps to become more transparent, government departments and agencies are more openly collaborating with each other as well as the public. See examples of how Adobe technology and software are empowering the Open Government movement.

As a web designer and front-end developer working in government IT, I love the Adobe products that I use daily. However, I was surprised that Adobe built their Open Gov site entirely in Flash. Flash sites are not accessible or section 508 compliant. The best use of Flash for government web use now is to stream videos. Chris Foresman summed up the problem with Flash in his article on Ars Technica:

After just a cursory browsing, here are some of the usability and data accessibility issues we observed. You can’t select, copy, or paste any text. Your browser’s font override features won’t work, so you can’t adjust the font or its size to be more readable. Your browser’s built-in in-page search won’t work, and you can’t use the keyboard to scroll through the text. You can’t parse or scrape the data in any way; the design is fixed-width, so it’s not going to work well on different screen sizes; and browser plugins, like Greasemonkey, can’t adjust anything. Basically when it comes to text at all, if you don’t like the style or are visually impaired, you’re screwed.

Personally, I’m not anti-Flash. I believe in using the right tool for the job and Flash has its place. Rich media sites such as TV, movies, and gaming sites use it to offer their tech savvy audiences the best interactive experience. However for government sites, we need to make sure our sites are as accessible as possible to everyone out there. With the advancement in front-end development, many interactive elements can be done in pure HTML, CSS and unobtrusive JavaScript today.

The second issue is Adobe’s push for PDF format. Just about all government agencies use Adobe Acrobat to publish documents in PDF format. I have no problem with PDF for short documents. They’re printer friendly and accessible if done correctly. However, long reports can be a nightmare for both developers and the public who attempt to read them.

Clay Johnson from Sunlight Labs recently wrote a blog post titled “Adobe is Bad for Open Government.”

Take, for instance, H.R. 3200– otherwise known as “America’s Affordable Health Choices Act of 2009″, a 1017 page healthcare bill from congress. Because it is primarily published in PDF, we’ve got to build a special parser for it– that bill– in order to represent it programatically. Or Carl Malamud’s IRS filings for 527 (stealth PAC) organizations: gigabytes of PDF files, all released by government. Government releasing data in PDF tends to be catastrophic for Open Government advocates, journalists and our readers because of the amount of overhead it takes to get data out of it. When a government agency publishes its data and documents as PDFs, it makes us Open Government advocates and developers cringe, tear our hair out, and swear a little (just a little).

Clay suggests instead of PDF we should use other formats such as HTML or XML. I prefer XML since many PDFs already are built off XML format. As for HTML, I can see several issues:

• Writing valid HTML code. Unless the people who create the files are up to date with W3C standards, we’ll end up with tons of poorly written HTML files. Many government sites are plagued with poor HTML already.
• XML offers a structured format that can be transformed using XSL into other, more specific formats such as HTML or PDF.

I recommend reading Clay’s article in its entirety, including its comment section. Recently, Clay and Rob Pinkerton, the Director of Adobe Government Solutions, appeared on the Kojo Nnamdi Show. They offered their views in-depth on Adobe’s involvement in the Open Government movement. The audio and transcript are available on Kojo’s site.

I am happy that Adobe wants to get involved with pushing government IT forward. However, they should study the constraints government agencies face. Document format and accessibility are two important issues given the amount of data to be presented to the public.

“Accessibility” is a big word. Everyone who develops Web sites – coders and content creators alike – should aim for full compliance, but the reality is that only the criteria in Section 508 are legally binding to government. For Web-based intranet and internet information and applications (§ 1194.22 ), this means sixteen criteria and the Adobe Open Government site does not meet them. Paragraph (l) states “When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.” Unfortunately, there is text content in the HTML source of the page, but CSS is used to hide that content in such a way that it is not announced by screen readers (using “display: none“).

Adobe missed a valuable opportunity to demonstrate how Flash can be used in an unobtrusive and/or accessible way; if Adobe can’t make a Flash-based, 508-compliant site, why should we expect government developers – or any developers – to do so?

Update (12/3/2009): The Adobe Open Government site has been updated! The site still uses Flash to provide some background animations, but the content is marked up using HTML, CSS and JavaScript.