Most of us love e-government. We're discovering that in many cases, no one can serve us better than ourselves. Customer service expectations have less and less to do with human-to-human interaction and more to do with human-to-technology interaction. Automated back-office processes and tools enabling citizens to interact online with government have yielded revolutionary conveniences.
However, it's easy to forget that government's IT advances can create special challenges for people with disabilities. Sometimes programmers unintentionally design Web portals in ways that are difficult to decipher for software designed to read text aloud to visually impaired citizens. Also, how are the blind supposed to knows what graphics convey? Many state and local governments have ambitious video streaming initiatives connected to their portals. What good are those videos to the deaf? Some portal designers are strategizing ways to include readable text.
But IT obstacles for disabled citizens involve more than portals. In 2007, the Indiana Family and Social Services Administration (FSSA) used IT to end its practice of assigning individual caseworkers to food stamp recipients. Any caseworker answering the phone now uses a centralized IT system to help all clients. The American Civil Liberties Union (ACLU) of Indiana insists citizens with disabilities often require interaction with caseworkers who are accustomed to dealing with their particular disabilities. Can IT be adjusted to address those exceptions?
Consulting firms specializing in the Americans with Disabilities Act (ADA) help governments and businesses comply with that federal law. When governments modernize their technology infrastructures without taking the ADA into consideration, projects aimed at easing citizen burdens occasionally make those burdens heavier.
Austin, Texas IT, workers frequently discover obstacles to accessing the city portal for disabled people. The Austin Department of Communications and Technology is redesigning its portal using an open source content management system called Plone. The agency can program Plone to prevent those obstacles to accessibility from entering the portal in the first place.
Problems are usually caused by code that wasn't written with screen reader software in mind, said Chris Florance, public information officer of Austin. The software reads Web text aloud for visually impaired people. Difficulties often involve the site's HTML code. For example, in the past, the city's Web team didn't always end each text paragraph's HTML code with a "closed tag," which tells the software that a paragraph has ended. Without the closed tag, the reader software spews out the text without the necessary breaks in speech, making it difficult for listeners to understand. Programmers should also pay extra attention to HTML when creating tables of text, said Florance.
"Let's say you have a table of cities and populations," he said. "If you're using good ADA-compliant HTML code, the reader software will read it as 'Kansas City, Mo. -- population 1 million; Jefferson, Mo. -- population 200,000; Austin, Texas -- population a million and a half.' But if the HTML was set up a different way, it might look OK on the page to a viewer, but the reader software might read it as 'Austin, Texas, Kansas City, Mo., Jefferson, Mo.,' and then it would start reading the populations. It could mess up the sequence."
Dynamic portals -- which combine several forms of programming content for creating text, graphics, video and interactive functions -- pose another accessibility challenge. When the portal combines these functions, the underlying code may be interconnected in ways that confuse the reader software. Simply put, the reader software can't parse the text code, which it's supposed to read, from other code that it should ignore. Remedies exist for this, said Matthew Esquibel, Austin's Web supervisor. For example, his team will program the text using XML, enabling the reader software to distinguish the text code from the rest.
Often city portals use photos and graphics to communicate messages