- From: Kassia Krozser <ktwice@pandemic.com>
- Date: Fri, 18 Jun 2004 09:00:43 -0700
- To: w3c-wai-ig@w3.org
David Woolley wrote: > A pre-requisite for this is that authors use the styles, defined by Word, > to mark up the document properly, which means that the authors still have > to understand structural markup, and not operate in a lazy WYSIWYG mode. > I don't know how well this markup is reflected into the HTML generated > by Word, but I believe that Acrobat uses it to create tagged PDF, which > is essentially an HTML structural overlay on the page description. > This is more or less the same as for direct HTML authoring; that can, > and more often than not, is done in a non-structural way. There are two issues with this. First, of course, is that an entire generation of word processor users have been taught to operate in WYSIWYG mode. To them, this isn't a lazy approach; it's how they learned to use the tools. And it suits their purposes just fine, so why would they change what they do? Re-educating these users would be a massive and probably expensive proposition. In an informal poll I did (basically people in my circle of acquaintance, but all very experienced computer users), I discovered I was the only person to use styles at all. The concept was greeted with blank stares. Second is that, even using styles, you don't get good HTML (my partner says it is well formed in that tags are closed, etc, but it's not good HTML. To understand what I mean, you need to view the HTML for a Word document). And when you convert a semantically correct Word document to PDF, the resulting HTML is not necessarily right. Going into the PDF tag editor to do clean-up is not easy -- a five minute project can stretch to thirty or longer. I went through this on a report we recently issued, and, as Joe Clark pointed out (though I did already know it), there were a few minor accessibility issues. I couldn't fix them in the PDF markup, and, after researching for a while, think perhaps I know the solution. But I have the time and inclination to put forth this effort. Most people who work day-to-day on websites don't. This is a real world issue that has to be addressed if businesses (and I'm including government agencies) are going to include accessibility in their web routines. They're not anti-accessibility, but there are a lot of hoops to jump through that don't need to be there. The commonly used tools should provide better support; so much burden is placed on developers and web professionals, but when you get down to it, most websites are managed by people who don't know HTML from the bold button in Word. > Creating valid HTML, in the sense that it passes the W3C Validator, is > a relatively mechanical process. Creating semantically valid HTML > from a purely physical document is an AI problem. I agree that creating valid HTML is a mechanical process...if you know HTML. Most people don't; this why I believe commonly used tools must be better at creating standards-based HTML documents. For a recent government project we did, the "webmaster" was a person who had never touched a website in her life. She wasn't particularly well-trained in Word, doesn't know Excel, and thought PowerPoint was a great way to present document outlines -- and yet maintaining the website was to be her job (in addition to her regular job, which requires her to be out of the office most of the day). She's learned a lot about HTML, but only as it relates to her day-to-day site updates. She's not particularly interested in web development or learning more than she needs to about the Internet. This is a common website manager. This is the person who needs education and good tools. We've done the education part as much as possible, but cannot change the fact that the tools used in her organization don't help the process. I feel a bit like I'm up on a soapbox, but we face this issue every day, and find the desire for accessible websites exists in our clients, but the realities they face complicates the matter. Kassia Krozser Pandemic Media ktwice@pandemic.com (626) 791-5852
Received on Friday, 18 June 2004 12:00:57 UTC