Section 508
Building Accessible Web-sites and applications in a real-world business environment
Sat, 2007-07-21 10:19 — iDonnyAre you of the thinking that if something looks good is a respectable web browser such as Firefox, Safari, Opera, or Internet Explorer, then it is satisfactory (especially if the code also validates using the W3C validator)?
Have you ever tried to browse the web using a screen-reader such as JAWS or Opera Browser/Audible?
Building an inaccessible web
Content and application accessibility is not being regarded with as much importance as it deserves. Currently, too much focus is put on the lowest common denominator, and investing time and resources in features and implementation strategies that will get the biggest bang for the money and time is a commonly tolerated compromise. This Web Design and Development strategy is a direct result of letting business interests drive the way of the Internet. It is undeniable that the business community and capitalist market forces are responsible for the growth of the Internet from a scientific experiment, to the previously unimaginable medium that it is today. However, catering only to what will generate high dividends for share-holders can be lack of visions.
An example of this short-sighted drive to cater for the majority at the expense of the non-traditional and minority site visitor became clear to me in two situations where the CEO of a mid-size company asked this question when he was told that web applications built for the federal government had to be Section 508 compliant so that blind members of the public could use them: "Blind people do not read, and should they use the Internet?" In another situation, a senior project manager at another company remarked that to reduce server overhead, a new application would be built so that the last bits of XSLT logic to transform raw XML data to the UI (user interface) markup would be done in the web browser. When told about accessibility, and the use of non-traditional web browsers such as PDAs, text-only, and other browsers that are not able to parse XML/XSLT, he angrily responded that "We are building a rich application that will work with the latest browsers (IE6+, FF, Safari), opening the Web Application to non-traditional browsers is not part of this project and will have to be scoped separately as an enhancement"!!
The above-two are examples of some level of ignorance, disregard for Web Accessibility, and quick frustration with the otherwise meticulous process of making web sites and applications accessible. I cannot deny that it is slow, and anything but easy to attempt to code a site, and as opposed to previewing it in Mozilla Firefox or Internet explorer, to open up JAWS, or turn off the monitor and preview/browse the website/application without any visual information. This is also the biggest reason to make web-sites and applications accessible to blind, low-vision and otherwise disabled users.
No one can deny the the W3C placed and has continued to place importance and dedicate time and resources to developing the necessary techniques and infrastructure for designing and developing accessible websites and applications without compromising the eye-candy that we often rush for at the expense of accessibility. We therefor have very weak, or no reasons at all for not building accessible web applications and sites.
Currently, there may be relatively little motivation for business management to spend the extra time and resources required to make applications accessible. I once worked on a project that was launched despite my protests and warnings that the UI markup was not valid HTML or XHTML. The 'important' thing at that time is that the application was relatively stable and quite usable in Internet Explorer version 6, IE7, and Firefox. My protests seemed to many to be the passion or a lone and narrow-minded purist with little regard for the financial consequences of delaying the project so that the issues could be fixed and bring the web application to scope in terms of accessibility and code validity. The disregard for valid code soon begun to make the applications behaviour unpredictable, unstable, and difficult to quickly update because what initially seemed stable and usable became unstable when small changes were made


