HTML

Are 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

In the migration from HTML web design to XML based design, why wouldn't one choose to skip XHTML and go straight to the source, cut the middle-man and code content in XML?

It may come as a surprise or shock to hear this, just when we all thought that XHTML was the happy in-between buggy, irregular and bad HTML, and the neat, orderly, structurally valid XML. Many web designers have come to like the comfort ease of use that one finds in HTML. Besides the short-comings of badly structured HTML and the mix of presentational and layout markup (Believe me, we all know some web designers who refuse to embrace semantic markup and CSS), we can all admit to have liked the forgiving nature of HTML.

It is not more or less a universally accepted fact that HTML 4.x and its predecessors are not future-compatible enough to be used in creating valid and stable web content that is accessible, and that stays faithful to the web content presentation architecture of separating content from design, from mark-up.

XHTML in its various flavours of Transitional, Strict, and to a lesser extent Frameset are quickly becoming the standard markup languages for web content. XHTML is a representation of XML, and when valid, it is as good as any other XML document that is built upon a valid DTD especially when well written, strict and valid.

Client-side XML

XML, the term and the technology is talk about and used almost everywhere. It is thought and talked about by everyone. It is now arguably the de-facto method for presenting and exchanging data between applications, disparate technologies and products. Most of the noise is being made about server-side or inter and intra-application interfacing. for client-side use, this is mostly installed applications.

Making a case for Client-side XML

As a subset of XML, XHTML by definition and characteristics complies with formatting and structural architecture of XML. Technically,XHTML is XML. It even has a DTD (Document Type Definition). If browsers support XHTML, the it supports XML. Through my trials and research, I have found that more browser versions support XML, than these that support CSS 2.x . It is ironic that CSS is more widely used than XML markup, yet they at least have the same support. It should therefore makes sense for anyone who prefers pure XML for markup to go ahead and markup his/her content in XML as opposed to XHTML, and much less in HTML.

This document is one of many that discuss the use of XML in Web Design

http://www.cmsproducer.com/labs/xmlpagemarkup/idonnyxmlmarkup.xml

Too many classes and IDs can lead to the same bloat that plagues inline styling and presentation markup

CSS is the blessing that is saving HTML/XHTML and all other similar mark-up languages from the mess that was caused by the mixing of markup and styling. Many a front-end designer/developer often over-define their markup in fear of not being able to properly target and style certain sections and elements of their content. For instance, one may want to separately control titles, subtitles, images, lists, list titles, list items etc, and one way to do this is to attempt to anticipate all the granular sub-elements of a given block and enclose them in elements that belong to classes, or IDs for more precise targeting.

Motivated by the above fear, one can easily end up with code as shown below:

Although the intentions of this are to markup the content is a comprehensive manner so that ones can control the presentation with pin-point accuracy without ever having to go back to the markup (this is crucial in CMS setups where the front-end developer does not necessarily have access or knowledge of how to modify backend code), the markup is bloated with unused classes and IDs. If all these classes and IDs were to be put to use, it would result in a very large CSS file that basically transfers the bloat and enormity from inline CSS and FONT tags, to the CSS definition file. This defeats the purpose of being able to group like pieces of markup so as to control them and make them look similar while maintaining the ability to apply unique styles when necessary. In the above example is a manifestation of too many IDs being used thereby overly fragmenting the presentation. Using too many different classes also results in a situation where each class has one or a few members, thereby mimicking the use of IDs, with the difference that classes can appear more than one on any given page.

Each of these situations result in a CSS file such as this: A better approach to this would have been to either use a class, or take advantage of the shared specificity of all the bullets to target them as follows: or

With the second example having a higher specificity and thereby presenting a CSS feature that makes it possible to mark-up once, and control the presentation using several CSS files that override each other based on specificity.

Depending on the content structure, one can choose to use or ignore specificity to override other declarations without resorting to !important and inline CSS.

The balanced and sustainable approach to controlling the presentation of your markup is to balance the use of IDs and classes, and use them sparingly. If the content structure is well thought out, one can come-up with a markup approach that uses IDs to identify sections of content; classes to group similar pieces of content within an ID and across the page/content, and elements as a preexisting structural framework that can be targeted without having to attach to a class or ID.

To engage your website visitors and enable them to easily navigate and understand your content and message, you need an intuitive and practical web-site layout and brand. This can be achieved by examining your usability goals and your established branding to come-up with a layout and design that is pleasant, intuitive, accessible, and current.

Static website design

This approach to web-site layout and presentation is flexible but significantly more resource intensive. It also presents a challenge in maintaining a consistent brand and across all the pages of a web-site because all it's pages exist as complete individual entities on the web-server.

Based on the infinitely flexible nature of this approach, we cannot generalize the requirements, cost and characteristics of such projects. For an evaluation of your vision and ideal approach to come-up with a suitable scope, please contact us.

Web Content Management System Site Design

There are a variety of commercial and open source Web Content Management System (CMS) platforms in the market. We specialize in the installation, configuration, customization and template design of Web Content Management Systems based on Drupal. Drupal is extremely flexible and this characteristic makes it ideal for numerous configurations based on the unique requirements of every website.

• Refer to our Drupal Web CMS theme and branding pricing model
• Contact us for an evaluation of your Drupal Web CMS needs