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.
The added bonus is that you can also support non-standard browsers, low broadband, people who don't want to download and install plugins, etc.
Personally, I'd dump the showy stuff, but then again, I don't do this as a business.
Incidentally, does anyone know of anything you can use to check how accessable your site is?
I can spell. I just can't type.
For fonts, colors etc. use CSS. These will not interfere with browsers that do not support it. Make sure that you use an external CSS file - do not put CSS code inline. This has the added benefit that changing your style for the whole website requires only changes in that single CSS file.
Try to limit Javascript as much as possible, only use it for added value, not for essential things. Many people switch off JS, because of all those annoying popup ads.
Do not design your site for "800x600" or any fixed size. It will annoy the users of large monitors, that do not maximize their browser windows.
To state the obvious: The website will not be visited because of its style, but because of its content. The more often a user visits your site, the less important is the design - it will even annoy users if it slows down their browser. Of course, if you think that your users visit your site only once anyway, then you should get the most flashy, cutting edge design possible.
Users will not complain if your site locks them out (unless you *really* have valuable content), they simply quit and never come back. Ask yourself: how often have you contacted a webmaster because of broken HTML/JS/etc ?
I was actually more concerned about accesibility by those with disabilities than with what browsers people visit with, but I guess I didn't specify that well enough. My mistake.
My user name is linked to ``http://v4mpyr{at}mail{dot}com''. It should be ``mailto:v4mpyr{at}mail{dot}com''. Ugh.
When I stated ``they make the clients happy'' I was referring to all the flashy images and fonts I had mentioned earlier in that sentence. That was pretty clear when I submitted however an editor's ``fix'' kinda blurred that point. My personal sites are toned down and fully accessible - it's the client sites I'm concerned about.
--
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...
"... because they never envisioned someone having more than 1024x768 graphics viewing the site."
;-) in the corners...
Hm. I'd have to say that once you get above 1024x768, it's a little silly to be running most standard applications fullscreen. First of all there is the fact that I don't know of any websites that will look even the slightest bit better with more screen real estate than that 1024x768 gives you. And secondly, having windows is nice because you can have them all floating around each other, and you can see two (or more!) applications at once.
At the very least, you should leave some room to have random eye-candy (play mp3s w/ visualization - mute them if you don't care for the noise
Just a quick note, I went to the bobby page that was linked, and, because I tend to think of nasty things like this I ran the bobby page through the page checker - just to check their own site out ;)
I was kind of shocked by the results:
- Priority 1: User checks are triggered by something specific on the page; however, you need to determine whether they apply. Bobby Approval requires that none of them apply to your page. Please review these 6 item(s)....
- Priority 2: 9 Priority 2 issue(s) that Bobby has identified......
- Priority 3: 5 Priority 3 issue(s) that Bobby has identified......
- Browser Compatibility: The following section contains a list of 6 browser compatibility errors.
If I was writing a web page that checked accessibility then I would have made sure that it passed my own checking software!If you ever drop your keys into a river of molten lava, let'em go, because, man, they're gone.
Designing Web Usability (Nielsen)
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....
That's easy to forget. It was never intended to be used for page layout.
Go ahead & design you pages to look good, but comply with XHTML standards, and keep a few things in mind:
Use descriptive tags (<cite>,<em>) instead of sylistic ones (<i>,<b>).
The devices used to access the Web will determine how to interpret the elements within these tags based on their purpose. A browser might italicize a citation, whereas a device for the blind might 'speak' the words in a different voice.
Oh yeah, and stay away from <font> tags. Use CSS instead.
If you follow the W3C's guidelines for XHTML, your pages can still look good, because the devices used to retrieve the data will strip out the information & present it in a format suitable for the audience.
Browser? I barely know her!
I see so many sites that say... "Oh you have Netscape 4.7... you MUST want to use java, flash, and all this other STUFF you probably don't want" Developing content for the non-frame, non-graphical browser seems to be the last concern, but the content providers should realize that graphical browsers can display text too. Backwards Compatability!