| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45
Back To Interview list
Michael Smith: I am talking with David Epler about his CFUN talk on "HTML Markup for Accessibility You Never Knew About". I didn't know there was anything new in HTML - what is that all about?
DE: Actually Michael, there were some changes in the HTML 4.0/4.01 specs, but most of us haven't looked at the spec for various reasons. For whatever reasons, most of us continued coding to the HTML 3.2 spec and didn't notice the major changes to the 4.01 spec. Most probably because the major browsers of the time (IE and Netscape) were not really doing much to support standards and were too busy waging war on each other. Remember [marquee] and [blink]?
MS: Oh yuk - the tags of the kiddie sites!
MS: Why is separating structure, content, and presentation important?
DE: There are several reasons, but I'd like to go back to the start. HTML is for marking up text documents; to give meaning to the text through headings, paragraphs, lists, and sections. In the beginning that is what we had, a document (content) that was structured with markup. Then we had the addition of tags like [font] which at the time (before CSS) made sense. Looking at pages with black, times-roman text is boring. So we started introducing presentational items into what was clean structural markup. This is where the problems began.
MS: What do you mean by presentation items?
DE: Things like tables. In fact the situation only got worse by using tables for layouts, along with other practices to get things done in the ever changing browsers that were not standards based for HTML or CSS. The HTML we have made from using all these practices is a nightmare to maintain. I've had problems maintaining pages with 5 or 6 nested tables for layout and having to track down the problem when I accidentally broke it. If we go back to the beginning, with simple structural HTML and leave the presentation to CSS we eliminate the maintenance nightmare. Another benefit is that it becomes much easier to design for accessibility as well.
MS: That is great for screen readers, but if you don't use table tags can you still make attractive layouts for regular folks?
DE: Sure you can make great layouts that are tableless, it is a matter of using CSS. There are several sites that have good examples like Little Boxes (http://www.thenoodleincident.com/tutorials/box_lesson/
boxes.html) and the ever popular CSS Zen Garden (http://www.csszengarden.com/). There are other reasons to go tableless besides getting rid of the maintenance nightmares and enhancing accessibility. Tableless sites render faster in the browser and generally require less bandwidth because of the reduced HTML.
MS: What about data tables? Can those be made accessible?
DE: Ahh... Using tables for what they were meant for, displaying tabular data. HTML 4.01 added several tags and attributes that significantly increase the accessibility of tables. The tags [thead], [tfoot], and [tbody] help mark headers, footers, and table body. But the biggest change to help with accessibility was the addition of scope and headers attributes for use on [th] and [td]. I don't want to get into too much detail here about it, since a good portion of the presentation is focused on this topic. I have quite a few examples of making a table accessible and will be using IBM Homepage Reader 3.0 to demonstrate the examples.
MS: That sounds interesting - I will look forward to hearing about it at CFUN