vanderwal.net

Accessibility benefits

The W3C provides an overview of the benefits of accessible web design. Building sites so they are accessible is not a task that much be done it is an asset.

One thing that I have had the benefit of viewing and discussing while at SXSWi is Flash. Folks from Macromedia have shown their soon to be released version of Flash. Flash MX (as it is named) has some very good new features, in its providing common Web development objects to help developers create scroll bars and the like very easily. The application seems to provide object or extensions to Flash that streamline the process to building something usable and consistent in Flash.

The best new feature of Flash is content can now be made accessible for those with sight disabilities. This is greatly helpful as Flash is largely a visual information development and presentation tool. The information is now usable by site readers that read information aloud stored in Flash. This has been a large hinderance for many folks who would like to adopt Flash into their development tool belt, but had restrictions that limited the use of Flash because it locked out a segment of the users who had visual disabilities.

There is one large element in Flash that is completely disappointing still. The information is not accessible for reuse. All Flash can provide is visual information presentation, which restricts a user's ability to copy and paste or to have the information machine readable. The information is locked in an unusable format for these purposes. What does this affect? If a hotel provides their phone number and address in their Flash presentation the user can not copy and paste the information out into their PIM (Outlook, Access, Palm desktop, etc.), to an e-mail, or text message that the user could read from their PDA or cell phone (given messaging capabilities). The user would also be restricted from grabbing the information to put together a matrix from which to make decisions or to supply to others to make their comparisons. The locking of information in Flash requires the user to retype the information provided, which introduces the ability for errors in the information that was carefully crafted.

Not only do human users have the inability to re-purpose the information, which is a great benefit to those providing the information, but machines are precluded from accessing the information. If the same hotel wants to be included in their city's chamber of commerce listing on the CCoC Web site the hotel information can not be easily extracted by the CCoC as it could be from HTML (using an id tag) or XML. The information is locked again in an unusable and un-reusable format. The creators of the content lose, and could possibly lose big by not having information that is easily reused. This becomes increasingly important with the growing use of Web Services that rely on machine readable or machine accessible information.

Why the hotel scenario? Macromedia used the hotel demonstration to highlight some of their great new features. As I watched the presentation I kept wondering if the information was still unusable for purposes other than reading or having the information read to the user. It was later confirmed the information was still un-reusable, but Macromedia is also aware of this strong down side to the information presentation and is working hard at fixing the issues.

I keep rereading Nathan's Rant from July 2001 concerning experience design, its state of being and his first book on the subject. Visual presentation and creating an experience for the user is quite helpful when presenting dry or complex information. Today visual presentation must be accompanied by versions of the same information for the visually impaired, well at least many of us live in that world. This adds new twists and challenges to create compelling information sources for an array of user types. For me, Nathan's works have always been an inspiration and a trigger for solid thinking and problem solving.

Shirley Kaiser discusses accessibility and Adobe Acrobat on her site.

There is one element in Adobe Acrobat that does not meet the Government's 508 compliance, if this is the yard stick being used for accessibility. The area of non-compliance is complex tables. PDF tags only have TABLE, TR, TH, and TD tags available, which do not accept scope. Scope is what helps the complex tables become compliant in HTML. The only acceptable method for providing information in complex tables is HTML, at this point. One work around is to make the complex tables attachments or addendum and remove them from the original document (should the complex tables be provided in PDF format) and only supply them in HTML.

To keep it clear a complex table is one that has more than one set of header rows and often one of the header rows would span a selection of other rows. An example would be a table showing fiscal quarters of the year and the months that fall within these quarters, which would then show rows of related numbers. The top two rows create a complex header as each quarter header spans three rows and defines the months directly below them. Voice readers will capture these relationships quite well with the use of "scope tags" in HTML (this would look like <th scope="col"> for header tags and <td scope="row" in the first cell of the table's rows). Unfortunately, PDF does not have a corresponding tag.

I also pointed out that the more current Web browsers permit using CSS with printer designations that allow for a better representation of the information. This would help those people build one application, whether it be a Website or a PDF that prints in the desired manner and is accessible.

This may help keep yourself and your readers in the clear if 508 is their standard upon, which their accessibility work is being performed. Unfortunately there are no compliance standards, only guidelines. But, for most federal government organizations it is meet all of the targets to be compliant. 508 is a pass/fail hurdle.

Further information on 508 may be found at www.usability.gov/accessibility/index.html.

Content management is back at the forefront of every aspect of my digital life again. Content management revolves around keeping information current, accurate, and reusable (there are many more elements, but these cut to the core of many issues). Maintaining Websites and providing information resources on the broader Internet have revolved around static Web pages or information stored in MS Word, PDF files, etc. Content management has been a painful task of keeping this information current and accurate across all these various input and output platforms. This brings us to content management systems (CMS).

As I pointed to earlier, there are good resources for getting and understanding CMS and how our roles change when we implement a CMS. Important to understanding is the separation of content (data and information), from the presentation (layout and style), and from the application (PDF, Web page, MS Word document, etc.). This requires an input mechanism, usually a form that captures the information and places it in is data/information store, which may be a database, XML document, or a combination of these. This also provides for a workflow process that involved proofing and editing the information along with versioning the information.

Key to the CMS is separation of content, which means there needs to be a way to be a method of keeping links aside from the input flow. Mark Baker provides a great article, What Does Your Content Management System Call This Guy about how to handle links. Links are an element that separates the CMS-lite tools (Blogger, Movable Type, etc.) from more robust CMS (other elements of difference are more expansive workflow, metadata capturing, and content type handling (images, PDF, etc. and their related metadata needs)). Links in many older systems, often used for newspaper and magazine publications (New York Times and San Francisco Chronicle) placed their links outside of the body of the article. The external linking provided an easy method of providing link management that helps ensure there are no broken links (if an external site changes the location (URL) it there really should only be one place that we have to modify that link, searching every page looking for links to replace). The method in the Baker article outlines how many current systems provide this same service, which is similar to Wiki Wiki's approach. The Baker outlined method also will benefit greatly from all of the Information Architecture work you have done to capture classifications of information and metadata types (IA is a needed and required part of nearly every development process).

What this gets us is content that we can easily output to a Web site in HTML/XHTML in a template that meets all accessibility requirements, ensures quality assurance has been performed, and provides a consistent presentation of information. The same information can be output in a more simple presentation template for handheld devices (AvantGo for example) or WML for WAP. The same information can be provided in an XML document, such as RSS, which provides others access to information more easily. The same information can be output to a template that is stored in PDF that is then sent to a printer to output in a newsletter or the PDF distributed for the users to print out on their own. The technologies for information presentation are ever changing and CMS allows us to easily keep up with these changes and output the information in the "latest and greatest", while still being able to provide information to those using older technologies.

An USA Today article on poor product design provides insight that is helpful not only to product development, but also application development. The insights (while not new to most of us, but most likely very new to USA Today readers) include not including the consumer early enough in the process, product design team not well balanced, and technology runs amok.

These very closely apply to Web/Internet/Application development's downfalls. Not including the user in the development phases and/or testing with users early and throughout the development process. Having a development team that does not have a balance of visual, technical, and production skills can be problematic. Lastly, projects that are technology for technology's sake, very rarely offer success.

Conversely, success comes from getting these things right, involving the user and understanding how users would interact and use what you are building. Having a balanced team so that visual, technical, and production issues can be addressed and solved appropriately. And lastly knowing when and how to best use what technologies will drive success.

This last element, understanding the technologies, will help you get over the hurdle of accessibility/508 compliance. It will also help you find the best tools to interact with the users of the site/application. Having DHTML elements to provide action on a site or to serve information, when the user audience does not fully have the capability of addressing or handling the presentation, will have detrimental effects. Know what your elements your users have turned on and off in their browsers and what versions they are using. It is important to know what threshold of user profile can be the cut-off for developing a site. If 10% of your users have JavaScript turned off should you still develop elements of your site that are JavaScript dependant without providing an alternate service? Know and set this percentage threshold, as it will help understand why you can and can not use certain technologies.

A Nick posts the outline and links for he and Ross Olson's Web Standards discussion, which was delivered in Portland, Oregon at the Portland Multimedia | Internet Developer's Group.

We are all trying to make our sites more accessible. Some of us do it because we have to and others of us do it because it is the right thing to do. No matter what our mission to many of us it is a new twist to our regular routines and we could use some help. Those of us that use Macromedia products now have help in Macromedia's Solutions Kit of Accessability.

Molly Holzschlag writes the 14 Ways to Talk Clients Out of Ruining their Sites, which is a wonderful article that will help back-up the guidence we have been giving clients. Going over the top is never the best practice. Some of the suggestions are: skipping the test phase, client-centered design, ignoring accessibility, poor site structure, everything above the fold, too many effects, and splash pages. These are the no nos, or do with great restraint. Please enjoy the article and share it with decision makers and those that think they get it.

IBM's Ease of Use Center offers articles, links, and resources that cover a wide gamut of offerings to help development for the user's benefit. The resource is full of wonderful offerings.

The feature story in October was The Purpose of the Machine is to Augment Us, which focusses on Franco Vitaliano of VXM Technologies in Boston, MA. "Maybe the intelligence of a system is not in the computer sitting inside a war room or on a desktop," he says, "but in what we call the communications cloud."