Web Axe Podcast #34: Design Considerations for Accessibility
[music]
Dennis:
Welcome to Web Axe Practical Web Accessibility Tips. Welcome to Web Axe, Podcast #34: Design Considerations for Accessibility. This is your host, Dennis.
Ross:
And I'm back. I'm Ross.
Dennis:
Glad to have you back again, Ross.
Ross:
Thanks. Thanks for having me on.
Dennis:
Before we get started with the main subject of our podcast, I guess, do we have any announcements to make or events?
Ross:
Well, we just came from the World Usability Conference in Michigan State University and we'll have a podcast about that. That was pretty fun.
Dennis:
Yeah, that was pretty good. That was yesterday, November 14, on World Usability Day, I guess it's called. So every year, that was the fourth annual usability and accessibility event that they hold at MSU. Yes, so that was definitely worthwhile going to. You know, I don't know why they call it the usability and accessibility event because they don't really talk a whole lot about accessibility.
Ross:
No, they don't and there's a kind of here and there.
Dennis:
Yeah.
Ross:
My only guess is that they are tied together.
Dennis:
Yeah.
Ross:
to a certain extent maybe.
Dennis:
Well, I don't want to argue that, of course, but I think that department is usability and accessibility or something.
Ross:
Yeah that's what I am wondering. If it's kind of put on by usability/accessibility department and so they kind of tie them together at least just to get more people.
Dennis:
Yeah.
Ross:
We had some good interviews but it was shocking how any people didn't want to be recorded.
Dennis:
I know, especially the two guys sitting with us at lunch.
Ross:
Yeah. [laughter] I mean Hey we do a podcast. Would you like to talk about what you think about usability? They are like, "Ah no."
Dennis:
"I don't want to be on the microphone." [laughter] But anyways, besides that not a whole lot going on except for see I guess, Refresh Detroit. Our next meet up is the Wednesday after Thanksgiving, we are going to have it in Brighton again. So if anyone in the area, Southeast Michigan area is interested, we will be talking about Web accessibility and standards and everything, come meet us and check that out at refresh-detroit.org.
Ross:
Anybody we met yesterday who we gave a card to talk to definitely stop by and everybody else too. I guess.
Dennis:
Yeah, [laughter] sounds like we will get a few more listeners out of that conference and we found a few neat ideas and companies and one other usability podcast that looks pretty interesting.
Ross:
Yeah, I am a new subscriber to that one.
Dennis:
What's the URL for that?
Ross:
dimecritique.net.
Dennis:
OK so I have to go check that out.
Ross:
They seemed pretty good. They review the usability of everyday items such as irons and rice cookers.
Dennis:
Yeah [laugh] everyday things. All kinds of miscellaneous items and cars. I don't know if they do, I think they do computer too, but yeah, it's pretty interesting. They do all kinds of stuff. It's not just usability for a web site which is pretty interesting.
Ross:
Yeah, I'm sure they have good things to say. I am impressed so far. So worth checking out.
Dennis:
Yeah, that was neat that the guy Tim or Tom was pretty impressed that we've been doing an accessibility podcast. So that was cool.
Ross:
Yeah, get them to plug it.
Dennis:
Yeah. OK, so let's move onto the main content of this podcast is Design Considerations for Accessibility. Ross and I started listing off a whole bunch of things. We're actually, it is not really going to be called part two. In two to three weeks we are going to have another podcast for just general coding considerations for accessibility, not specific techniques for how to do things but just a bunch of different things to keep in mind when you are coding the design for accessibility.
Ross:
Yeah, we came up with a big list and realized there are two parts of it. How you are actually going to design and layout and structure the site versus how you are going to code it and so we figured two podcasts might be a little easier.
Dennis:
Yeah, well all right, let's get to it. The first subject is sticking to conventions, which I highly recommend. I know Paul Bolet and I talked about that too a little while back. A more usable and accessible web site is obviously where one, it is easier for a person to use it and for it to be easier for them to use. If they are more familiar with the way it is laid out, the easier it will be for them to use it. So sticking to layout conventions is probably a good idea.
Ross:
It's kind of the basic thing when you go to 50 different web sites this is where the things usually are. If you think about it from someone who is not real familiar to the web, it is pretty confusing. Every web page is laid out differently. You have to use it differently so anywhere you can keep your page consistent with what other pages do makes it easier to use and makes it more accessible.
Dennis:
Someone with cognitive disabilities or just a new user to your web site or to the Web in general will make it easier. Some examples would be like the search box usually is in the upper right corner of a web site. The main or general global navigation items are usually across the top, while some navigations are usually on the side, left side or right side.
Ross:
Then also the use of icons can be really helpful. A lot of web sites do that. It helps not only as far as recognizing that the little envelope stands for email but people with cognitive disabilities are going to have a harder time reading comprehending email lists to a friend versus seeing the little icon and identifying that.
Dennis:
Yeah it's a good idea to stick to the conventions of the icons. You know like the icon for going to your home should be like the little shape of a house usually or some kind of alternative version of that.
Ross:
Yeah something that makes sense. It looks like a multiple use for a home. You don't want to put a dog icon or something like that.
Dennis:
[laughter] Yeah, or you know what a good one to talk about is like the RSS icon. That's a newer one that is becoming a convention. There are two really. There's the one that says RSS in white letters with the orange background.
Ross:
Yeah.
Dennis:
but I think one that is becoming more popular, a lot of people go, "What the hell is RSS?" The one that is becoming more popular is the square orange block and it has the three little curvy lines on it.
Ross:
That's kind of, since RSS is still relatively new. You have an icon and everybody can use it but if you don't know what RSS is, it is still a little confusing so I would almost like to see an icon that says subscribe or something along those lines where it kind of tells people who don't know what RSS is that this is sort of what it does.
Dennis:
Well I guess people are using the phrase News feeds or something like that.
Ross:
Yeah.
Dennis:
more and I know Microsoft came up with their own terminology. We won't give them the time [laughter]. all right so another design consideration is for navigation. Well just real fast, we will say about skip nav or skip to content. That was covered on an earlier podcast on Web Axe. It is a good idea if you have an accessible web site, you want to make this skip nav link visible. Some sites and we can go on and on about this but some sites when you mouse over it becomes more visible or if you tab through it doesn't show but when you tab through it, it appears. Whatever way you decide, it's obviously a consideration when you are designing the page.
Ross:
It's good to have. Some sites don't make it. It's only really usable if you have style sheets off or if you are using a screen creator and it's just kind of their choice. But whether you make it visible or not, it's good to have and if it's visible, that's even better.
Dennis:
There might be some other very few instances; a small percentage of your audience might use it if they turn off the style sheets. It might be valuable to have it. Anyway, a couple more considerations for navigation. It's a good idea to indicate the current page that you are on in the navigation area. And then it's also a good idea to indicate the pages you that have already visited.
Ross:
It's always important. It's kind of like visual cues where you are in the site. And a lot of people don't indicate visited pages, which is too bad because it's so simple to have a visited tag where you have a slightly different color or different color altogether, or maybe it's underlined or not.
Dennis:
Or if you are really nifty, you can put the little tick box or check mark. We Americans call it the check mark and that's your main navigation elements that the user has been there already.
Ross:
Yeah, it's starting to get pretty popular. If you have two pages that are similar you can go, "Oh, OK. I've been there."
Dennis:
And again that's better for people who are not accustomed to using web sites and people with cognitive disabilities and stuff.
That brings up the next element. It's kind of related, it's breadcrumbs. There're good and bad sides to those too, but at least consider that in your design if you are going to use breadcrumbs or not, and where to place them.
Ross:
So that way you can see, again, where you've been, how you got there, where you are at now. That sort of thing.
Dennis:
Let's move on to color considerations. Obviously when you are designing a web site you need to consider the color and there are a lot of psychological and marketing aspects to that. As far as accessibility goes there are a few things to consider. Number one, be sure there's enough color contrast in your design so people with low vision and color blindness can still view the site and see what they need to see. If you don't have enough contrast it will be very difficult to read. And I think that's a priority one consideration.
Ross:
And there are tools out there that will test and show you what it will look like to someone who is color blind. So even if you might be able to read it, or even if you have poor vision you might be able to read it, someone who is color blind might not be able to, so it is important to test that also.
Dennis:
It could be if your computer isn't that good. My brother had this computer and I don't know what happened but the monitor got all dark all of a sudden, and so for a year he used this laptop and it was kind of difficult for him to use. He could still use it, but the monitor was really dark and there was nothing he could do. It was broken. So, that would also help if your monitor isn't as good or was broken.
Ross:
I noticed with CRT monitors as they get older the quality gets worse and worse. People have a computer for three or four years and the monitor gets worse and worse, so you want to make sure they can still read your site.
Dennis:
What do you think about the light on dark or dark on light argument? I personally go a long with supposedly it's a fact that dark letters on a light background in the long run are easier to read.
Ross:
I've read that and I think it kind of depends on the monitor itself. I mean, monitors as opposed to paper, they project light, where paper reflects light. Especially if you are in a dark room and your monitor is projecting less light, I know a lot of people it's kind of too bright for them, it gives them a headache. There's this kind of balance where even people who are using light backgrounds and dark text will not go pure white, not go pure black to compensate for that. I think visually, I mean, personally, I like dark on light better, but I think readability-wise it seems like light on dark for me is easier. Maybe it's just because I associate a piece of paper with a white background and black text.
Dennis:
I think in general it's better to go with darker text on a light background. Unless it's some kind of alternative, like an art site or something. You got your black background and gray text and all that stuff. So besides making sure there's enough contrast, obviously you want your colors, you want to design for the content of your site, of course, and all that marketing stuff.
Ross:
You kind of consider how much text you have and if there's going to be a lot of text, take that into consideration, versus if you have a few short blurbs on each page versus a lot of pictures, you'd probably get more experimental.
Dennis:
I believe another priority one color consideration is never use color to convey information. And that might be more for somebody writing the content but it's also true when you are designing your site. If you don't know, the general idea is if you have a red button and a green button for No and Yes or something, you should add at least text saying Yes and No to convey that content, to convey that meaning. Or, in addition to, change the shape of the object, like a red octagonal stop sign kind of thing for No and a circle or whatever for Yes.
Ross:
I see this most being broken for forms. People will say, "Items marked in red must be filled out." Well....
Dennis:
Can't tell red from green.
Ross:
Yeah, can't tell red from green then, you know.
Dennis:
Of if you've turned off the style sheets or whatever.
Ross:
There's a million different situations where that's useless.
Dennis:
The last color consideration is if you change one color of a link in an anchor state, you should change them all. Most people do that nowadays, designate every state the active, visited color, but if you do change one of them, make sure you change them all. Or else the default colors are going to revert for the ones you haven't changed and you end up with a mess.
Ross:
Yeah, it gets really confusing.
Dennis:
Let's move to layout considerations.
Ross:
A lot of people have a style sheet specific for low vision or large text or high contrast. Any time you are catering to people who have poor vision it makes more sense to convert a multi-column site to one column to just kind of linearize the content. That way you can make the text even bigger, the line links don't get ridiculously small, and it gets much easier to read. People have to scroll more but it's going to be easier for them to scroll and try to read a sentence that is three words per line.
Dennis:
And hopefully if your site is already created with web standards and CSS as it should be then creating that low vision style sheet should be relatively easy.
Ross:
It makes it really easy to shift stuff around and change the width, that sort of thing. So, use web standards.
Dennis:
Another consideration is, you've probably heard this one before, is about scrolling. I don't think it's a big deal if you need to scroll or not, but if you need to scroll down to get some content, then to try to indicate that to the user.
Ross:
You want to make sure that it's obvious that you can scroll down and one way to do that is to have a universal footer at the bottom of every page so people know they don't hit the bottom of the page until they see that footer. Also, if people start scrolling down and they don't see the navigation anymore, they don't see the breadcrumbs, they don't see where they're looking on the page, it starts to get a little disorienting because all they see is text. That's one thing to consider. Try to keep the page to about less than four pages worth of scrolling. If you took your resolution and copy that four times, that's about where you want to stop and have a second page for the same content.
Dennis:
So if you have a really long article, once you've scrolled down about four pages, you should probably create a second page for that article.
Ross:
Yes. Generally it makes it easier to read, navigate, that sort of thing.
Dennis:
Did you find that five to 10% of users won't bother or notice that they can scroll down? That's interesting.
Ross:
Yes. I forgot where I read that and who knows how valid that is for a sample site.
Dennis:
It sounds pretty believable to me.
Ross:
People, sometimes get to a page and it's not obvious. The scroll bar is there but it's way out on the right hand corner and you don't really focus on that. I can see where people wouldn't notice, "oh, I have to scroll down." When you start using fixed elements I think that probably gets worse.
Dennis:
That leads to the point that when designing the content on a page, the most important content should be first.
Ross:
Didn't Nielson say something like that? It should be a reverse triangle; most important, second most.
Dennis:
It's like newspapers if you think about it. People scan newspapers. When you're writing newspaper articles, the most important stuff is supposed to be first.
Ross:
Yes. Front page, big letters.
Dennis:
Another consideration for the layout design is try to keep the width of the design approximately 760 pixels wide, and that obviously is to fit into the 800x600 screen resolution. I believe 30 or 35% of people are still using that resolution.
Ross:
I've heard a whole bunch of different ranges, but enough where you should consider it. Even at 10% you have to figure that's one out of 10 people, which is a fair amount of people who are visiting your site. It's not only technology constraints but a lot of people who have poor vision use 800x600 just because it makes the text bigger.
Dennis:
As far as mobile devices, PDA's have a fixed resolution. At 1024x there's going to be a whole lot of horizontal scrolling with a PDA.
Ross:
The wider it gets the less useable it gets, so that's something to be considered.
Dennis:
All right. Text considerations.
Ross:
Sans serif fonts are generally easier to read on screen where serif fonts are easier to read on paper. Times New Roman is serif. The serif refers to the little danglies at the end.
Dennis:
If you don't know about typography, it's the ends of the letters themselves, little curly rolls; Times New Roman, Georgia. Those are serif fonts because they have serifs, those little squiggly things that make the writing look fancier.
Ross:
Sans serif fonts are, sans means not, so they don't have those...
Dennis:
It means "without" actually.
Ross:
"Without," thank you. So Verdonna, Ariel, and Helvetica.
Dennis:
So we're recommending, I like Verdonna. Sans serif fonts are easier to read. So Helvetica, Verdonna, what are a couple of other ones?
Ross:
Ariel. There's a handful. That goes back to the fact that paper reflects light, screens emit light and your eyes scan the top of letters. On paper, having the serifs on there makes it easier to recognize the letter quickly. That's not the case on screen which is why some of you will start to develop sans serif fonts. For example, Verdonna was made by Microsoft.
Dennis:
Really?
Ross:
That was because fonts didn't have anti-aliasing on computers for Microsoft so they designed a font that looked good small without anti-aliasing, and that where Verdonna came from. They screwed off and that was their way of making it better.
Dennis:
You were breaking up the last 10 seconds so I don't know if our audience heard that. Microsoft created Verdonna because of the anti-aliasing issue?
Ross:
They didn't have any anti-aliasing built into Windows at the time. It Was a way to make text readable. They designed the font to be very readable in small sizes.
Dennis:
That's cool. Then there's also Trebuchet?
Ross:
Yes, Trebuchet MS.
Dennis:
That's Microsoft too, then?
Ross:
Yes, it's a hybrid between serif and sans serif. It does have serifs but it's not extremely pronounced.
Dennis:
All right, let's move on to a couple more issues directly related to accessibility and that is; be sure your text, the font size, can be enlarged in your web site without breaking the design. On my main monitor I have the resolution pretty high just so I don't have to strain my eyes so much.
Ross:
Me, too. I have a 19" external that I run high resolution for Photoshop or whatever, but trying to read a web page with tiny font is, forget about it.
Dennis:
No kidding. For anyone who wants to enlarge text for any reason, make sure your design doesn't break or is still readable when you enlarge the text. Another more general consideration is, your headers should be larger than your regular text. That might seem obvious. To indicate importance, header one or header two should be larger than three or 4. Try not to break that convention, that's just because of the importance of the meaning behind that and for anyone with cognitive disabilities.
Ross:
It makes it easier to scan and comprehend if you have a cognitive disability and there's all sorts of reasons to do that.
Dennis:
Yeah. That's a good point. For scanning and all kinds of other reasons, but fonts should be good sized. Not everyone knows how to resize the text.
Ross:
Yeah. This is something I just read; there's a blog about web design called "smiley cat" at smileycat.com and I guess they just study, I can't remember, maybe link to a study where they looked at what percentage of users of a set of web sites use anything other than the default text size, and it was something like only.03% actually did. To me that kind of says, if you look at, you know, 10% of the market still use 800x600, and a good portion that's for readability reasons. A lot of people don't know how to resize text, so you want to keep that in mind. People are viewing your site and they don't know how to enlarge the text so you want to make it at least a decent size to begin with.
Dennis:
You know, that's a good point, and that brings up an argument about placing the text resize buttons or tools on your web site itself.
Ross:
Yeah.
Dennis:
Some people say, yeah, that's great. The user can click it to automatically resize the text, and I guess I have to agree with that. It's a good idea, and that helps the user. But, I do at the same time have a problem with that because I think that's the responsibility of the browsers.
Ross:
Yeah, I agree.
Dennis:
The companies that develop these browsers need to make that tool, that technology more prevalent on the browser. It's already incorporated in the browser, why can't they just put a couple "text enlarge" and "text decrease," a couple of simple buttons.
Ross:
Yeah, I know.
Dennis:
Then you don't have to design it. Why does everybody have to reinvent the wheel and put it on their own web site. Just put it on the browser where it should be.
Ross:
Yeah. You think that's something that could prevent somebody from getting any information from a web site. They don't know how to resize the text, the text is too small. Why not make a plus-minus button right in the browser.
Dennis:
Yeah. IE7 and a lot of other browsers have the zoom-in tool, the "resize the site."
Ross:
Yeah.
Dennis:
The zoom in or zoom out 150% or whatever. If they're doing that I don't know why they can't put "increase the text."
Ross:
Yeah, it doesn't make sense. What I do, and this kind of has it's fallbacks too, is I try on my accessibility page to give people instructions on how to resize the text, which I figure if they read that they can go to another site now that they know how to do it.
Dennis:
You mean your "help" page?
Ross:
Exactly.
Dennis:
And if you've read the Web Axe blog you know what I mean by that.
Ross:
But everybody's not going to find that, and that could be wholly lost on some people so it has it's own drawbacks.
Dennis:
So I suppose that for now that's a good idea, to put the "increase text size" button there.
Ross:
Yeah, until the browser manufacturers get a clue or two.
Dennis:
Anyway, we're running out of time so let's just go through some of these last considerations fairly quickly. Just some various other design considerations for accessibility. One is to limit the use of "flash," and that could be another whole episode, but basically my point is, if you're going to use flash, just limit the use of it and place little animation and interactive elements in certain portions of your site and make the content accessible.
Ross:
Yep. Don't make your site dependent on flash, and also make sure you have print style sheets because a lot of people print out pages because it's easier to read on paper.
Dennis:
Yeah. And you can make it look really cool and print out much better for people with a special style sheet designated for printing. And then, maybe the next point is for part 2, but the graphical buttons with text--when you're implementing your interface, and you have graphical buttons it really should be text or an actual html button with graphical backgrounds.
Ross:
Yeah. And that way you can resize it...
Dennis:
Without the pixelation.
Ross:
Yeah, without pixelation. That sort of thing. That's really important.
Dennis:
The text and buttons resize nicely whereas if you resize the graphic it's going to be all distorted and pixelated.
Ross:
Yeah.
Dennis:
It's a good idea to include some kind of site help or accessibility page or guides so if someone wants to know than can go and see what accessibility features you have on your site, and maybe list a few access keys.
Ross:
Yeah. Kind of inform a little more.
Dennis:
No flickering. So that's another basic accessibility guideline, and the point of that, I know there's a couple points but the main one is to avoid causing any, help me out here, Ross.
Ross:
Seizures, I believe.
Dennis:
Yeah.
Ross:
Yeah, that would be really bad.
Dennis:
You don't want to give people seizures with your web site.
Ross:
Yeah. Some people are real sensitive to flickering and that can cause seizures, so definitely no flickering.
Dennis:
Exactly. And, let's see. If you're using multi media, like audio, plan in your design for text-only versions somewhere, you know, for links for that, and if when you're doing video, plan for captioning your audio with the video.
Ross:
Yep. You can do that, think PBS closed captioning. Kind of the same idea, if you have the video of people talking, people can get the same content without having to see or hear it.
Dennis:
Right. And this is definitely doing that, depending on what medium you're using. If you have any questions or input or comments on that, leave a comment on the Web Axe blog or send me an email. I've done some captioning with "Smile" and "Sammy," for video and it's pretty neat. It's fun to use and you can customize it and everything. It's pretty cool.
Ross:
Yeah. You definitely want to do it if you have to deal.
Dennis:
Well, all right. I think that wrap's it up for "Design Considerations for Accessibility."
Ross:
If you have any questions, end me an email, we'll be happy to answer them on the next show.
[music]
Dennis:
Great. We'll see you next time. Thanks for listening. The Web Axe blog and podcast is located at webaxe.blogspot.com. Email Web Axe at webaxe@gmail.com. To leave a voice message, call 206-203-0585. Web Axe is sponsored by CheckEngine USA, web site tune-ups and overhauls: www.checkengineUSA.com.
Transcription by CastingWords