Accessibility, Web Standards, and Authoring Tools

by Christopher Schmitt

18 Reader Comments

Back to the Article
  1. We’ve just begun testing the new forums, produced by everyone’s favorite pixel-by-pixel animator (and ALA’s new List Mom), Waferbaby
    (http://www.waferbaby.com/). If you run into a problem using the new forum, hit the Contact page http://www.alistapart.com/contact/ and let us know. Thanks! Now back to our regularly scheduled topic discussion. - jeffrey
    Copy & paste the code below to embed this comment.
  2. I wish more sites would follow accessability guidelines, not just because it helps the disabled but because a side effect is often a more useable website. It seems that when a site’s development team has to go through everything to make sure it’s accessible they also find spots where it’s easy to make the thing more usable: alt text for pictures, cleaner layout, more standard and thus more usable in non-IE browsers, etc. My suggestion to everyone is to take two minutes to send a message to the contact of your favorite, non-accessible website and kindly ask them to become accessible to improve the experience for everyone.
    Copy & paste the code below to embed this comment.
  3. Sites should follow accesibile guidelines, however most of the time the people who put up the sites don’t care. I think accessible development tools will greatly help the introduction of accesibile authoring. Accessibility is not a strategic issue for many websites, the people who commission them “the customer” are loathe to pay extra money to make sites accessible, after all they don’t pay to make their print adverts accesibile do they? And no I’m not saying that print and the Web are the same thing, but often advertising is a major purpose of the website. Accessible orientated authoring tools are/will be a great step forward, but they are not the silver bullet that some people think they will be. There are plenty of ways to make applications more accessible but the average html author is just concerned with getting the page “done”, all the extra work is not worth it unless the author is quite self motivated or being paid to do it. Authoring tools can’t force people to write accessible websites (if they tried many authors would switch to a different authoring platform because this on was “unfriendly”), but yes they can help.
    Copy & paste the code below to embed this comment.
  4. And then there are those who WANT to make their sites accessible but have difficulty understanding Bobby’s WAI and 508 Reports. I’m becoming more comfortable with 508 and with the checklists it generates on Bobby. WAI is hard, in no small part because Bobby’s results are often so complex and seemingly contradictory. One small example: You’re encouraged to use CSS, yet you’re flagged for it when you do so (because Bobby has no way of knowing that your site is usable even when CSS is turned off). Another: you’re always flagged for using color and told to ensure your information is available even to those who can’t see color. Fair enough, but if you’ve taken pains to make sure your information DOES work for those who can’t see color, you still get flagged and therefore don’t get a clean bill of health on WAI. 508 has many of the same rules, but for some reason Bobby is smarter about granting you 508 approval while reminding you of the rules.
    Copy & paste the code below to embed this comment.
  5. Bobby isn’t very smart when it comes to judging accessibility. I’ve lost count of how often I’ve had to try to explain to a client that there’s nothing wrong with their site, Bobby is merely highlighting potential problems it’s incapable of understanding. What’s possibly worse is that passing Bobby can give a false sense of security, bestowing upon some sites the seal of approval when they’re not actually very accessible. The problem with most authoring tools is that they tend to reinforce the misconception that the Web is a purely visual medium, and companies know if they try to force their users to think about structure & markup yet more designers will grumble and move to Flash.
    Copy & paste the code below to embed this comment.
  6. It’s not always the designer’s fault. There are many (me included) who would dearly love to create proper XHTML & CSS designs, with the greatly increased accessibility this gives but are unable to due a combination of factors. Firstly, most clients are concerned with how a site looks rather than the accessibility of the code. On almost all the projects I’ve worked on this has been the case. Generally there is also a demand for exact rendering in all browsers, necessitating the usual hacks and work a rounds. Secondly, the usual site creation process I’ve encountered in most agencies is for design and build to be separated. So designs are created first by a designer in Photoshop or fireworks. The client then signs these off. The designs are then turned in to HTML templates by a developer. In my opinion this disconnect coupled with the importance placed on look & feel leads to the nasty non-valid HTML that makes up the current state of most of web. I’ve tried time and time again to explain the benefits of XHTML & CSS designs to clients as well as to change to process of web-site creation but have met little success on this matter. It would be interesting to hear of other people who have overcomes these problems as I’m sure someone out there must have.
    Copy & paste the code below to embed this comment.
  7. Although 508 has no legal importance over here (the UK) we still have the Disability Discrimination Act and the open.gov guidelines. I’m using Bobby for the first time on an Further Education site just now and agree with his Apartness’ views on its er, quirks. I’m using JavaScript/DOM for visual enhancements that have no bearing on the function of the site, yet Bobby flags them up and there is no way to tell it to ignore these _errors_. The client is, thankfully, very receptive to the idea (ideal?) of separating style from content. The truth is, however, that realistically, XHTML Strict + CSS just doesn’t cut the mustard yet - not for primetime sites. So for the moment we are making do with Transitional and checking things furiously on Bobby and in the accessibility lab that one of the colleges has.
    Copy & paste the code below to embed this comment.
  8. Jackie, you’re right on the scripting/DOM issue as well. Bobby essentially will not pass any site that uses JavaScript even when the site works perfectly well with JavaScript turned off. That’s another reason I feel better when I do Section 508 accessibility testing than WAI testing. Section 508 testing will pass a site that uses JavaScript and merely issue a perfunctory reminder that the site should work without JavaScript. WAI testing assumes if you use JavaScript you’re an evil cretin who doesn’t care about accessibility. It’s sad and wrong.
    Copy & paste the code below to embed this comment.
  9. Correction to previous post: “Bobby essentially will not pass” should be changed to “When testing for WAI compliance, Bobby essentially will not pass”
    Copy & paste the code below to embed this comment.
  10. If anyone is interested there’s an online event currently running at http://webaim.org/training2002/ addressing pretty much all aspects of accessability. I think they’re into week 2 now but everything from past weeks is going to remin online. They also have some discussion forums running which, whilst not being hyper-active all the time, have got some interestign debates going on. Go and take a peek . . .
    Copy & paste the code below to embed this comment.
  11. A question for the group - I can make most form elements keyboard accessible through the use of the accesskey attribute of the <label> tag but doing so sometimes overrides the accesskeys for browser menus. Is this ok? here’s some code to try out. note how alt-f is taken over by the page and no longer pops the file menu… <form>
    <fieldset>
    <input type=“radio” id=“r” name=“r” /><label for=“r” accesskey=“r”>Radio button</label>
    <input type=“radio” id=“f” name=“r” /><label for=“f” accesskey=“f”>Radio button</label>
    </fieldset>
    </form>
    Copy & paste the code below to embed this comment.
  12. When using Accesskey it is advisable to avoid using any of the letters used by the browser i.e. F, E, V, A, T & H (I’m sure I have seen this information as a Web Standard some where…). As these functions are preset and may be required by the user and by over riding them you may disorientate and confuse the user, which is not a good thing. See http://www.seemug.org.uk for accesskey in action. Just my 2 cents :)
    Copy & paste the code below to embed this comment.
  13. A-Prompt (http://aprompt.snow.utoronto.ca/) is a simple and easy to use software program designed to aid web developers and content authors create sites that are accessible to the widest possible audience. Based on the WAI guidelines, this software toolkit is made available through the collaborative efforts of the University of Toronto’s Adaptive Technology Resource Centre(http://www.utoronto.ca//atrc/) and the Trace Center at the University of Wisconsin(http://trace.wisc.edu/). Ausi disponsible en français(http://aprompt.snow.utoronto.ca/french/).
    Copy & paste the code below to embed this comment.
  14. I apologize for posting a little off of the topic (not sure where else to ask this question), but I’ve recently been working on building/designing my personal site according to XHTML and CSS standards. So far, nearly everything has gone smoothly and I’ve learned tons about standards while having lots of fun. However, I have encountered one small problem: a part of the layout in my portfolio section breaks when viewed with Internet Explorer 5 for the macintosh. I’ve tested the site in IE5/NS6/Mozilla/Opera on a PC (the design is hidden from older browsers) and IE5/NS6/Mozilla on a Macintosh, and it appears that IE5 for Macintosh is the only browser in which this particular bug occurs. I’m not sure what’s going on, although I’m sure that my code is an ugly hack anyway. Here’s the actual page:
    http://www.digital-hearth.com/portfolio/web.html Here’s a page with screenshots (.gif) of both the correct version, the buggy version, and the css and html which controls the presentation:
    http://www.digital-hearth.com/portfolio/incorrect.html Here’s a link to my main style sheet:
    http://www.digital-hearth.com/style/mainstyle.css If anybody has any suggestions or tips on how to hack through this little bug (although it might not be a bug, could just be my crappy code), they would be utterly appreciated. Failing that, if there is somewhere else that I should be asking this question, perhaps you could point me in the right direction? Thanks again.
    Copy & paste the code below to embed this comment.
  15. I don’t know if I quite agree with Ben (http://www.alistapart.com/stories/tools/discuss/#ala-10). I think it depends on which groups of users is using page building tools that are designed to output accessible HTML. The neophytes will notice nothing as they author pages in these new tools. They’ll fill in the prompts and dialogs assuming that pages have always been built this way. I think the real group users to worry about are the supposedly-informed, supposedly-technically-proficient users. These are the ones that will complain the most about the new authoring tools because they’ll have all the bad habits gained from previous generations of tools. They’ll also be attached to a set of server scripts that parse and generate poorly-formed markup. They’ll be hesitant to adapt to these new tools because they will require throwing out a lot of code they spent money on. I’ve been designing accessible, standards compliant sites since ‘97 and one of the things I’ve noticed is that a lot of open source server scripts (blogs, bulletin boards, CMS, etc.) generate bad, and inaccessible markup. I fact a lot of my work these days is simply correcting scripts someone else wrote so that it generates accessible markup. Perhaps there should be a compaign among programmers of server-side code to make certain their scripts generate accessible markup. In theory, these scripts, especially the content management ones, fall under the Authoring Tool guidelines of the WAI.
    Copy & paste the code below to embed this comment.
  16. This is not directly related to Christopher Schmitt’s article but it is about accessibility and I didn’t know where else to put it*. I don’t know if anyone else has noticed this but Mozilla and IE seem to implement ACCESSKEY differently. Mozilla gets it right: Invoking the keystroke associated with a page element immediately activates that element. IE 4 for Windows used to do it the correct way but further iterations have inserted the unnecessary step of hitting ENTER to invoke the element. However my complaint (And yes, I filled a bug with Mozilla many months ago: http://bugzilla.mozilla.org/show_bug.cgi?id=93039 .), is not directly related to that. To understand my complaint consider the following markup: ======
    Jump to site navigation [Much intervening markup and content] <a name=“anchorname”>Navigation Links</a> [More navigation links that follow.]
    ====== IE and Mozilla handle this markup differently. If the user invokes the accesskey in IE (For windows at least.) , the system focus is shifted to the anchor and link tabbing proceeds immediately to any link that follows that anchor, thus allowing the user to hop back and forth in a page and quickly bypass links, arguably the intent of ACCESSKEY. Mozilla, while getting nearly everything else right, doesn’t do this. If the accesskey is invoked, the page shifts to the anchor *but* the system focus is not also shift. If the user attempts to tab, the links still take focus in the order they appear in the markup. To me this defeats the point of accesskey: to offer users a shortcut to content or navigation links that can be used at any time. I guess this is old news. The W3C recs don’t explicitly state what the correct behavior on this point should be and Mozilla One (And all browsers derived from it.) will soon be unleashed on the world but, I still think this is an accessibility issue that needs to be clarified. Which behavior is better for accessibility? * I miss the thread sorted topics of the ALA’s old BBS! However I am very happy to have the boards back in any form!
    Copy & paste the code below to embed this comment.
  17. I recently reviewed the video “ENABLE: People with Disabilities and Computers” and found it to be an excellent resource for healthcare professionals, special educators, and persons with disabilities. Here is an excerpt of the review of “Enable”. === VIDEO REVIEW === For many people with disabilities, assistive technology can be vital for their independence, quality of life and effort to become integrated into society. In the award-winning video “ENABLE: People with Disabilities and Computers”, you will meet a deaf-blind university student, a business man paralyzed from the neck down, a speech impaired person, and many other people with disabilities who demonstrate how technology assists them in achieving their objectives and life goals, and allows them to fully participate in society. Educators, disability professionals, caregivers, employers, and others will be able to use this video in a variety of settings, from training faculty, students and work site supervisors, to helping persons with disabilities understand how technology can assist them. The “Enable” video offers numerous profiles of individuals with disabilities who have experienced how technology can enhance their lives. The profiles cover a range of disabilities, including blindness, speech, hearing and mobility impairments of various kinds, stroke, and cerebral palsy. Each of the individuals profiled describes his or her disability in a personal, unique way, often emphasizing the liberating impact of technology in all aspects of their lives, at work, at school and at home. This video shows all kinds of adaptive technology, both hardware and software. If you are interested in receiving a copy of the video “ENABLE: People with Disabilities and Computers” or would like more information, go to http://www.rehabtool.com/video (This 45-minute video produced by David Bolnick, Ph.D. et al. is closed-captioned and includes narrative descriptions for the visually impaired) D. Gerard, Editor
    RehabTool.com
    Copy & paste the code below to embed this comment.
  18. >Lastly comes Bobby… (www.cast.org/bobby)
    Bobby provides one of the most counter intiutive
    interfaces I met so far. Marek
    Copy & paste the code below to embed this comment.