Improving Web Design Without Losing Accessibility? 24
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?"
plain and flashy mode? (Score:1)
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?
Re:plain and flashy mode? (Score:1)
As I put in my submission, CAST's [cast.org] Bobby [cast.org] checks the accessibility of your site against a wide variety of criteria. In the advanced mode, you can specify what browsers and versions of that browser you want to check. This list includes Netscape, Explorer, WebTV and AOL.
--
Some suggestions.. (Score:1)
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 ?
Re:Some suggestions.. (Score:1)
Writing style sheets [canit.se]
Web Design Group's CSS Guide [htmlhelp.com]
ZDNet's CSS primer [zdnet.com]
W3C's CSS Guide [w3.org]
A full list of CSS properties [htmlhelp.com] (cheat sheet!)
The cool thing about CSS is it lets the author specify fancy layouts, colours etc, but older browsers etc do not rely on them at all - the heirarchical nature of the document remains intact.
Re:plain and flashy mode? (Score:2)
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 [userland.com] (which I used to use to manage my static site), PHP [php.net], Zope [zope.org], 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 Few Clarifications (Score:1)
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.
--
Dynamic Content and Design Templates (Score:2)
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
Accessibility... (Score:2)
Accessibility and Design (Score:2)
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...
High screen resolutions. (Score:1)
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
Re:Accessibility and Design (Score:1)
The blurb from the above web page:
Or you can read the 'Full Description': Wow, that is really long. Hope the info justifies the lengthLouis Wu
"Where do you want to go ...
Re:High screen resolutions. (Score:2)
>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.
Who checks the checkers? (Score:1)
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: [cast.org]
- 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!Read this book... (Score:1)
Designing Web Usability [amazon.com] (Nielsen)
Re:Accessibility... (Score:2)
If your site is based in the USA, then avoiding a lawsuit [nfb.org] has some positive value. If your site belongs to an organization that receives any government funds, then complying with [access-by-design.com] the ADA [metacrawler.com] is worth at least that much to you.
Re:Zope Book (slightly OT) (Score:2)
I haven't read it though, not enough time to play with ALL the fun stuff.
Re:Zope Book (slightly OT) (Score:2)
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....
HTML is a markup language. (Score:1)
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.
Give me the choice! (Score:1)
Re:HTML is a markup language. (Score:1)
When I first started reading HTML: The Definitive Guide [oreilly.com] (now in 4th edition), I was impressed by how a markup language which was designed to present academic papers could be so snazy. And then I looked at the source of many popular sites, and I bought CSS: The Definitive Guide [oreilly.com] .
I appreciate that /. allows some content tags (em, strong, div), but I want some more (cite, code, dl {for definition lists}). I feel kinda dirty using a physical style tag when I should be using a content tag, even if it is only a weblog.
Louis Wu
"Where do you want to go ...
Re:Give me the choice! (Score:1)
A crack addicted knife wielding tattoed monkey could do a better! Whee!!!
Re:Accessibility... (Score:2)
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).
A better way to look at the issue is to say, ``Hmm, do I want people who use Lynx, or use Netscape with Java, Javascript, and images turned off, or are running Linux on a system where there are no plugins, or ..., to see my site?''
If you're a big company that's only interested in the mainstream audience (who probably run Windows 95 or 98 with Internet Explorer and tons of fancy plugins), then, no, you probably don't care. After all, those people probably don't have any money, anyway. But if you've got a message you want a wider audience to hear, then you'll benefit from accessible site design.
The fact is that accessibility isn't really that hard. It just seems hard when your main goal is to duplicate the appearance of your corporate brochures on a Web browser. Building an accessible site boils down to little more than following good web design practice -- adding close tags where applicable, using contextual tags (<em>, <strong>, <cite>), including alt text for images, and all the other things mentioned in other messages.
But achieving that level of accessibility does mean giving up control. You can't guarantee that a Web page will look the same on every machine (every machine that has the necessary plugins to view it at all, of course). You can't know for sure that the fonts you have on your machine will be available on a user's machine. You can't be sure they'll have the same color depth, screen size, or sound card. And giving up that control is hard, especially when your Web site is being designed by people who were trained for print media, where that kind of control is implicit, and under supervision by executives who don't understand the Internet's history or culture, and see it as nothing more than an extension of television to people's desktops.
You say that the audience for accessibility is less than 3% -- ask yourself this: How many people arrive at non-accessible Web sites, get frustrated, and leave, never to return? Are those people worth your time? What about their friends, relatives, and colleagues?
Re:plain and flashy mode? (Score:1)
Interesting. I do all of my work in a linux environment so I can just use my Apache server to run test sites. I'm interesed in liioking into Zope though - thanks.
--
Re:A Few Clarifications (Score:1)
Actually, accessibility when advanced features are disabled [w3.org] is addressed in item 6 of the W3C Accessibility Guidelines [w3.org], so it's not just for the disabled.
The other thing to consider is this, since your question concerns sites for paying clients: People who turn Java and/or JavaScript and/or cookies off are probably more tech savvy on average than people who don't. So it's entirely possible that people who turn Java and/or JavaScript and/or cookies off would have higher average incomes than people who don't. It would be interesting to see someone do a survey of this; if an income difference were shown to be true, such a result might lessen the enthusiasm of clients for creating sites which require these technologies in order to even work.