A Journey Through Accessibility

Monday, 27th March 2006

Author: Roberto Scano

Contents

• In the beginning...
• The first evolution: accessibility and HTML
• The CMS generation: What You See Is What Only You See?
• The future generation: more standard means more quality?
• Acknowledgements

In the beginning...

Let us take a wayback machine to travel back in time to the last century, or more precisely, to the end of the last century when the web had started to increase its potential.

The first web revolution happened on the 14th January 1997: HTML 3.2 was issued from a consortium called the W3C, a consortium not yet known to web developers. As written in the document's introduction, HTML 3.2 is the W3C's specification for HTML, developed in early 1996, together with vendors including IBM, Microsoft, Netscape Communications Corporation, Novell, SoftQuad, Spyglass, and Sun Microsystems. HTML 3.2 added widely deployed features such as tables, applets and text flow around images, while providing full backwards compatibility with the existing standard HTML 2.0. Ten years later, and this is all history, but in those early years were the first web developers: guys and students (especially inside universities, where the web was available before it was available to the general public) started to develop their first pages using built-in web browser editors. I remember the first version of popular browsers: NCSA Mosaic, then Netscape, then Internet Explorer, and I also remember how difficult it was to configure Winsock.

CSS 1.0 was also on the scene in 1997, but presentation was achieved with markup elements and attributes back in those days. Browsers were not as forgiving as they are today. Mosaic stopped rendering content on the first markup error. When HTML 3.2 was first introduced, the HTML Writers Guild (there has been an HTML Writers Guild since 1994), merged with IWA, and only had their plain text editors for creating and editing content when the first shareware / freeware application for developing HTML was issued. I remember, for example, AOLPress 2.0 - one of the first WYSIWYG editors available since 1995 that didn't allow the creation of invalid markup: all markup that did not conform to HTML 3.2 (or the old Netscape HTML version, which only differs slightly with the W3C's HTML 3.2 recommendation) was removed or fixed automatically by this tool. These were the first generation HTML editors that had knowledge of tags and attributes, and they also understood that they had to be able to produce pages that were visually pleasing, valid, and not heavy (due the poor connectivity around the world at that time). At this point in time, there were no references to web accessibility.

[Back to the contents]

The first evolution: accessibility and HTML

After some months, on the 18th December 1997, the W3C issued the first version of HTML 4.0, with a revision on the 24th April 1998. What were the major differences from HTML 3.2? The following elements were introduced: ABBR, ACRONYM, BDO, BUTTON, COL, COLGROUP, DEL, FIELDSET, FRAME, FRAMESET, IFRAME, INS, LABEL, LEGEND, NOFRAMES, NOSCRIPT, OBJECT, OPTGROUP, PARAM, S (deprecated), SPAN, TBODY, TFOOT, THEAD, and Q. The deprecated elements from HTML 3.2 were: APPLET, BASEFONT, CENTER, DIR, FONT, ISINDEX, MENU, STRIKE, and U.

HTML 4.0 was the first HTML version that had notes for accessibility:

As the Web community grows and its members diversify in their abilities and skills, it is crucial that the underlying technologies be appropriate to their specific needs. HTML has been designed to make Web pages more accessible to those with physical limitations. HTML 4.0 developments inspired by concerns for accessibility include:

• Better distinction between document structure and presentation, thus encouraging the use of style sheets instead of HTML presentation elements and attributes.
• Better forms, including the addition of access keys, the ability to group form controls semantically, the ability to group SELECT options semantically, and active labels.
• The ability to markup a text description of an included object (with the OBJECT element).
• A new client-side image map mechanism (the MAP element) that allows authors to integrate image and text links.
• The requirement that alternate text accompanies images included with the IMG element and image maps included with the AREA element.
• Support for the title and lang attributes on all elements.
• Support for the ABBR and ACRONYM elements.
• A wider range of target media (TTY, Braille, etc.) for use with style sheets.
• Better tables, including captions, column groups, and mechanisms to facilitate non-visual rendering.
• Long descriptions of tables, images, frames, etc.

This was the period where the use of large WYSIWYG editors became popular, which resulted in the propagation of incorrectly using elements, such as the table element, for presentational purposes. In order to understand how problematic table rendering was in these early years, I suggest you read the note put in the first version of HTML 4.0. There was also the great idea (the emphasis is sarcastic) of using frames for creating templates for websites. At this point, I would like to remind everyone of the preamble mentioned at the start of the Transitional DTD:

This is the HTML 4.0 Transitional DTD, which includes presentation attributes and elements that W3C expects to phase out as support for style sheets matures. Authors should use the Strict DTD when possible, but may use the Transitional DTD when support for presentation attribute and elements is required.

When new web developers started to use WYSIWYG editors with no knowledge of HTML DTDs, the Transitional DTD was widely used. Why Transitional? The phenomenon can largely be explained because the Transitional DTD permits "tag soup": from HTML 4.0, there was no control regarding generated markup, so new web developers created content, and in the process, made some big mistakes, such as the following:

• Layout tables - WYSIWYG Editors usually used fixed dimension for layout tables, and added attributes that are not allowed for presentation, etc.
• Alternative text - WYSIWYG Editors didn't automatically request alternative text for images, or, in the best cases, automatically used the filename for the alternative text. The same problem occurred with framesets: the classic message your browser doesn't support frames was used as alternative text for the frameset, and this is a problem that still exists today.
• Headings - Headings were incorrectly used for their presentational effects, instead of using CSS.
• Quotations - Elements like <blockquote> were used for visual formatting, instead of a more appropriate element for the content.
• Fonts - The font element, along with its attributes, were heavily dispersed throughout the document, often with illegal nesting according to the specification.

At this point in time, developers had various levels of expertise and web development knowledge: some knew something about markup requirements, some (very few) started to take an interest in accessibility, but most developers started using WYSIWYG editors like MS Word. The available WYSIWYG editors did not produce valid markup, and the terrible ones were the editors that permitted copy & paste from Word documents, copying the entire word processor markup inside the HTML page.

Also in 1998, the W3C developed the second version of CSS that was not fully supported and handled differently by the latest versions of browsers at this time: this should help one understand how things were done in 1998...

[Back to the contents]

The first revolution: WYSIWYG vs. WCAG, ATAG, XHTML and CSS 2.0

1999 was the year the Web Content Accessibility Guidelines (WCAG) were released: on the 5th May 1999, WCAG 1.0 became a W3C Recommendation. This was the first set of international guidelines developed by the W3C Web Accessibility Initiative (WAI) with the intent of providing information for web developers to create accessible web content. With this initiative, the W3C presented a set of guidelines for developers, but the big problem was that the majority of web developers were using WYSIWYG authoring tools that didn't observe WCAG.

To ensure that future authoring tools could guarantee accessibility for both generated content and authoring tool interfaces, the W3C issued the Authoring Tools Accessibility Guidelines (ATAG) 1.0, and HTML 4.01.

During this same year, there was another significant milestone in the history of markup: on the 26th January 2000, the W3C issued XHTML 1.0, a reformulation of HTML 4 as an XML 1.0 application, with three DTDs corresponding to those defined for HTML 4. The semantics of the elements and their attributes are defined in the W3C Recommendation for HTML 4. These semantics provide the foundation for future extensibility of XHTML. Compatibility with existing HTML user agents was possible by following the guidelines set out in Appendix C - HTML Compatibility Guidelines.

For someone new to the Web in 1999-2000, this scenario could be viewed as a total revolution. But for authoring tool developers, it wasn't a revolution at all, and conformance with the declared DTD was far from utopia for another couple of years. This is very strange when one considers that a simple tool like HTML Tidy was available that guaranteed conformance to a declared DTD, using a simple SGML parser. This was the MS Frontpage and Dreamweaver era, and these tools were not yet ready for accessibility: using external plugins, and with some customisation, early pioneers started to promote the creation of accessible and valid web pages.

What were the main problems for web developers at this point of the web-revolution?

• Obsolete WYSIWYG editors. The major editors on the market didn't guarantee the production of valid markup using an XHTML 1.0 DTD. One of the main problems for these tools was that the templates for creating new web pages didn't conform to any specification and didn't follow any accessibility guidelines.
• Poor knowledge of W3C Recommendations. Web developers had a poor understanding, or were completely unaware, of W3C guidelines for accessibility; instead, they were considered as "something for a restricted group of people". Combined with the poor knowledge of other W3C recommendations, the same errors from the "first evolution" were being propagated.
• Unknown Document structure. One of the biggest drawbacks of editors is that there was no support for the user about how best to structure a document. This means that, for example, using WYSIWYG editors there was no control for heading structure. Consequently, developers incorrectly used elements such as blockquote, unordered lists, data tables, the list goes on.

[Back to the contents]

The CMS generation: What You See Is What Only You See?

And so here we are in the present with a new generation of web technologies; XHTML 1.0 Second Edition, XHTML 1.1, and a growing arsenal of other markup languages and supporting technologies.

The web evolved, and with it came the need for more complex authoring tools: there was a need for applications that worked within a web browser, called web applications, that also allowed for the automatic generation of web content: editing pages, transferring images, document, etc; the Content Management System (CMS).

This generation is referred to as the "what you see is what only you see" (WYSIWOYS) generation. In this era, we face the following problems:

• Inaccessibility of web applications. This is difficult to resolve, and occurs both in "closed" web applications as well as in open source applications - however, the major problem is with the second group: with open source projects there is little initiative to promote accessibility, so the problem is, in the case of CMS's, a lot of websites go online like mushrooms, with a diffusion of inaccessibility. A lot of problems also occur with new generation applications, such as e-learning applications, etc., that require conformance to accessibility guidelines for both the content they generate, and for the publication/editor interface:
  1. It is important that people with disabilities can operate and interact with user interfaces, so there is a requirement to ensure both the quality and accessibility of user interfaces, following the W3C guidelines and latest standards
  2. It is important that every technology has its own accessibility guidelines, and that these guidelines are publicly available: technologies like Macromedia Flash, Java, ActiveX, etc. have accessibility guidelines that developers should follow to guarantee maximum accessibility.
• Inaccessibility of WYSIWYG web editors. A lot of tools for generating web content aren't accessible and/or don't allow content to be published so that it is "valid and accessible". In the past few years, thanks to laws that are under development around the world, there is an increase in the quality of the generated markup. These laws have obligated the manufacturers of classic authoring tools to develop new versions that guarantee a declared level of conformance.
• Inaccessibility of web content and documents produced for the web. This is one of the most talked about issues on many discussion lists. With WCAG 1.0, many people assume that accessibility is limited to markup. But what about other technologies, such as an untagged, inaccessible PDF document that is required to be completed to receive a service from a company or from a municipality? This is a clear discrimination that needs to be immediately addressed, and the new generation must understand how to solve accessibility issues for all web content.
• Poor knowledge of web standards. Thanks to CMS, anyone can add content to a company's website: a secretary or marketing director to specialised "web content editors", "web writers", etc. Without a proper understanding of how to use markup correctly, these "new editors" produce content that is to be presented on the web from the CMS. But if the CMS doesn't guarantee conformant markup, if the WYSIWYG editor doesn't use the CMS defined style sheets, the final result could be that the resulting web page can only be rendered using the same PC and/or the same browser with the same configuration as the "web content editor" who incorrectly assumes the whole world sees the content in the same way that they do. We also inherit all the issues raised in the previous generation, such as incorrect document structure, etc.

[Back to the contents]

The future generation: more standard means more quality?

Despite all this, the Web is continuing to evolve, and in the near future we can expect WCAG 2.0, ATAG 2.0, XHTML 2.0, CSS 3.0, and also ISO guidelines for accessibility of World Wide Web user interfaces (ISO 9241-151. Ergonomics of human system interaction - Part 151: Software ergonomics for World Wide Web user interfaces). This means that the world requires more quality for web interfaces and web content, and also for tools that allow people with disabilities to generate web content that is accessible to people with disabilities.

People involved in these standardization projects have in mind a future world where there is no discrimination, and where the Internet and the Web can be understandable and usable by a great range of people.

What are the points that we want to write and define for the future generation of web developers? Here is how I envisage the future of the web:

• Accessibility for everyone and for everything. International guidelines will set standards for the accessibility of software (OS, applications, software user interfaces, etc.) hardware, for different technologies like Touchscreens, ATMs, etc. There are a lot of guidelines that should be merged in international standards / government directives. This will produce products and services that are accessible to all people: authoring tools, CMS, web application accessibility, and others, will all reach fruition.
• Accessibility for documents. All documents on the web will be accessible to all. Companies that as of today haven't started to define accessibility guidelines for their documents will define them as soon as possible, otherwise they will loose their market position due to working with countries where there are laws in place that require accessibility for all.
• Harmonization of accessibility law. A lot of countries have local laws based or inspired by WCAG 1.0, which is a last-century specification. With the new WCAG 2.0 on the horizon, and with the new ISO standards, I hope that there will finally be a harmonization of national laws that guarantee, and also costs less, for the implementation of web accessibility tools and products.

Developing applications and web content following appropriate specifications will not only make you "cool", but will make you a real web professional.

[Back to the contents]

Acknowledgements

A special thank you to Pam Berman for editing and marking up this document.

[Back to the contents]

Category: Accessibility.