Implementing Web Standards in the Enterprise

Go to most enterprise class websites and look at the code. What you will most likely find is a twisted mass of inaccessible poorly written HTML and large amounts of JavaScript that will never validate. This bloated and malformed code wastes bandwidth, lengthens load time, limits the customer base able to use the site and is a maintenance nightmare. Maybe you don't need to go to someone else's enterprise class site - maybe you can just look at your own. This article is for those of you working in the enterprise that understand web standards, need additional tools to get the standards message across to management decision makers, and are looking for a path forward after getting the go ahead. How did we get here? Compact, well-formed code that executes quickly with minimum expense is the trademark of an expert developer. Why then is completely malformed HTML so tolerated in the enterprise? I think there are several reasons: 1. The client side has long been seen as a step to the server side rather than as a career path in itself. 2. Business rules are rightly built and maintained on the server side, so the Web page is seen as merely a way to display the business rules built by server side developers. 3. Pages have been built with tables for so long that the expertise needed for client side development with expert skills in CSS layout, JavaScript and the DOM has been perceived as unnecessary. 4. Since server side developers have been seen as the most important group and the client side has been ignored, most developers have tried to get away from the client side as fast as possible, leading to a brain drain client side. But now, the client side and Web standards are gaining popularity. Why? I think there are 3 main reasons. 1. Web standards evangelists have kept the fire burning until it started to catch on with others; we are reaching a critical mass of working web standardistas. 2. While there is room for continued code performance improvement on the enterprise server side, the gains are relatively incremental. 3. Conversely, the client side is now the place where large gains in performance and functionality can be made. Ajax and Flex, for instance, hold out exciting possibilities for new ways of interacting with end users. What standards? For the purposes of this article, when using the term "Web standards" I mean that pages will validate (or come very close to validating) to the following published specifications:

• W3C XHTML 1.0 Strict

• W3C CSS1 used for all positioning and formatting of presentation elements.

• W3C Priority 1 Accessibility Guidelines

• Tables are used for tabular data only.

• JavaScript must be accessible or equivalent functionality must exist.
Making the case to decision makers Aren't you tired of telling executives they should implement Web standards because it's the right thing to do? Executives are focused on maximizing value for shareholders, raising profits and lowering costs. The only sure-fire way to get the attention of a decision maker in the corporate world is to talk dollars. So, why use Web standards? For the same reason standards are used in every other industry; standardization is crucial to lowering costs, raising ROI and maximizing a company's value to shareholders. If you are a Web standardista you already know the benefits. Standardization creates pages that are lighter weight, reduces time-to-production, are less maintenance intensive, significantly lower bandwidth needs, open the Website to new customer bases and thus raise ROI. Business executives need to hear this. Implementing Web standards will give your company a competitive advantage by lowering costs and broadening your available customer base. Your company will also greatly reduce its exposure to accessibility lawsuits related to the Website. You better hope your competition doesn't read this and take action first. How specifically can you make the case in your organization? Here is one path.
• Analyze your site, find the most highly trafficked 5-10 pages, then do a small proof-of-concept by rebuilding those pages to Web standards.
• How much lighter are they? That's bandwidth dollars saved.
• How much faster do they load? That's customer satisfaction.
• How well do they work in all major browsers? That's broadened customer base.
Next, gather outside stats:
• ESPN.com claims their pages decreased about 50KB each by going to standards. They estimate that based on the amount of traffic they receive daily (40,000,000 daily page views in 2003), they now save about 730 terabytes a year. Source:
• A maintenance approach. Whenever pages are worked on for maintenance purposes, they are converted to Web standards as part of the work.
• An incremental approach. Re-build portions of the site over time until it's all finished. You also have to have a plan for new projects if you go this direction.
• A "new projects only" approach. You leave the current site as it is and use standards going forward.
• An "eclectic approach". You use a mix of the above approaches, possibly with others not discussed here.
Then take all this data and put it together in a report using the business language executives understand -- charts, graphs, PowerPoint slides, whatever it takes to visually make the point about ROI. You're creative, you can do it. You may have to evangelize for months before anything happens, or it might be that your company never does get it, in which case you may need to decide how important Web standards and providing access to information is to you and possibly make some career decisions. Implementation and Training Web standards are part science, part art, part best guess. XHTML is binary, it either validates or it doesn't. Accessibility standards though, are agreed upon coding best practices mixed with XHTML tags and attribute extensions which are much more fluid when it comes to validating and working in the real world. Some accessibility checks must be done manually because even the best validators cannot make every decision about code validity. A new skill set that is somewhat ambiguous means that many hard-core programmers and QA people may have trouble with the non-binary nature of accessibility Thus, after evangelizing successfully, the real work starts. In large organizations, one task, like re-writing the Web site or a portion thereof, requires the involvement of many departments. Success will require training all departments responsible for input, output and evaluation, including marketing, analysts, graphic/interface designers, project managers, developers and QA. Each group is different, needs different training, and will most likely get frustrated with you along the way more than once. So let's assume your process is something like this: Marketing requests a new feature or new area for the Website. Graphic designers/UI people design the pages. Business analysts write up a technical description and pass it along to the project manager's office. A PM is assigned and works with an architect or a tech lead and the analyst and a dev manager to hammer out requirements and resources. The analyst writes an approach doc describing the project in detail. Development gets the doc, quotes level of effort, gets resources and builds the project. QA then tests the project against the requirements in the approach doc. User acceptance testing closes the loop when marketing tests the project, and then it goes live. So, there are whole bunches of people that need to learn new skill sets to pull off the project. 1. Marketing, graphics designers and analysts will need to know how their requirements and designs can positively/negatively affect accessibility. 2. Developers will need to learn a new software development lifecycle that includes validation of all code. 3. QA will need to learn how to test and verify that pages meet standards. You're going to need a training plan with versions for different groups that speak the language of each group. If you fail to tailor your training to each group, you can create more problems than you could possibly imagine, and that could derail your whole web standards program. Marketing, Graphics Designers, Analysts In many organizations you can group these people together for training because what they need to learn is essentially the same information. You will need to make some decisions about the "gray areas" of accessibility, like popups, tabbing, form field focus, and a range of other issues. While popups are not necessarily evil, and opening a new window is very convenient for the business to communicate additional info, some windows may not be friendly to a person with a screen reader. A popup that has links in it to another popup, which then links to a different part of the website completely blows a user's browser history and can be a chaotic experience for a blind person using a reader. Following are a few "gray" rules used on the site I work on. Forms
• The cursor will not be forced to move to the first form field via field focus onload.
• "Auto-tab" between fields is no longer used.
• Fields are not artificially separated, e.g., phone number fields.
• If you choose to tab through the page from the top, you will often notice on a forms page that the cursor will go directly to the first form field.
Popup windows
• The user is now allowed to change the size of the popup window if they choose to do so; every window can be maximized, minimized, and resized, and as needed, a scrollbar will dynamically appear if the window is made smaller than the content within it.
• For pages containing Flash content, we can safely remove the scrollbar; if the window is re-sized by the user it will not display a scrollbar.
And not so gray rules... Alt text is used for images. Title text is used for links.
• Alt text is not used in "non-semantic" images, i.e., images that do not communicate something important about the page, like a smiling person.
• Title text is used to provide additional information about a link that is not descriptive to a person who cannot see the context of the page, e.g., links like "Details".
Developers I have the pleasure of working with a highly talented, dedicated and motivated group of developers, so training them was a pleasure. I hope your experience will be as good as mine was. I took a two-pronged training approach. First, I articulated the coding goals. 1. Well formed XHTML 2. Use tables only for tabular data, not for page layout 3. Use CSS for page layout and to control all aspects of the content's look and feel 4. Will be accessible to people with a wide variety if disabilities 5. Will validate to published XHTML and accessibility standards confirmed by using validator tools in conjunction with manual verification using screen readers and code-level inspection. I followed up with classes in XHTML, basic CSS, accessibility and how to use the validators we chose. These classes were required for all developers and highly recommended for PMs, QA, and other related teams. The second prong was to build a library of components so that developers could take a generic component, tweak as necessary and move on to another page or project. We built page templates, fully formatted example tables and many additional widgets, all using CSS for formatting and following accessibility guidelines. Since we effectively created a new software development lifecycle, that also had to be articulated to developers. 1. Pull components from the library to assemble your pages 2. Use global styles as much as possible for formatting 3. Validate your pages for XHTML and accessibility compliance 4. Submit for code review Quality Assurance QA testers can be a particularly challenging group to train because of the pass/fail nature of their world. A simple example that can cause issues unless addressed in training is the "alt" attribute. Our testers were used to seeing the alt attribute on every image, and they used Internet Explorer to verify by hovering over the image. There are two problems here that come together to create a training need. One, IE's behavior is incorrect; the alt attribute should not be displayed visually. Two, while all images should have an alt attribute, if the image is "non-semantic" the attribute should be empty (alt=""). So, when you tell QA they will not see alt attributes on every image but that every image has an alt attribute, whether empty or descriptive, they now must look in the code to verify the empty attribute exists. Believe me, this can be a big change for many QA people. Add in other kinds of attributes that must now be tracked and the new processes may quickly seem daunting and/or just plain frustrating to them. What's the answer? Your situation is likely unique, but this is what I was able to broker: 1. An agreement that the business (marketing) would provide alt attributes where needed 2. These would be written into the project documents by the analyst 3. Development would code the attributes, then run accessibility validation to report on all empty attributes 4. QA would verify the existence of attributes that had text and use the validation report to verify the correct images had been left with empty attributes For the many other attribute issues, like summary, tabindex, label and title, the validation report run by development is passed to QA to verify all accessibility measures are in place. Your mileage may vary, but this hybrid model works for us. Keeping the good ground Making the case to executives and training teams on Web standards is difficult, but the ongoing process to maintain your pages may be your greatest challenge. The new software development lifecycle policies must be rigorously enforced. All code must be validated before going to QA. You will also need to create multiple feedback loops that consists of all the groups we've mentioned already so that if some feature or widget that violates standards sneaks by one group, another will catch it and alert the appropriate people. Catching issues early is especially crucial if they require approval to make compliant. In addition to the feedback loop, there are two areas that both require equal attention; maintenance and new projects. Maintenance Change requests for defects or minor enhancements may come from a variety of sources but at some point, most organizations have a person or small team who assign that work out to developers. Make friends with these folks and train them well, so if they see something that violates standards or is a gray area they will flag that and let you know. Invest extra time and energy in the maintenance team developers as well and you will be repaid with a site that is increasingly compliant. New projects You will want to make friends with the analysts, or whoever in your organization writes the requirements for new projects. Train them well. Many features - elaborate popups come to mind - must be caught in the requirements stages or they become part of the application and are very difficult to remove later. You need eyes and ears everywhere and the people who write your docs are crucial to helping you maintain standards. Last thoughts As you master how to build web standards compliant enterprise sites, you will have benefited your company's shareholders and a host of people who might otherwise be unable to access valuable goods and services online. Now, let's go do it again :) Andrew Kenney has architected mainframe and Web client interfaces for BankAmerica, Fleet, Security Pacific, Verizon Wireless, Vanguard University and other leading corporate and non-profit customers since 1989. An ardent proponent of Web standards for many years, Andy serves on the advisory board of the World Organization of Webmasters. He has taught a variety of technology and leadership classes at the university level and in the corporate environment, and holds an M.A. in Organizational Leadership. He is Lead User Interface Architect for B2C and B2B applications for Verizon Wirelesss Internet Services division.