Slashdot Mirror
Constructing Accessible Web Sites
What does the book cover?
Chapter 1 is an introduction to web accessibility. I would guess that most people who pick up this book will already know at least a little bit about accessibility, but this chapter provides a good overview and presents some compelling arguments for providing accessible websites. Interestingly, none of these is based on a moral argument -- they are all sound reasons why it is in the interests of an organization to think about accessibility. For example, one of these sections mentions that people with disabilities in the U.S. are estimated to control a discretionary income of over $175 billion. Making a site accessible to these people gives it access to an additional market that non-accessible sites cannot tap.
This first chapter sets the tone for the whole book. It doesn't preach about accessibility for the sake of people with disabilities but rather seeks to convince the reader that accessibility is in their interests.
Chapter 2 concentrates on one of the major reasons for making web sites accessible - laws that compel us to do so. It presents an overview of the state of the law in different parts of the world and a couple of examples of cases involving web usability. I have to admit I skimmed this chapter, as I wanted to get on to the technical stuff.
In Chapter 3, the book gets on to the mechanics of accessibility -- assistive technologies. It provides a short survey of the screen readers and other technologies that are available. I would have liked to have seen more information here on how widespread these systems are, even if just approximate.
Chapter 4 is where the book starts talking about the actual work involved in creating accessible content. It runs down the basics of accessibility (most of it is good practice such as using ALT text and so on). The blink tag even gets a mention and a "good for them!" is given to Opera for not supporting it :) This chapter will not be news to anyone who has done any accessibility work (or even just best-practices web development). The information on how tables are handled by screen readers is good though.
Chapter 5 looks in more detail at navigation. The advice here is good even outside of an accessibility context and there are some good points about 'gotchas' that could make sites difficult to navigate with assistive technologies.
In Chapter 6, input gets the same treatment that navigation got in the last chapter. I wasn't sure about the stuff on PDF forms (does anyone actually use these for web input?) but the advice on HTML forms was great.
Chapter 7 is about testing for section 508 (of the U.S. Rehabilitation Act) compliance. Initially, this was another chapter that I skimmed, as I am not based in the U.S., but then I realised that the testing advice in this chapter is not just useful for section 508 compliance -- it is useful for general accessibility testing.
Chapter 8 studies the accessibility of web development tools themselves. This doesn't apply to me but it was interesting to see how the tools (Dreamweaver, Frontpage, GoLive, Homesite and BBEdit) compare in terms of usability. This would have been a lot easier if there had been a summary table of the ratings given to the applications.
Chapter 9 seemed a little out of place. It is on "Separating Style from Presentation" and basically looks at CSS. I'm sure most people picking up this book will, like me, not need to be taught CSS basics. I skipped the chapter and very nearly missed an interesting little section on aural stylesheets.
I was surprised that chapter 10 was devoted to Flash, as I expected that Flash coverage in an accessibility book would be limited to a few paragraphs lambasting Macromedia for creating such an inaccessible technology. Well, it turns out that the new version of Flash supports accessibility much better than previous ones. This chapter was a real eye-opener for me. Clearly there is more work to be done but well done to Macromedia for putting accessibility support in!
Chapter 11 didn't really interest me much -- it seems to be more aimed at people who need to implement an accessibility strategy, one to hand over to managers once the technical content of the book is digested.
Chapter 12 is a bit of a heads-up on newer technologies and how they affect accessibility. There is some brief but decent discussion of how technologies such as SVG support accessibility.
The last actual chapter, Chapter 13, is a more in-depth look at U.S. web accessibility law. This was another one that I skimmed but one section did catch my eye. There is a discussion that raises the scary idea that web developers may be held liable for inaccessible web sites, even if their client told them to ignore the issue. If this is true, then it is an important point for every web developer to consider -- could you be held liable?
There are three appendices in the book; a quick reference guide summarises the most important advice given in the book, a glossary of terms and an appendix that details the U.S. Section 508 legislation.
Conclusion
Apart from the basic CSS coverage and the more U.S.-specific sections, I found the vast majority of the information in the book to be very interesting to me. The style was good too -- I was surprised that a book with 8 authors manages to maintain such a consistent and readable tone throughout.
Overall, I found the book a much more interesting read than I was expecting it to be. It gives specific advice about the way web sites should be constructed with accessibility in mind and offers strong arguments for following the advice.
It seems that accessibility is going to be a fact of life in web development. That being the case, every web developer needs to learn at least something about it, if only to use as ammunition in interviews. I would definitely recommend Constructing Accessible Websites as a good source of information on the area.
You can purchase Constructing Accessible Web Sites from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
when you can check your site for these guidelines on the web here?
I forgot to mention of course that in many EU countries, certain bodies (governement, education, , vendors, larger companies et al) MUST make at least the core functionality of their sites accessible to people with sensory disabilities. I'm not sure what the exact laws are, but if you develop for any of the above, and you don't do it right, you could end up in a lot of trouble!
:-)
Slashdot would *just* pass the basic test, I'm informed
M.
*...Slacker, Artist, Techie - Geek *
Remember: Nothing is Cool.
Nope, you miss the point.
This isnt about your personal website, this isnt about your blog, or your Sailor Moon fan fiction.
The key here is if you run a venture that is designed as a place of *public accomadation*, then it must be accessable to all the *public*. That's the key word.
If you sell products or offer services, everyone needs to be able to access those products or services.
Ie; there's no law saying you need a wheelchair ramp on your home. If you run a restaurant, hotel, or other place of public accomodation, then there is.
The same rules about accessability coincide with good web design for the most part. Don't scan your paper catalog and serve a bunch of jpg files. Dont force people to chase down one of those stupid javascript adverts that blocks the page until you answer its poll, etc.
I don't need no instructions to know how to rock!!!!
Adapting existing sites, on the other hand, can be troublesome. If the site was designed well from the start that certain elements are modulized, adaption to accessibity should be near trivial. However, those sites that build every page uniquely will have a much harder time of getting to the end goal of accessibility. Particularly for those sites that were build by WYSIWYG editors that do not account for accessibilty options (such as tag-soup output engines).
But the key is here that there's two critical legal elements that will affect site accessibility in the States at least: Section 508 rules that apply to gov't sites and those that want to contract with it, and the potental requirement of accessibility to those commercial sites that may be covered by the ADA (see the recent stories on lawsuits against American and Southwest Airlines by blind users). Hobbists', non-commercial, or otherwise personal web sites have yet to be concerned for accessibility and I don't believe they ever will be, as these provide no required service to the general public.
That's not to say that you shouldn't think about accessibility if you run that type of site. Accessibility is not only about making your site available to more people, but it's also about better web design in general; seperate presentation from content, don't treat the browser as a pixel-perfect rendering engine, and the like. A causal site design would certainly do no harm in converting an inaccessible site to one that is, and that could mean more visitors and also improving one's HTML/web page skills.
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
This is how the BBC tackles this issue: Betsie It was simpler to handle things this way rather than expand rules for coding pages.
Web accessibility doesn't prevent beautiful pages. The Web Accessibility Initiative by the W3C has information on making web pages that degrade well. This means that you can have all the flash, Javascript, ActiveX, and everything else you want, and still let someone using Lynx and a screenreader hear what you have to say.
I can't say that I don't give a fuck. I've just run out of fuck to give.
* That doesn't mean using Dreamweaver or any other GUI HTML design software. Real HTML-ers write it by hand. Real Men use vi from what I hear but I like BBEdit for UNIX.
Strange women lying in ponds distributing swords is no basis for a system of government.
Well most peoples' websites don't need to be changed. These laws are only for institutions offering public services. This isn't your blog, somebody's homepage, or anything like that. This is sites that everyone needs to access because they are pointed there in order to do business with a company, or work with a government agency.
I think a good compromise here would be what a lot of people did back when frames were all the rage. Simply offer a no-frills page for people who are disabled. You get to keep your flashy page for your regularly abled (hah) consumers, and those who need special access can get it.
Also, I don't personally use/need screen readers, what I do need is websites that do simple things like respect my need for larger fonts (that means flash is right out). A lot of websites don't do that, and until the last year or so I had to actually copy out the text I needed to read and paste it into something else. Now mozilla at least does text enlarging which makes my life a hell of a lot easier.
"question = (to) ? be : !be;" --Shakespeare
This site was incredibly useful for me in making my website more accessible.
--Chris http://chris.quietlife.net/
Actually, the newest Flash version has capabilities for disabled people. the Nielsen Norman Group helped them in adapting the product for different target groups.
The latest Alertbox of Jacob Nielsen talks about Making Flash Usable for Users With Disabilities - also the subject of a tutorial at Macromedia DevCon in Orlando.
Teenagers these days don't have as much sex as they want each other to think they do.
Then why do you let the html dictate what font's/fontsize you see?
In the 3 major browsers, its easy:
Moz: Edit|Preferences|Appearance|Fonts - choose your font's and typesize, and uncheck "Allow documents to use other fonts"
IE: Tools|Internet Options|General Tab - Fonts Button: Set your Fonts and typesize here|Accessablity button: check the 2 "Ignore font..." box's, or you can supply your own style sheet
Opera: File|Preferences|Fonts: there are too many options that you can control here, upto and including using your own style sheet.
It's not difficult for the end-user to do, or to have it done for them by a helper.
Just my
Sometimes people just have to learn and adapt to change, it is one of the requirements of being a living thing.
I'm surprised that there isn't a chapter on accessibility and dynamic visual data (charts and graphs, etc.). This is probably one of the most difficult things to do in creating an accessible site. Example: how do you get a description of those ever changing stock charts, or sales information? There are lots of data that are displayed graphically that also needs a description to be accessible, but there aren't many tools out there for creating that description dynamically. Corda seems to be one of the only companies that I've found that has a solution for this. Their tools will create a text description whenever you create a graph. Sure the description may not be the best, but most of the time it will do the job.
infested with jello like fishes no melotron wishes
Why? Here's the quick course:
On the web, the primary way that information is represented is in the form of HTML and XML documents.
Neither HTML nor XML was designed as a visual medium; rather, both are intended to represent information in a manner that is independent of presentation.
However -- and this is where the problems start -- almost all other media that designers and content creators have experience with (e.g., the ever-popular ink on paper) are visually oriented media, and so many designers and content creators approach web media with this bias.
As a result, all too many web sites are designed with the goal of looking a certain way instead of communicating the intended information clearly. This is an understandable error because with most other media (e.g., ink on paper), these two goals are one and the same. But it is still an error.
To correct the error requires nothing more than the following:
Even if your web site's audience does not include people with disabilities, there are many good reasons for making your site accessible:
There you have it. When doing the right thing is easier, why not do it?
Easy, automatic testing for Perl.
I think it comes down to the difference between absolute font sizes and relative font sizes. I like to use the 'Larger' setting for font sizes in IE (I've recently moved to Mozilla and now use the 150% setting) as it's more comfortable for me and I can read default sized text OK. If a web page uses relative font sizes then I can still read it OK as IE (or Mozilla) will apply the size adjustment I've specified on top of the one specified by the web page. However if the page specifies an absolute size the IE will render the text at that size (I haven't been using Mozilla long enough to make a definate statement on what it does yet), not appling the size adjustment I've specified.
I've tried using the overrides in IE, including local stylesheet, but have found it patchy at best. For example if the page specifies a separate stylesheet IE will use my local one instead, if it uses an inline stylesheet it will override some settings but not all and if it uses style settings in the body of the page it won't override them at all.
Probably for some sites the design and the content are intertwined, however most of the sites I use most often (mainly technical how-to sites, product information sites and Buffy fanfiction sites) the important parts of the content are separate from the presentation/design side of things. I want to be able to read the text, not struggle to read it due to it being set to a small font size or get a headache from the color scheme the page author has chosen to use (e.g. pale yellow on orange, yellow on blue, dark brown on black &c, those are real colour schemes I've seen in the past few weeks).
Stephen
"Don't write down to your readers, the only people less intelligent than you can't read" - Sign on Newspaper Office Wall