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:
In addition to the specs, these rules are also required:
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.
Now it’s time to decide on a coding approach for your report. Maybe you can advocate for a total Website re-write, if so, go for it. Remember that it has to make dollars and sense. If creating a team to re-build the site costs more than it saves, be aware of that, and share that with the executive team, let them know you’ve done your homework. So, maybe you will advise one of several alternate scenarios:
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
Popup windows
And not so gray rules…
Alt text is used for images. Title text is used for links.
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.
