The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Designer vs Coder and accessibility issue

You get a well designed layout which people like and your boss has already accepted it. Layout has fixed width and is quite complex with many buttons. Commercial font is used for text on buttons (also menu) and banners (no option for text resizing - I`m not convinced to use sFIR method).

Of course it`s no problem to create even very complex layout using HTML+CSS. However it might be a problem to implement additional functionalities which provide better usability and accessibility.
To give an example:
- layout is fixed and complex. I must use pixels for both text size and layout structure. Should I provide some kind of text resizing functionality based on Javascript? We all know that browsers give option to enlarge your text or zoom but I guess there are some users who don`t know about it.
- text have some kind of grey color. Should I provide link to change the contrast? Or maybe provide changing whole styles?
And where to place such "functionality" links? In the footer I have a link "About site" which will describe all stuff like that, i.e. "accesskeys", how to change text size... But again... there is no guarantee that user will ever read this. Is this kind of section worth doing?

What is your experiences when it comes to deal with beautifull designed layout by people who don`t care or know about user and its disabilities?
Thanks for any advices and excuse me for not publishing the layout project. At this time I`m not allowed to do so.

Sounds complicated.... Just stick to clean simple design. Dark text on light background and comply with all the unsability rules, mainly because it's good SEO, and because you want guide dogs to be able to use your website.

Image-based menu:
I can see that you have some struggles with this. Sites don't really use images for nav menu anymore. If they want corporate font on nav, most big sites these days go for a flash implementation. You can always start with showing a text-based nav, and if they don't like it swap out with images. (It should be list-based in both cases, so it only takes you a little bit of extra work to later plug in the images if the client/designer insists). - Something like this will work in your case, although it's not 100% clean separation of structure and presentation that you usually want to achieve:
orlandodefrias dot com/2008/07/10/image-based-menu-with-css/ (cannot post any urls yet, so you have to adjust it accordingly)

I would not recommend going for a list-based menu with background-images, because they totally disappear from a page with images turned off, while foreground images have alt text to display.

Font-resizing
Since IE7 still doesn't do a good job re-sizing pixel fonts (screen zooming function that causes horizontal scrollbars), it might be a good idea to add javascript for that. However, it will take you extra time, so if you don't get paid for it and you run out of time, don't worry about it right away. If you have time, add it somewhere in the header area.

Grey text
I would not add script to change the text color. If the text is too light, it needs to be made as dark as you can get away with without upsetting the designer. You can always set the color value back to lighter in css if you lose that fight.

Overall make sure that your markup has a semantic structure, i.e. you divide page sections with using heading levels, add skip nav, follow a logical document flow etc. This should work no matter what design you have to deal with.

And I would suggest not to add an Accessibility link to the footer unless the client is dedicated to accessibility. There's nothing worse than the standard "we care about people with disabilities... please contact us if you have problems with our site" on sites that did not really have accessibility in mind.

Did you voice your concerns with the design? Sometimes the designers have no problems to adjust their designs if they have the info they need to make different design decisions.

I stick with proper HTML code and I try to keep in mind everything I know about accessibility and usability during the whole process.

@melissapbr:
I use unordered list for menu and using the similar method to yours. However I add some extra markup to make sure that alternate text will be seen when images is off or not supported.
Here is the example:

Btw. this method was explained by Paul O`Brian on one of the sitepoint`s forums.

I don`t like the idea of flash menu. Too many users have it disabled or not installed. It`s slow it needs extra plugin. In my opinion it`s one of the worst option and I can`t agree that big sites choose this one to implement theirs menu.

So, in your opinion I should relay on users knowledge about theirs browsers and options their provide (text resizing)?

Your chosen menu technique works well, thanks for sharing it. I am not suggesting a flash menu at all.

I like text-based menus, but I see that big sites also use the image-based menus (I was just looking at target.com, because they "lost" a big accessibility lawsuit last year and now have mandatory ongoing training for their developers in that area).

If you have time to put a resize option, by all means, do it (if the design you work with is not already overloaded with other things to click on).

Not sure how many users who need the resize functionality would look for it on individual sites. I think it's not user friendly or accessible at all to have to go from site to site and every time find a resize option for that particular site, because most sites set small font for aesthetic reasons. Users probably simply make their own arrangements, such as lowering their desktop resolution or getting "browser-savvy".

I wonder how many users actually use the resize functionality if you put it in? I guess you could track that somehow. That would be a valuable statistic.

.......... If you have time to put a resize option, by all means, do it (if the design you work with is not already overloaded with other things to click on).

Not sure how many users who need the resize functionality would look for it on individual sites. I think it's not user friendly or accessible at all to have to go from site to site and every time find a resize option for that particular site, because most sites set small font for aesthetic reasons. Users probably simply make their own arrangements, such as lowering their desktop resolution or getting "browser-savvy".

I wonder how many users actually use the resize functionality if you put it in? I guess you could track that somehow. That would be a valuable statistic.

When using Firefox ..... same as with MSIE (You can specify "change text size only" in Firefox via the top menu bar: View ---> Zoom ---> Zoom Text only. Setting remains until changed. The above keyboard shortcuts will now only change the text size leaving the image sizes as original).

When using Safari/Chrome ..... same as with MSIE except the keyboard shortcuts only change the text size leaving the image sizes as original.

When using Opera ..... same as for Firefox/MSIE except use shift + for Zoom out.

The above procedures are especially well suited for web page viewing by People with Disabilities who cannot use a mouse (duchenne muscular dystrophy, etc.) and therefor rely on stylus/keyboard functions. Visitors who use a scrolling mouse can zoom/increase text size very fast via ctrl scroll -- for all Browsers listed above -- keyboard shortcut ctrl 0 (zero) returns to original size.

Web developers/authors might want to check pages they are composing to be sure navigation is not affected by incremental zooming (visitors will seldom zoom more than three increments). In my experience, many visitors (especially those with diminished vision) to web pages now increase the text size by one or two increments for easier reading especially when very small text is encountered.

Jamesicus - We are aware of the zoom functionality. What xarr is worried about is the users who never touch their browser settings or are aware of any keyboard shortcuts. Dependent on your target group, there are still users who only click on things on the actual web site rather than using browser shortcuts and settings. A site like sitepoint wouldn't have to worry about it, but other sites might have to think about it a little more.

I used to have a neighbor in his 70's who "discovered" online stock trading. He was using AOL and had no idea what a browser is, but he had some shortcuts to the web sites he needed to go to and clicked around the web page with the mouse to get the job done. Nobody ever showed him how to do the things you are suggesting and it would have confused him. He might have found a text resize function directly on the page faster if it was labeled as "text resize".

sorry zonker720, I disagree to your suggestion, giving up to the original design that the boss OKd already is not the option to go. I think Xarr's don't worry much about SEO because his layout is coded properly right?

Xarr, it can be an option to include text resizing in javascript but the button on where you put it that will be a very big problem. Sometimes little details really give big problems in terms on design.

Thinking about the contrast of the button, hmmm.... does this affect the design. There are also users that if you don't give them the idea they will not think about it.
"About US" is a must on sites, because it is the heart of the site, here is where you want to project the site or promote about it, nothing beats a good content.