Quality Control


Quality in web page development is a multi-faceted concept. Not only do you have to look at formal measurements, but there are many subjective aspects which need to be taken into account. However, just because an observation is subjective, doesn't mean that the effect on quality should be discounted.

For example, colour choice is a highly subjective area. In a formal review of the XHTML Tutorial out of 60 reviewers a substantial number did not consider dark blue text on a pale yellow background to be a suitable choice, citing reasons such as accessibility issues, professional appearance etc. However, we can isolate specifics from this and hone in on valid quality issues. In this case professional appearance is almost totally subjective, and for the most part is determined by the client or the organisation that you work for, but accessibility is a measurable entity and colour combinations are well understood, but even so the distinction is not black & white (pun intended!). Accessibility is measured on a continuous scale. Some colour combinations may score zero (e.g. Red & Green) and others may score top marks (e.g. Black & White) but dark blue on pale yellow is a high scoring combination, with the added bonus of satisfying my aesthetic preferences.

Quality Criteria

We are going to investigate the quality criteria in more detail. Some will be seen to be down to the designer (and may well not be under the control of the developer). Others, however, will be intimately connected to the development process, and we will see how EWD can assist us in creating a high quality product. We are going to look at the following types of quality measurement.

Standards base development

We ought to be in agreement that all web pages should conform to the appropriate standards for HTML version, CSS and Accessibility. Does this mean though that if a web page conforms to the standards through some sort of validation test that it is a quality product? I would argue No!

Example 1

John Doe creates a new website using HTML 4.01 Strict with inline CSS styling and use of some of HTML's page design features. The pages are validated and meet the W3 requirement as well as the appropriate accessibility criteria.

Is this a high quality product? No! Quality cannot always be measured up front. Only through time do you become aware of limitations and flaws. For example, an MP3 player with a rechargeable battery which cannot be changed and only lasts 12 months may look good up front, but fails the quality test eventually. In the case of John Doe's website trouble starts down the line when his client wants changes and the code is so convoluted, with a mix of HTML, inline styles and HTML design elements that it becomes virtually impossible to change. There is also the issue of whether the original choice of technology was appropriate. Using HTML was a mistake especially since XHTML has been around since the year 2000, is well understood, is well supported and has definite measurable benefits. We should not be using old technology and techniques for building new products, unless those techniques and technologies are still superior.

 Example 2

Jane Doe uses the latest tools and techniques to build a website. All the pages pass automated validation tests for XHTML, CSS and Accessibility. Should Jane be complacent?

Again, the answer is No. The Accessibility test alone poses some problems. The tests only measure some of the criteria. The remainder should be completed manually from the appropriate checklist. Other problems are less obvious to spot and may even arise from inappropriate use of the techniques. A common example of this the use of multiple <br /> elements to space content down a page, instead of using CSS to control the layout. The process of translating a visual design to XHTML/CSS needs to be carefully done to ensure that the end result meets our goal of a high quality product.

Using EWD to monitor standards compliance

EWD helps the developer by providing automated standards based compliance tests. However, manual checks will still be required and appropriated use of techniques can only be achieved through care in the development process linked to a well informed approach.

Validation Task PanesThe validation Task Panes give you access to Compatibility, CSS checking and Accessibility tests. The image shows the Accessibility check. EWD can create a web page report of the checking process by clicking the Generate report button Generate Report button.

CSS Reports dialogThe Check button Check button brings up a dialog which allows you to specify the scope of the test and what aspects should be tested. The CSS Reports dialog shows the scope (Check where:) and the aspects (Check for:) for CSS checking.

Accessibility check optionsThe Check for: section for accessibility has a range of options. Note: WCAG Priority 3 is not included and must be checked using an external tool.

Compatibility check optionsThe Check for: section for compatibility includes options for HTML and CSS validation. By default these will be set to match the options you used when initially creating the website (set in the Tools| Page Options … dialog) and you would usually keep these unchanged.

Guidance for standards based quality checks

The following sites and links give good advice on maintaining quality when using a standards based approach. As a professional you should always refer back to these sites to keep up to date with latest practice.

World Wide Web Consortium (W3C) pages

Web Accessibility In Mind (WebAIM)

Creative Issues

One of the most thorny issues with web page developers is one which has been around for a long time and one which one would hope had gone away, namely, the use of tables for layout. There are still developers who use complex and unnecessary table structures to force their web page to appear how the want it, despite the incontrovertible facts that tabular layouts pose difficulties for screen readers and are inflexible when you are faced with a design change. If anyone needs convincing that tables are unnecessary for recreating the sometimes whimsical designs coming from the creative team then you need look no further than the CSS Zen Garden website. Here you will find an almost endless variety of designed pages all based on the same underlying table-free XHTML web page.

Recreating a design using XHTML and CSS so that the end result is standards compliant, accessible and usable is the challenge. Some of the issues are resolved by following the guidelines associated with the standards, but others may need to be resolved with the designer. If a visual design is inherently unusable, e.g. through poor colour combinations or cluttered layout, this should be signalled straight away and resolved with the design team.

Planned design is covered in more detail in the next page of the tutorial, but for now let us make the statement that: 'A developer should only produce a web page that matches a pre-existing design'. By this we mean that the development process needs to be separated from the design process. Inevitably there may be some drift in the design, but this should be through a carefully monitored and audited process.

Unfortunately EWD doesn't give us much help in this part of the process. The tools help in the creative process of matching design aspect to web page code, but initially we need to use raw XHTML to create the skeleton for the pages. The previous page on template based development hints at this with its demonstration of taking a classic three section web design to produced a template based in <div> elements. We need to be able to look at a visual design and identify the top level structural content elements. Fortunately, these are usually easy to identity, such as the header, navigation, content sections etc.

Once we have our structure we can use the design tools in EWD to work with the styling of the page. We should aim for as clean a structure as possible, and a consistent use of structured elements. This will be covered in more detail in the next page.

Engineering Issues

When we think of quality in engineering we may assume we are looking at things such as components that fit together properly with all the screws securely fixed, rather than the coding of a website. However, a website can be thought of as a built structure, and inherent quality in the construction is something to aim for. Validation does not pick up issues such as poor code structure or consistent use of naming conventions, but these are just as important as other quality issues.

Example 3

John Doe takes a slap happy approach to coding. He uses the code view more than the design view in his web page development tool and happily types XHTML codes directly. The resulting code is shoddily laid out and it is difficult for a third party to see what is going on in the code.

The extreme case of this approach would be an XHTML file consisting of one line of text. Fortunately, EWD provides a simple technique for achieving a reasonably consistent and readable layout for the XHTML code. In Code View right click in the code and choose Reformat HTML. EWD will reorganise the code so that elements are consistently formatted and lined up.


Quality in engineering terms is all about using tools and techniques and using them properly and consistently. There is an almost endless list of advice which could be provided under this heading and some of it appears in the guidance accompanying the various standards. What is presented here is a starting point in your search for perfection.

  • Try to avoid inline styles in your HTML. If you do, it should be for unique styling effects. The impact of inline styles can be global to your site if the styles are in the template, though you should avoid using techniques like this which require you to modify page content if you want to have a change in design.
  • Adopt a consistent and informative layout within your pages. EWD automatically uses a layout mechanism to help with this. Unless you have specific layout requirements, e.g. company policy, use the technique in your page editor.
  • When naming elements adopt a consistent naming technique. For example, all lower case, using meaningful names. Good example - class="rightimage" for a right align image. Bad example - class="Style5" for the same thing.
  • Use id and class attributes in an appropriate way. Identically styled elements should use class syntax rather than id syntax
  • Adopt an appropriate website structure and stick to it. Putting site wide images in a separate folder from page specific images help with management. Separating pages with a folder hierarchy helps too.
  • Adopt a consistent and meaningful naming convention for files in your website. image001.gif, and page001.htm don't help you or the users in understanding what is what. largewidget.gif and products.htm are far more helpful.
  • Use the tools to help with maintaining quality. Regular accessibility, compatibility and CSS checks will keep your code basically sound.
  • Use coding in an appropriate way. Using <hr /> for decorative effects is bad. Using CSS borders and margins to separate hypertext links only works for people who can see the effects of the CSS. Separating structure and layout (XHTML and CSS) is the key!
  • Perform manual checks for your pages, especially where automated checks are not available. If you want to conform to WCAG Priority 3 you will need to use an external validation service as well as providing an audited inspection of the manual checks.
Valid XHTML 1.0! | Valid CSS! | WCAG Approved AA
Page design by: John P Scott - Hosting with: Netcetera