Summary

From "tag generation" to the "WYSIWOYS generation". Roberto Scano identifies web accessibility problems throughout the web generations, and summarises where we are now, and what we can expect for the future.

Author: Roberto Scano

Contents

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.

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:

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...

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?

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:

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:

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

Acknowledgements

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

Category: Accessibility.

Comments

  1. [journey-through-accessibility.php#comment1]

    Cheers for that. It's enlightened me a lot on the origins of compliance and accessibility.

    I feel old considering I was 10 when the HTML writers guild formed and 13 going on 14 when HTML 4.0 was first released...

    Posted by Chris on

  2. [journey-through-accessibility.php#comment3]

    Roberto, thank you for this article. The note on the transitional doctype is useful to know! I am tired of people saying that its a valid standard - which it is - but use it for presentation purposes. We are past that stage now - or we should be.

    Thank you

    Posted by David on

  3. [journey-through-accessibility.php#comment5]

    Robert,
    A great article which puts some real and informative context around what many of us feel passionate about. Your comments on the lack of any real impetus for the OS/CMS community to produce accessible output are especially interesting. I think the same is true for e-Commerce platform developers, although that is thankfully beginning to change.

    Posted by Robert Campbell on

  4. [journey-through-accessibility.php#comment6]

    Hi Robert,
    I agree with you.
    I'm also developing an optimization for an existing ASP e-commerce cart making it accessible and I would like to prepare a future article with some guidelines about how to make accessible web applications like WCMS, E-Commerce web sites, webmail, etc.
    I've wrote something of this in my "little" book (816 A4 format pages) but it is only in italian language for now *smile*

    Posted by Roberto Scano on

  5. [journey-through-accessibility.php#comment7]

    Would love to see the cart when it is done just got my Macromedia Certification and the new Adobe Studio 8 and ma having a blast creating websites but do not like Cartwaever and am looking for a new cart system that is easier to use prefreably with Excel 2003 databasing option. Drop me an email when yo uget it done Robert so I can have a looksie!

    Posted by britney on

  6. [journey-through-accessibility.php#comment9]

    Excellent article!

    Just one question: what program do you recommend for people that want to create standards based webpages but don't have time to learn XHTML and CSS ? I still know people who use frontpage, and I would definately want to suggest them something different.

    Posted by Joost on

  7. [journey-through-accessibility.php#comment12]

    Great article Roberto - thanks for sharing it. Accessibility really is coming to the forefront with the new legislation that is being passed. One of the problems I think that exists is that wysiwyg editors in web-browsers, which is how most CMS's do content editing now, produce really poor markup - and what is produced is of course its not the same across all browsers. Does anyone know of a better way?

    Posted by Allan Jardine on

  8. [journey-through-accessibility.php#comment13]

    The W3C User Agent Accessibility Guidelines http://www.w3.org/TR/UAAG/ are also important for accessibility. One of the problems with authoring accessible content is the ability of developers to see the benefits of the markup in the browser. Compliance to UAAG is critical for developers to be able to functionally test their web resources for accessibility.

    See the Mozilla/Firefox accessibility extension for a view of what browsers should have:
    http://firefox.cita.uiuc.edu

    Posted by Jon Gunderson on

  9. [journey-through-accessibility.php#comment15]

    Roberto, well done. Now if I could just get those digital scrap-booking soccer moms to follow some standards, my work would look a lot less inhibited in comparison.

    How do you suppose a "anything goes" approach to web development fits into our future culture? I'm thinking about the 30 million or so "web page builders" on myspace.

    I wonder if application developers should also be held accountable to standards. Shouldn't all the browsers and media players share hot keys (like _fullscreen_) or something?

    Already, usability and accessibility are blurring together as desktop applications move online.

    Remember when the tv remote control made watching tv more accessible? What do you think the web equivalent will be for the remote? A web standard? A piece of hardware?

    Sorry for rambling. Ya did good and it surely does bring back memories.

    Posted by Brent Norris on

Comments are closed for this entry.