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.
Other vendors typically have it for less than Amazon. Go to Dealtime and use their book price comparison engine to get the best price. In this case, they report that Walmart has it for $31.49. And if you provide your zip code, they can compare prices including shipping.
And, of course, there's always half.com for used books.
How can we afford to ever sleep
So sound again
--ebtg
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.
I can't say that I don't give a fuck. I've just run out of fuck to give.
Tables are fine; it's NESTED tables that give some browsers fits.
BTW, the W3C HTML validator checks out your code and will tell you what's not standard. To make sure your code is syntactically correct, make your page XHTML 1.0 compliant, and you'll be in good shape. (XHTML requires many of these 'optional' attributes, like 'alt' attributes for images, and closing 'p' tags, etc. It's very handy; it makes your code cleaner, and it turns HTML into an XML document.)
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.
Well, in a way "they" do. Under the US copyright law, publishers are required to allow agencies serving people with disabilities to produce accessible versions of their books without charging royalties. Thus, for example, organizations like Recording for the Blind & Dyslexic can freely produce audio textbooks for distribution to students with print disabilities.
And there's more on the way. A bill has been introduced into congress (the Instructional Materials Accessibility Act) that will take this further, requiring textbook publishers to provide electronic text files in a uniform format for use by agencies that produce Braille and audio books for students with disabilities.
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.
Mark Pilgrim has a wonderful site at http://diveintoaccessibility.org/
It's set up as a 30-day transformation process, with each day containing a new change. He includes has a few example characters, each with their own unique set of disabilities and/or web-browsing choices, and he explains how each of these people would benefit from said changes.
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
Then why do you let the html dictate what font's/fontsize you see?
;) people choose specific fonts for a good reason. I have in the past not allowed pages to use different fonts, but I would hate to be pushed back into that.
Mostly because I'd like to preserve as much of the design as possible. I think that (at least on some sites
The simple fact of the matter is that since just about every site out there is "done for IE" people *know* what the default fontsizes in IE are. It is very uncommon for people to change their default fontsizes, and I think that when they do webpages should respect that simply because that does not violate POLA. It's not *just* for visually disabled people, those who want fonts bigger or smaller for whatever reason should be able to get them, and it doesn't take much to not hardcode your fontsizes.
"question = (to) ? be : !be;" --Shakespeare
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.
A few weeks back, vennix.com had a very interesting article on what they consider accessible websites for the healthcare/medical industry. Interesting read.
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
Haven't used Opera much and only recently started using Mozilla so can't really comment on those. However I can tell you from bitter experience that the overrides in IE (and the last version of Netscape that I used, four point something I think) work patchilly at best.
Typically they will override somethings but not others, depending on how the page sets things. The overrides are not a universal panacea for poorly accessible pages.
Stephen
"Don't write down to your readers, the only people less intelligent than you can't read" - Sign on Newspaper Office Wall
The Perkins site, IS interesting. Here is a working link :)
My sig sucks.