It’s been a long trip, but we’re almost out of the dark. We finally have browsers that offer substantial support for several technologies established by the World Wide Web Consortium (W3C) and other standards bodies. Designers and developers can use many core features of XHTML and CSS and sometimes DHTML without worrying about the hazards of cross–browser chicanery.
As browsers have evolved, it’s become easier to comply with the W3C’s Web Accessibility initiative (WAI) and, in the United States, with the amendments to Section 508 of the Rehabilitation Act of 1974 (commonly called “Section 508”).
Better browsers are only the beginning#section2
With the advent of standards–compliant browsers, we need to turn our attention to the tools that help designers and developers build the web. Professional developers and homepage hobbyists alike can code their pages with simple text editors. Hand coding, however, won’t always allow developers to meet tight publication or delivery deadlines.
If web development tools like Macromedia’s Dreamweaver, Adobe’s GoLive and Microsoft’s FrontPage (among countless other applications) do not generate standards–compliant code, the work of convincing the browser vendors to support standards will have been wasted. The creation of content will be trapped in a shell—legible only in a handful of browsers, locking out millions worldwide.
Furthermore, web development software vendors are in a unique position to educate their customers about web standards: what standards are, how they work in the context of the web, and how they help make sites more accessible.
For an insight into their contributions to date, I interviewed representatives of Macromedia, Adobe, UsableNet, and The Web Standards Project and reviewed some of the tools that are available for accessible web development.
Tools make the developer’s deadlines#section3
If web builders must rely on software to do the grunt work of site building, the tools they use should be designed to generate standards–compliant code by default.
“It’s critical that these tools facilitate the creation of valid, standards–compliant sites rather than merely allowing highly sophisticated users to create such sites with extra effort,” said Jeffrey Zeldman, ALA’s creative director and group leader for The Web Standards Project (WaSP), an organization that promotes the use of web standards.
“Though these authoring tools are used by pros, they’re also used by tens of thousands of people who ‘double’ as their organization’s web developer in addition to doing their real job as a marketing person, secretary, graphic designer, and so on.”
The web development tools we have#section4
By allowing users to customize their authoring products, and/or by forming partnerships with companies, web development software vendors have made it possible for designers and developers to produce accessible websites with their existing web tools.
It’s not the “out of the box” solution the WaSP is seeking, but these software vendors are working to educate their customers about standards and accessibility–related options, and to better integrate their products.
Macromedia#section5
“We have worked hard to make this easier, though we are still in the early days in this area, and will continue to work in partnership with developers, partners, and other industry leaders to improve support for creating accessible websites so that these technical barriers can be removed,” said Kevin Lynch, Chief Software Architect for Macromedia.
In addition to including numerous changes like an enhanced user interface, improved rich–media support and a pixel–level snapping tool, Macromedia’s recent version of their vector–based animation tool, Flash MX, takes a giant leap forward in accessibility support.
Through Microsoft Active Accessibility, users with disabilities will be able to access rich-media content with screen readers like Windows–Eyes. Within the authoring environment of Flash, web builders now have the ability to add text descriptions to graphic elements—much like an alt attribute to the <img> tag, but also summarizing looping or animated presentations.
UsableNet#section6
UsableNet, Inc., a Macromedia partner, created the free 508 Accessibility Suite, which extends Macromedia Dreamweaver’s functionality to allow checking of web documents’ accessibility against proposed standards.
If you need a major upgrade from Section 508 Suite, UsableNet also offers LIFT and LIFTPro. LIFT works with Dreamweaver by providing far more than the basic analysis that makes up the free Section 508 Suite.
With LIFT, you can manage a set of accessibility rules you want to test for—be it a subset of Section 508 or WAI. After you generate the reports, you can go through the reports item-by-item, changing problem areas of your website almost immediately at the code level of your pages.
UsableNet also has LIFT Online, which allows developers to test an unlimited number of live sites for an annual subscription fee.
Microsoft and Adobe#section7
FrontPage developers should expect a LIFT–like tool from UsableNet in the next three months. Until then, however, Microsoft has formed a strategic relationship with HiSoftware. Owners of FrontPage can get a free licensed copy of that company’s AccVerify SE™.
And even though Adobe’s GoLive has a few accessibility features built into the software, Adobe has partnered with SSB Technologies to provide a licensed copy of InSight LE for more accessibility checking.
Bobby#section8
Lastly comes Bobby. Started in 1996 by Center for Applied Special Technology (CAST), Bobby is an online tool for checking live sites for accessibility issues. It’s not as extensive as other tools on the market, but you can’t beat the cost (free online). For a price, Windows users can also download a software version of Bobby to use offline.
Educating developers#section9
To help their customers keep up with a sometimes overwhelming amount of information about accessibility requirements, Macromedia has published a Solutions Kit that’s free with the purchase of Dreamweaver or Fireworks. The kit includes white papers on accessibility, FAQs, web page templates, product extensions and much more.
Of course, software vendors can only do so much, and web developers must take it upon themselves to learn and implement standards and make their site more accessible.
“I think the unfortunate part is that most people don’t watch people using their website,” said Daniel Brown, Senior Evangelist for Adobe. “I almost wish that GoLive, LiveMotion, and ImageReady had a little wizard that would pop up every now and then and remind people to take into account the variety of their users.”
Resources#section10
- Standards and Accessibility
- World Wide Web Consortium
- How to Read (W3C Specs)
- Bobby (accessibility/508 validator)
- W3C validator (for XHTML/HTML markup)
- CSS Validator
- WAI Guidelines
- Section 508 (official U.S. Gov’t Section 508 site)
Software#section11
There are too many web development tools to examine here, so if you don’t see your favorite authoring software listed below, contact their customer support and inquire about their accessibility initiatives.
- Adobe
- SSB InSight LE for Adobe GoLive
- Macromedia
- Macromedia Solutions Kit
- Macromedia Dreamweaver Exchange
- Microsoft
- Microsoft and Section 508
- Making Web Pages More Accessible
- HiSoftware’s free AccVerify SE software for FrontPage users
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
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.
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.
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.
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.
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.
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.
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.
Correction to previous post:
“Bobby essentially will not pass” should be changed to “When testing for WAI compliance, Bobby essentially will not pass”
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 . . .
A question for the group – I can make most form elements keyboard accessible through the use of the accesskey attribute of the
here’s some code to try out. note how alt-f is taken over by the page and no longer pops the file menu…
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 🙂
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/).
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.
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.
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]
Navigation Links
[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!
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
>Lastly comes Bobby… (www.cast.org/bobby)
Bobby provides one of the most counter intiutive
interfaces I met so far.
Marek