Slashdot Mirror
Improving Web Design Without Losing Accessibility?
v4mpyr asks: "Like many other web developers my sites usually contain all kinds of design elements such as fonts of varying sizes, styles & colors, flashy images and sometimes even [ack] javascript...all of which are essential to the overall design of the site (they make the -client- happy). I'm a firm supporter of the push to make the internet fully accessible to all of its users, regardless of disability, browser or operating system; however I'm finding it hard to do so while keeping my clients fully satisfied.By the looks of most websites out there it's fair to assume I'm not alone. CAST (the Center for Applied Special Technology) has a neat little tool called Bobby which has helped me out quite a bit. Does anyone have any other tips, ideas or suggestions to improve website accessibilty without hindering overall site design?"
It may require more work, but two modes (i.e., flash/non-flash, text-only/graphical) may just be the easiest way to go -- so long as the content is identical in both modes. I imagine a site with fewer toys is easier to make accessible.
A nice way to manage multiple versions of the same site is to use server-side tools such as UserLand Frontier (which I used to use to manage my static site), PHP, Zope, or any of the many others out there -- these three are the ones I've tried. With a bit of scripting, you can get a good idea of what tricks you can use with a particular client, and tailor the page you serve to that client.
Building static sites with the same capabilities is harder -- as far as I can tell, there are very few tools for building nice sites offline and then uploading them to a remote server. (As I said, I used to use Frontier (which is (1) expensive, and (2) Mac/Windows only), and am currently frustrating myself by trying to bend Zope to my will (made hard by the lack of basic documentation) -- suggestions for alternatives are very welcome!)
A solution to this is to use server-side browser detection and dynamic output the proper header/footer/etc.
/ie/link or /ns/link, etc.
The approach is very simple and can/should be applicable to most server-side scripting languages.
Before any data is processed, detect the browser type/version (plugins too where available). With this you will generate a the proper header/footer and _also_ any sub-table styles, etc. The advantages to this are that you'll be able to have a nice, theme through-out your site (as good design dectates) and you'll be able to provide all the flashy content where available.
The downside: If your site receives a lot of traffic, you might see some performance issues due to all the server side processing. Another issue is that you will have to design/develop a number of different styles for each browser/etc. Also, this can wreak havoc on caching mechanisms (i.e. Squid, etc).
One solution is to do a redirect upon loading the main page. i.e. http://foo.com will detect your browser and go to http://foo.com/ns/. But some browsers don't like redirects. You can fix this by using a splash page and having the splash page send you to the proper section of the site when it's done.
Alternatively, you can have the main page execute dynamically and send a "No-Cache" header (so Squid et. al) will ignore it. and have all links from there (you'll need some dynamic code for this) link to the appropriate section. For example: you go to http://foo.com and click on a link, it might to go
There are a number of ways to skin this cat. Usually the rule that applies is to keep it simple.
-Andy
The question with universal accessibility is how much is that tiny percentage of your audience worth to you if you have limited time and/or resources? Personally I go *way* out of my way making our site's pages accessible in just about any browser, but it's a ton of extra work both in terms of testing and design for less than 3% of my total audience. There are a lot of places, however, where that isn't a priority (take a look at /. in Netscape 2 if you want an example).
I'm not sure using colours and fonts and font sizes is all that bad for accessibility. People who complain about that seem to forget they can override the settings on their browsers for colours and fonts and font sizes. But this is only a general thing - you can take it too far pretty easily.
I've worked on a huge variety of sites and site designs. I've even done an ADA-compliant (Americans with Disabilities Act - they've a set of guidelines) website (it was an earlier incarnation of the Gates Library Foundation website - the current one isn't mine). To do that site, we made everything high contrast (dark links on white/light background), larger font sizes (default or -1 only (that's font size 3 or 2, depending on how you look at it), the table of contents was horizontal, across the top, not vertical. This was because of how screen-readers for the blind work (or, worked at the time - this was a few years ago - they are hopefully better by now) - they work(ed) reading left to right across the screen, and gawd help you if you're using frames - it'll still read right to left, right into the next frame. But that was awhile ago - hopefully that's changed. Anyway, we also used an early version of Bobby to check our site - it finally passed with no complaints (whew!). It took a while to get everything that way.
Some guidelines, off the top of my head - I'm not posting this after a lengthy composition like normal:
1) High contrast on all links - dark text on light, light text on dark, whatever, as long as it's consistently that way. Don't make one area dark on light and another light on dark.
2) If you're controlling the font size in some way (be it through - or + font sizes, fixed font sizes, CSS or not), make them as large as your design lets you get away with.
3) Take a cue from Nielsen - he's got a lot of goofy ideas, but some of his ideas are gems - particularly in the area of page density. In print, lots of white space is good for readability. According to Nielsen's research, the OPPOSITE is true on the web! So, if you're presenting information, organize it very very well - lots of bulleted/numbered lists, etc. Indent things where appropriate, etc.
4) The Web is NOT print (nor is it TV or like a computer program). Font sizes, graphics, dpi, everything is different on the Web than in how print, tv, and regular computer programs work. Everything is relative. You don't control the resolution or size on someone's monitor, nor do you control what colour depth their monitor is in, or if it's been colour-calibrated (the vast majority have not). Colours are darker on PCs than on Macs. People connect at different speeds, and even if they didn't, there's Internet traffic to consider - the fastest T1 can seem like a 56K connection if a link somewhere along the line is flooded. All these things and more must be taken into account when developing a site. Don't make the mistake of thinking you can address all these challenges perfectly - it's just not possible with a realistic budget. Think carefully about each of these points, and come up with a reasonable target audience. If your website is about photography, don't worry about access for blind people, capiche? Likewise, you might also want to consider making your site a bit more usable for those with better-than-average access - I run at 1600x1200 now that I have a 21" monitor and a nice new graphics card. Lots of site developers that have repeating background graphics forget that those background graphics repeat horizontally as well as vertically - so I often cannot see something that's on the page if the contrast between the background graphic conflicts with the foreground, because they never envisioned someone having more than 1024x768 graphics viewing the site.
5) Sound on websites are bad. BAD. MIDI especially. If you're about to use MIDI on a site, don't. Think about it, then don't. If your client insists on it, kill them. There's no excuse for MIDI sound on a website. EVER. Remember: Guns don't kill people - people who run into websites with MIDI background sounds on them kill people! The only good uses of sound I've run into are for imbedded movies and some (some!) Flash sites.
6) If your target audience is using modern browsers, consider using Flash - it's possible to make some quite low-bandwidth 'flashy' sites with some great UI possibilities using Flash. Flash 4 contains neato things like forms and such, and an addition to Flash 5 I read about this morning allows for form validations and other neat tricks. Eventually Flash will be ubiquitous enough to use for a lot more than we do now. Just a consideration.
7) If your client has an existing site, run some browser statistics on the site for a few weeks or longer and find out what people are doing, how they're using the site, what they're interested in, and don't even START designing the site until you've made a careful analysis of that information. Hire an expert to do that analysis if you can. That's a good idea for UI design, too. Hire a (qualified) company or individual(s) to do the site design for you - and I don't mean a graphic designer - I mean a USER INTERFACE DESIGNER. That term is NOT synonymous with 'graphic designer', no matter what a graphic designer may tell you. Pretty pictures do not a good UI designer make, though it is possible to make a great UI that is very pretty.
8) Information architecture - 'architect' your information before you design your site! Organize that information into the LOGICAL segments that your USERS WILL EXPECT (how do you know what they'll expect? Find out from them what they expect, dummy!) Once you've got your information organized, only THEN can you begin to design the site!
There's more to this subject than what I've written above, but quite honestly, I'm tired of typing just now, so you'll just have to live without my pompous bits of wisdom on this topic.
Have a day...
>Hm. I'd have to say that once you get above
;)
>1024x768, it's a little silly to be running most
>standard applications fullscreen
I'd have to say that you don't understand one of the best benefits to running at a super-high resolution. If you also then increase your font size, you get some really crisp text on your screen. Check it out if you have the video equipment - it's a brave new world.
I haven't read it though, not enough time to play with ALL the fun stuff.
Bleh!
FWIW, there is an early draft of a forthcoming Zope book from O'Reilly...
Yes, I know. Unfortunately, all the stuff I need to know falls into the ``XXX FIXME! XXX'' category at this time. I keep checking, though....